I am starting a new app that will target both web and mobile (but possibly only as HTML5, not necessarily a native app)... So, what are the frameworks you guys recommend? I am familiar with plain ol' ASP.NET, and some minimum AJAX. So is it best, for example, to build a ASP.NET REST based API with a JQuery and JQueryMobile?
I'm looking at a similar approach while we're commercializing an app of ours.
Considerations
After 5 months of research and experience combined with the comments above, here are some considerations:
Do you have control over your users' browser selection? If yes, HTML5 is a great and flexible. If your users are more up-to-date I would also recommend HTML5.
The server-side framework in most cases will not matter, as long as you can develop a robust server with an efficient data model that's familiar and manageable.
Are your mobile devices tablets or phones or both? If you are using phones it will be harder to fit and prioritize the interface.
Do you know all of your app's functionality? This will be important for determining UX which will then help you understand how you will build out the client.
Is your app real-time? And you have modern users? Websockets are handy. Here's a demo for ASP.NET http://wsaspnet.codeplex.com/
Recommended Frameworks
Given your case, here are some recommended frameworks to make life easier:
Stick with .NET on the server-side since you are familiar with it
Use backbone.js to manage your client-side template
HTML5 boilerplate is also worth a look http://html5boilerplate.com/mobile
Use the latest JQuery library
Use JQuery Mobile to adapt your HTML5 app to mobile devices
There's also JQTouch http://www.jqtouch.com/
Custom build your "fluid" javascript to adjust your client to different interfaces (I haven't been satisfied with current plugins and frameworks)
If you are using websockets, web-socket-js is very handy for a flash fallback https://github.com/gimite/web-socket-js ...otherwise stick with AJAX REST
Consider PhoneGap to adapt your app if you need to distribute the app in approved marketplaces outside the browser http://phonegap.com/ and https://build.phonegap.com/
Here's a C# Websocket server: http://www.codeproject.com/KB/webservices/c_sharp_web_socket_server.aspx
Remember
Sometimes it is just necessary to build a separate client for mobile if your app is complex. It can be native, HTML5, or HTML5 put through PhoneGap.
Related
I am beginning to develop an Enterprise level web application. The application will have many separate web pages but two of those pages being more focused and very heavy - heavy as in a lot of user interaction, modals that display mass data, websocket connections, chat, etc.
I have been assigned to Chief Architect on the project, so I am doing some research into the latest web frameworks. For the back end, we have done some testing and have decided to go with the Azure SQL platform. So far, I am liking the improvements that have been made, and are being made, to ASP.NET with Core 2.0. Specifically the Razor engine, over previous versions of ASP.NET MVC.
I wanted to get some expert opinions on the "new" Razor vs. Angular/React and the like. I'm particularly more concerned with performance. How does Core 2.0 Razor hold up to client side rendering frameworks? Are the differences negligible? Our app is targeting a potential 1,000,000 users (roughly 100,000 concurrent).
We ended up going with an Angular front-end and an ASP.NET Core API backend, using Azure SQL. We tested Core Razor and, although better than legacy Razor, Angular was much faster for us in the end. As far as user experience goes, Angular (or React) is far superior in terms of performance. The model-binding aspects of Angular we found to be a gigantic advantage of server-side rendering. Using Razor(or server side rendering in general) does, however, lend itself to better overall integrity as far as data goes and it makes for a better transition of data from front-end to back-end. There is a true disconnect between a front-end framework and an API. All data that is passed to the server has to be cast into typed objects - this means you have to manage two separate POCO model sets. This can cause issues if server objects and front-end objects do not align. At the moment, Entity Framework Core is not very matured so we have issues with updating objects, querying objects, including child objects, etc.
Overall, this setup has worked out great for us so far! I would imagine React would be a similar replacement to Angular if you're more comfortable with it. I had to learn Angular, which was a very easy transition, and I love it now!
By using Angular/React with API on the server-side:
you eliminate the process of generating HTML on server-side and you save CPU
API produces a small payload (JSON) and Razor (HTML) of course would be much larger in size, the constant full page reloads, and postback round trip, so API and SPA save bandwidth
API and SPA could have different versioning, scaling and deployment scenarios
By using API you can support mobile app too and if you start with Razor you may need API in future
But by using Angular/React, you should be worried about clients:
client must enable javascript
client must have modern browsers
client must have enough powerful hardware
SEO
I don't have benchmarks. But, I have several projects running JQuery, Razor, .NET MVC (C#), AJAX. Not to the scale you're tackling.
Advice.. Be sure to think things through and follow best practices. To keep things maintainable be sure to break controllers, views, model into smaller and meaningful groups. When I started, I made the mistake of putting everything into one Home controller, and a ton of views in the shared folder. Was fine at first but when feature creep began, it became a mess and difficult to go back and redesign.
I also use Linq2SQL. I made the mistake of creating models for everything and then realized I could just return the result set from my queries as a model. duh.
If you go .NET MVC and are concerned about performance, these are the things I ran into:
DON'T return partial views that create large blocks of HTML! Be sure to minimize everything. Get rid of all the white space. Use smaller ID names. Take the time to create html that is as light as possible. Return JSON and have the client do some of the work.
Be careful on how you develop your CSS. Don't use a bunch of inline styles, take the time to incorporate into CSS files that you can later minimize.
Same goes for your client side JS. It's tempting to put the JS inside partial views. Keep things organized.
Rendering on IE is horrible. Especially if there are lots of images. Be sure to compress images as much as possible, without losing quality of course.
React vs Angular
Basic Security on client side environment in Angular while React security not provide.
Angular execution slow while React execution is fast due to virtual dom.
Angular code is not 100% customize while react code is 100% customize.
Default Typescript in Angular while React use Javascript and Typescript Both. This is the main reason many developer like React because developers like JavaScript
I am going to build a social intranet for a company with about 750 employees. They already use WordPress with the BuddyPress plugin. Also, they have multiple internal systems which would have to supply additional data for the intranet. The application has to available for PC, and smartphone/tablet via browser and as a standalone app. Both for at least Android and iOS.
So far, we've been talking about building a responsive HTML5 webapp which communicates with a centralized API. I would have to build the API, too.
For the frontend they've recommended me to use AngularJS, but I'm concerned about performance if you combine it with WordPress/BuddyPress. Does anyone have experience with this? And would you build a responsive website or a seperate mobile version?
I've been comparing multiple solutions to build the mobile app with (near) native performance. These are some viable options I've found:
Appcelerator Titanium Studio
AppGyver Steroids
Xamarin Studio
In your experience, what are the pros and cons with these options? Are there any pitfalls with any of these? Do you have other recommendations?
I don't see that Wordpress / Buddypress in combination with AngularJS should cause any performance issues.
There are basically two aspects of the app which you're involving here. The server-side, which is running Wordpress, and then the client-side which is running AngularJS.
In any case, if you have queries on a huge DB, or a slow server, or a series of recursive queries, you will experience performance issues on the server-side with Wordpress, which might result is slow load times. In any case, if you have many DOM items displaying on the client-side, with complex CSS styling, you may experience some performance issues on the client-side, especially with older smart-phones, which might result in a slow/choppy UX experience.
There are some client-side performance implications with AngularJS when using ng-repeat when you get into objects with hundreds of sub-objects and deep data binding, which could easily cause some client-side performance issues.
I've been using Wordpress / AngularJS together for a year developing web apps intended for use on all the prescribed platforms, and there's no perceivable performance issues - certainly if there were any, I can't see how it would be caused by the Wordpress/Buddypress and AngularJS combo, since they're handling completely different sides of the app.
I'm working in a webapp with Spring and I always used JSP and Jquery, In a recent conversation, some guy commented: You should use Flex instead.
Would Flex be a good choice for a web app? What are the advantages of using it vs. just JSP and Jquery?
I think you really mean to ask; why should I use Flex instead of JQuery.
JSP is a server side language. Flex or JQuery are client side languages. Flex is not a replacement for JSP any more than JQuery is a replacement for JSP.
Flex can be used to create a Flash Application; which can be deployed in a few different ways.
It can be used to create a browser based application that run in Adobe Flash Player. The Flash Player is only supported on desktop browsers, and there are no viable options to deploy a Flash Platform app to current mobile browsers. I would only recommend this if you had tight control over the machines accessing your application.
It can be used with Adobe AIR to create a desktop application for Windows or Mac machines. I, personally, think the use case for this is even smaller than creating browser based applications.
It can be used with Adobe AIR to create a Native Application on iOS, Android, and Blackberry Playbook. If you are tasked with building a Native Application that needs to be deployed on multiple mobile OSes; I think that Adobe AIR presents an intriguing option.
if you need to build Native mobile applications, and you already know JQuery, I'd recommend investigating options to build your JQuery apps as Native Applications. I know options are out there to convert HTML into Native Applications, but can't comment on them. I see no need to switch your technology unless you are running into limitations. To evaluate Flex ;you'd have to define what those limitations are and then decide whether Flex will help solve them. Usually the time savings of "use what you know" outweigh any benefit that comes from switching technologies.
That said; Flex provides some things that I don't see yet in the "HTML5/JavaScript" space. It has a robust UI Framework that works identically across all the platform targets, a step through debugger, and a memory profiler just to name a few.
The two technologies are completely different. JSP/jQuery would give you a web application. Flex would give you a Flash application.
Personally, if JSP/jQuery would work for you then you should go that route. If you don't need the features of Flex, there's no reason to require the user install the plugin.
I came across the Adobe Flex framework one day. After watching http://www.adobe.com/products/flex/media/flexapp/'> the demo of Flex, it looks to me it is a bundle of different Ajax controls. I have no working knowledge of Flex at all and know very little about Flex. Therefore, I would like to hear from the developers here with some Flex experience to explain a bit more pros and cons of this Framework. In particular:
How productive it is to program in Flex compared to the .Net + Silverlight?
Any technical advantages over other frameworks?
Any disadvantages ?
Does it have any known scaling issues?
What kind of web servers can it be hosted on?
Any other things I should be aware of about Flex?
How productive it is to program in Flex compared to the .Net + Silverlight?
Way more productive than Silverlight as it has a much richer and capable control library. Silverlight is rapidly gaining ground here though. I think by the time SL 4 comes out they will reach feature parity, maybe even SL 3.
Any technical advantages over other frameworks?
If you can create it in Photoshop, you can pretty much do it in Flex with the help of the Flash drawing API. If you want to build very interesting data visualizations (tree/node diagrams, such as an org chart) you can do this Flex without a ton of work.
Any disadvantages ?
There is no server-side component to ActionScript so you need to find a way to pass data between Flex and your backend, be it Java, .NET, PHP, etc. There are libraries out there to AMF remoting with just about any backend which makes it easy. But as far as the objects you pass between the two, you need to maintain both or use a code generation tool to create AS3 classes from your backend classes.
Does it have any known scaling issues?
Flex is simply a presentation technology so this question doesn't really apply.
What kind of web servers can it be hosted on?
Again, only a presentation technology. It compiles out to a SWF file that is loaded by the browser over HTTP and then executes inside of the Flash Player plugin.
Well ~~ .. it's more that Silverlight is similar to Flex. It's not Ajax so much as a kind of 'walled-garden' inside of which you have a rich programming environment. Somewhat like Java apps say.
The usual criticism derives from just that. Flex/Flash applications tend to be ignorant of the browser (more or less) so that stuff like back-button usually gives unexpected results.
It'll run on all the current browsers on all platforms. You don't need to "host" flex as you build a SWF file that gets loaded into the browser and is executed by the Flash Player which your users are expected to have already downloaded/installed .. (95+%) penetration helps.
I've been using Flex for the last year or so and it's served my purposes well. It can be integrated nicely with javascript stuff on your web pages and provides a very rich set of capabilities for doing all sorta things like web-services and XML processing and of course all your video/audio/music rich media.
The language is ActionScript 3. Which is fundamentally a strict superset of javascript. You can use javascript as-is. (ActionScript was intended - by Adobe - to be next-gen javascript.)
It can compiled in two modes. One is for hosting in a browser as web app, using the Flash runtime object to provide granular GUI controls.
Or it can be compiled in desktop mode, where it uses another runtime (named AIR) to operate interchangeably on Windows, Mac, or Linux.
I wouldn't compare it to Ajax. It's more like .NET, if .NET didn't have such a disparity between desktop.NET and ASP.NET. Pretend ASP.NET offered a desktop runtime, maybe. (Not a bad idea, actually).
Like a lot of non-MS technology, it tends to be basic yet cover the important capabilities. More conceptual integrity, IMHO. About the same scale, scope, and complexity as VB6 and useful for about the same set of tasks, for about the same audience of developers and users. Yes, it's got good database connectivity too.
We need to build an administration portal website to support our client/server application. Since we're a .Net shop the obvious traditional way would be to do that in ASP.Net. But Silverlight 2 will be coming out of beta a good while before our release date. Should we consider building the whole website in silverlight instead, with a supporting WCF backend?
The main function of the portal will be: users, groups and permissions configuration; user profile settings configuration; file upload and download for files needed to support the application.
I think the main reason for taking this approach would be that we have good experience with WPF and WCF, but little experience in ASP.Net. Either way we would have to learn ASP.Net or Silverlight, and learning Silverlight seems a more natural extension of our current skills.
Are there any big no-nos from the experience of StackOverflowers? What are the big positives?
I would recommend against building a pure Silverlight site.
Silverlight suffers from the same issues as Flash does: Unintuitive Bookmarking, issues with printing, accessibility issues, not working back buttons and so on.
Also, you would require your users to have Silverlight installed or at least to have the ability to install it.
In controlled environements (eg. in large companies or health care) or on mobile devices, this might not be the case.
I would definitely go for a full Silverlight application, specially if you have good experience from WPF. You will be able to reuse your knowledge from WPF, and should be able to pick up Silverlight fairly quickly. I've been working with Silverlight since Beta 1, and the current Beta 2 is of solid quality. I guess it's safe to assume that a RTW version is just around the corner.
Pilf has some valid point, specially around printing. For that I would probably use SQL Reporting Services, or some other reporting framework, on the server side, and then pop up a new window with printable reports. For linking and bookmarking the issues are no different than any other AJAX application. I did a blog post today about how to provide deep linking and back-forward navigation in Silverlight.
Silverlight also has all the hooks needed for great accessibility support, as the UI Automation API from WPF is brought into Silverlight. I don't know if the screen reader vendors have caught up yet. The styling/template support in Silverlight makes it easy to provide high-contrast skins for visual impaired users if that is a concern.
Depends on your goals. If administration portal is part of application and will only be used from computers where your application is installed, there are plenty of advantages of going fully Silverlight - or even WPF.
But if you can see a scenario where it will be used either from random PC or by random person, fully functional HTML/Javascript version is absolutely necessary.
Some reasons are:
Most people don't have silverlight and you'll earn a good load of swearing if they have to download and install it. Some people who have it installed keep it disabled (together with flash and sometimes even images) to avoid distractions and speed up browsing.
When HTML site fails, user gets error page and reloads. When silverlight fails, it can hang or crash.
HTML is what is expected - both by users and web browsers: back and refresh buttons work as they should, hyperlinks and forms work as expected.
Slow internet is still very common, both in remote areas and mobile devices.
I agree with what everyone had said so far and I think this Flow Chart, which is aimed at Flash, also applies to Silverlight.
Source of Image
It sounds like your problem is that you need a rich-client admin application. Why not use click-once?
On the topic of remote andministrators, another poster stated that was an argument in favor of HTML if the admins were on a slow connection. I would argue that depending on the type of information, it may be more efficient to use Silverlight. If you have an ASP.NET datagrid populated with server side data binding, you can be downloading a ton of markup and viewstate data. Even if you're using an alrternative to DataGrid that's lighter on the ViewState, you will still have a lot of HTML to download.
In Silverlight, once you get the XAP down, which is probably going to be smaller than the corresponding HTML, the XAP is cached and so you shouldn't have that cost every time, and you'll just be retrieving the data itself.
For another example, let's say you have a bunch of dropdown lists on one of your forms which all have the same values in the list. In Silverlight, you can get these values once and bind them to all of the dorpdowns, in HTML you will have to repeat them each time.
This will get better with client side data binding in ASP.NET, which follows a very similar model to Silverlight and WPF for data binding.
Overall, I would also think that you would need to write less code for the Silverlight implementation which can increase productivity and reduce maintenace costs.
ASP all the way. You should only use silverlight/flash etc when text can't do what you want it to do - e.g. display video.
Using a plugin for your website makes it slow, and requires the user to have the plugin installed. Silverlight for instance rules out all Linux user. Also, since Silverlight is pretty new, there is no telling how committed Microsoft will be to keep the platform alive if it doesn't pick up soon.
I'd stick to plain old HTML with server side scripting.
Also, for public websites: Flash and Silverlight can't be indexed by any search engine, so good luck with writing tons of metadata if you want any visitors at all.
Silverlight is a good choice for an internal-facing portal, just as it would be for a public-facing portal if you've already evaluated your project and have decided to go forward with a web portal. You are free to integrate Silverlight components within an existing ASP.NET application (i.e. the "islands of richness") approach, but if you have the ability to build a new project from scratch, don't discount a completely Silverlight solution as a valid choice where you would have went with a traditional ASP.NET portal. Silverlight is RTW now, so if this decision is still on the table, you know you won't have to deal with breaking changes going forward.
There are some downsides with developing a site completely in Flash / Silverlight, but if those downsides won't matter to you or won't have an impact then there is nothing stopping you. Choose whatever tool you think meets your needs more fully. I wouldn't be put off creating a site purely in Silverlight based on the downsides, because it brings a lot more positives to the user experience.
The previous comments have dealt with most of the downsides of using Silverlight for a site like this and I agree. If you're determined to have rich-client style development and your audience is small (for admins only) then I'd probably recommend WPF over Silverlight as it currently provides a richer set of tools and controls.
If you stick with ASP.NET have you looked at Dynamic Data - it's ideal for building backend management sites with little effort.
I've seen "Silverlight only" websites at Microsoft and they are pretty impressive. But again, the demos were there to exploit the full potential of what Silverlight can do. The moment you need something different you may be out of luck. I don't see Silverlight like Flash except in the way they are installed/seen. But the Flash/ActionScript backend is really bad compared to what Visual Studio can offer with .NET
Ask yourself why would you like to use Silverlight? Fancy effects or programming model?