Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

My primary day job is making HTML applications. With that I mean internally used CRUD-type applications with lots of editable gridviews, textboxes, dropdowns, etc. We're currently using ASP.NET webforms, which do get the job done, but the performance is mostly dismal, and quite often you have to jump through hoops to get what you need. Hoops which are hung from the ceiling and set aflame.

So I'm wondering if it perhaps would be a good idea to move all UI to the JavaScript side. Develop a strong set of reusable controls which are tailored specifically to our needs, and only exchange data with the server. Yes, I like the "control" (aka "widget") paradigm, its quite well suited to such applications. So on the server side we would still have a basic layout simliar to our current ASPX markup, but that then would get sent to the client only once, and the Javascript part would take care of all the subsequent UI updates.

The problem is I've never done this before, and I've never seen anyone doing this either, so I don't know what the problems would be. In particular, I'm worried about:

  • Performance still. Benchmarking shows that currently the main delay is on the client side, when the browser tries to re-render most of the page after an AJAX update. ASP.NET webforms generated markup gives a new meaning to the word "web", and the rich Devexpress controls add their own layer of Javascript complexity on top of that. But would it be faster to recalculate all the necessary changes on Javascript side and then update only what needs to be updated? Note that I'm talking about forms that have several editable gridviews, lots of textboxes, many dropdowns each with half-a-zillion filterable items in them, etc.
  • Ease of development. There would be a lot more Javascript now, and it would probably mix with the HTML markup of the page. That or some kind of new view engine would have to be produced. Intellisense for Javascript is also a lot worse than for C# code, and due to the dynamic nature of Javascript it can't be expected to get a lot better. Coding practices can improve it a bit, but not by much. Also, most of our developers are primarily C# developers so there will be some learning curve and initial mistakes.
  • Security. A lot of security checks will have to be done twice (server-side and UI-side), and the data-processing server side will have to include a lot more of them. Currently, if you set a textbox to be read-only on server side, you can depend on its value not changing through the client roundtrip. The framework already has enough code to ensure that (through viewstate encryption). With the data-only approach, it gets harder, because you have to manually check everything. On the other hand, maybe security holes will be easier to spot, because you will have only data to worry about.

All in all, will this solve our problems, or make them worse? Has anyone ever attempted this, and what were the results? Are there any frameworks out there that help in this sort of endeavor (jQuery and moral equivalents aside)?

share|improve this question
    
So on the server side we would still have a basic layout simliar to our current ASPX markup, but that then would get sent to the client only once, and the Javascript part would take care of all the subsequent UI updates. You are describing exactly what ASP.NET is, which tells me that you are likely not using it correctly. :) In your ASP.NET applications if you place components within update panels then the ASP.NET javascript library will perform asynchronous postbacks to the server side and only re-render components that you specify. –  maple_shaft Mar 16 '12 at 10:56
    
@maple_shaft - I know, but somehow this works slow as hell. Also, the grids already do callbacks. For everything else, if there is a postback, in the vast majority of cases you need to refresh most of the page anyway, because controls change visibility/writeability/etc. And that's slow. –  Vilx- Mar 16 '12 at 11:05
    
@maple_shaft - Currently in most case the entire page (well, except the "frame" from the master page) is placed in one UpdatePanel (also in the master page). –  Vilx- Mar 16 '12 at 11:06
3  
Everytime I see an ASP.NET app where somebody puts everything on the page within an Update panel, I feel like throwing my monitor at the wall >.< ! This defeats pretty much the whole purpose of ASP.NET. To maintain server side lifecycle and application events it is necessary for it to communicate back and forth with the entire ViewState of the page. If you have 200 controls and a data grid then it wouldn't take Joel Spolsky to predict you will have massive performance problems. Ed Woodcock and AmmoQ summed up everything perfectly so I have no need to give you an additional answer. –  maple_shaft Mar 16 '12 at 11:19
    
@maple_shaft - But how would you partition it in a sane way? When I look at our pages I can't even imagine where it would make sense to make these UpdatePanel-borders. Place them where you like, there will be some control from outside that needs to update it, not to mention the grand "Save" button which updates everything. Or do you mean to meticulously specify all these relationships with <trigger>s? And another point you just gave - the ViewState is HUGE. How do you intend to get rid of that and still retain a working app? –  Vilx- Mar 16 '12 at 11:28

6 Answers 6

The team I'm in decided to migrate to ExtJS late 2008. We had at that point a 200.000 line PHP app that suffered from front-end issues. Our situation was much worse than yours, because we had a handrolled form controls framework that was really bad, and we had heavy use of iframes to load sections of the page (the visual architecture dated back to 2005, and the team wasn't aware of ajax that early on). We had to refactor the code anyway, so this made it easier to decide to heavily rearchitect the codebase to be primarily client-side.

Today the app is 300.000 lines, of which 60.000 lines are extjs code, and roughly 3/4th of the functionality has been migrated to ExtJS. The extjs code is all a single-page app, but it still embeds some legacy forms inside iframes. We ported over the navigation container first, and then migrated the different feature areas piecemeal. With this approach we managed to slipstream the extjs migration into the regular feature dev process, without slowing us down too much.

  • Performance

    The ExtJS code proved much faster than the legacy code. The old code was ofcourse really bad performance-wise, but even so we're happy with the results. The UI code is all static javascript, so it caches really well (we're in the planning stages of throwing it on a CDN). The server is not involved in the front-end rendering, which reduces the workload there. It also helps that ExtJS provides a lot of control over the lifecycle of UI (lazy rendering, easy unloading of invisible UI elements). Typically once the code is bootstrapped (on-demand loading architecture) most of the load time of a screen is spent in the web service call to fetch the data. The ExtJS grid is really fast, especially when using buffered views for rendering the visible rows on scroll.

  • Ease of development

    To be honest, this one is a mixed bag. ExtJS is a DSL, it's not really web development in the traditional sense. It took our developers a long time to really learn the framework's API, and I don't see this curve being any less steep on other client-side frameworks. Everyone on the team must be a "senior" javascript developer (as a rule of thumb, crockford's book should hold no secrets). We suffer from bootstrapping issues with new developers, because client-side expertise is not as widespread as you would think, and extjs expertise is almost nil (in Belgium, where we are located).

    On the other hand, once you are up-to-speed, the dev experience is very nice. ExtJS is very powerful, so if you're in the groove you can whip up amazing screens very quickly. IDE-wise we use PHPStorm, which I've found to be competent enough with ExtJS code.

  • Security

    Security is one of the main reasons to do client-side UI. The reason is simple: attack surface reduction. The web service API's used by our ExtJS code are a much smaller attack surface than a server-side UI layer is. OWASP's ASVS specifies that you should validate all input on the server for correctness before using it. In a web services architecture, it's obvious and easy when and how to do input validation. I also find it easier to reason about security in a client-side UI architecture. We still struggle with XSS issues, because you're not absolved from encoding to HTML, but overall we're much better about security than we were on the old codebase. ExtJS makes it easy to do server-side validation of form fields, so we don't suffer much from having to write code twice.

share|improve this answer
    
I wish I could do more than just +1 because of your actual experience! –  Vilx- Mar 18 '12 at 23:04

My site is still in its infancy but 100% js ui has been fine for me so far. The only server logic that exists on the front end is model mappings and ajax urls. The server has no knowledge about the ui at all, which to me is very easy to maintain. If you are interested you can checkout my site which is written in ExtJS http://coffeedig.com/coffee/ . My site doesn't really have any security issues but the client helps the normal user by simple validation. I know that a malicious user could really send any ajax to the server so all of "security" logic is done on the server.

I think the biggest problem for you is that you are going be doing a complete reversal of what your team is used to, there will be a steep learning curve. I think the best approach would be to experiment with some js frameworks and try to get the feel of it by writing some simple screens.

share|improve this answer

If you can afford to not support scriptless users, and search engines do not concern you, then yes, it is a perfectly viable approach. Here's a short rundown of the pros and cons:

Pros:

  • everything in one place (javascript)
  • you can load data from the server, not markup, which can save a lot of bandwidth if done right
  • easier to get a responsive application (network latency is still there, but the initial response to a user's input comes faster)
  • the web server doesn't need to render any HTML or expand any templates (i.e., processing effort is moved from the server to the client)

Cons:

  • everything needs to be in javascript (may or may not be an issue)
  • critical logic needs to be duplicated on the server
  • state needs to be maintained on client and server, and synchronized between both
  • security can be harder to get right (considering how anything in the client-side code can be manipulated by malicious users)
  • you expose a large part of your codebase (code that runs on the server cannot be seen from outside)

Personally, I think if you go this route, ASP.NET UpdatePanels are not the right way. They're great for partially ajaxifying existing web applications, but they still send HTML over AJAX, and managing state this way can be pretty hairy. You better go all the way, serving just a static HTML document, and then use a javascript template library to do the HTML rendering; the server doesn't serve any dynamic HTML at all, instead, the client makes business-logic level calls into the server and receives raw data.

share|improve this answer

Use ExtJS if you want to go that way, don't reinvent the wheel. But be prepared, this means a complete paradigm change. You HTML skills are nearly obsolete. AJAX everywhere, the server mostly provides an AJAX API. You will write a lot more javascript than ever, so better make sure you are really fit with javascript.

share|improve this answer
1  
I'm very comfortable with Javascript. I know some other people aren't though. –  Vilx- Mar 16 '12 at 11:15
2  
I did that for several years at a previous job. ExtJS is very nice and you can do a huge amount with it. –  Zachary K Mar 16 '12 at 11:17
    
@ZacharyK - How does it perform on really complex forms? Ones like I wrote there, with several gridviews, tabpanels, etc? –  Vilx- Mar 16 '12 at 11:20
2  
Quite well. you need to think about your data models of course. To be honest I try to avoid huge forms, and compose several smaller elements. But that has less to do with the limits of ExtJS then good design etc –  Zachary K Mar 16 '12 at 11:21
    
@ZacharyK - Too lazy to repeat myself. Read my comment on Ed Woodcock's answer. I can't make it simpler. :( –  Vilx- Mar 16 '12 at 11:33

Linkedin do this for their mobile site (see http://engineering.linkedin.com/nodejs/blazing-fast-nodejs-10-performance-tips-linkedin-mobile part 4), and it's apparently been very beneficial for them from a performance standpoint.

However, I'd suggest you avoid doing the same, for various reasons.

The first is maintainability: C#/ASP.net is, due to it being a server-side framework, client-independent, whereas Javascript is not (even with a framework like jQuery you're not going to get 100% cross-browser compatibility, not future-proofing). I'd say it's also easier to verify the functionality of a statically-typed application than an dynamic one, which is something you absolutely must consider if you're building large-scale sites.

The second is that you're going to find it difficult to find other people who are capable (and willing) to build a pure-javascript application of the kind of complexity needed to run your entire website (compared to the relative ease of finding .NET programmers). This might not be a concern of yours directly, but it certainly is something to think about from a long-term perspective.

The third issue is client-compatibility; if you're building public-facing websites then remember that a reasonable portion of the net still does not have JS enabled (for various reasons), so you'll need to be absolutely sure that you're not going to exclude a large portion of your userbase by switching to a JS-driven website.

As for your bulleted concerns:

  • I wouldn't worry too much about the security aspect, there's no reason why you could not mix paradigms and do some server-side processing when you require security (you're going o have some view-rendering code in there somewhere that returns HTML, there's no reason you can't have this just fire off an AJAX call instead, when required).

  • Ease of development isn't really a concern too, in my opinion, there are very good tools available for JS development, don't just box yourself into VisualStudio because you're used to it! (try JetBrains WebStorm, for example).

  • Performance of JS view engines is absolutely fine in most cases (again, in my experience), I use them heavily on a day-to-day basis. What I would suggest is avoiding the more heavyweight frameworks like knockout.js etc., and head instead for something like Jon Resig's micro template engine. This way you can plug in the supporting code in ways you're confident are fast and reliable.

What I'd do, if I were you, is really examine the reasons behind this switch; It could well be that you're just not leveraging .NET effectively and need to up your game, WebForms isn't a particularly slow framework out-of-the-box, so perhaps some of the 3rd-party libraries you're using are slowing down your rendering.

Try doing a performance profile of the application using a load test and profiling tool, and see where your bottlenecks are before you sink a large amount of time and effort into a more radical solution, you'll probably be surprised at what you find as the culprit for your slowness!

share|improve this answer
    
No, as I already commented on Darknights's answer, this is an internal app, with no (well, little) public-facing portion, so JavaScript-dependency is OK. And I've done profiling. The server side is good. It's the client side that bogs down under the heavy generated HTML (as I said, ASP.NET's generated markup is dismal) and the Devexpress Javascript. –  Vilx- Mar 16 '12 at 11:19
1  
@EdWoodcock ASP.NET web sites are by their very nature Javascript driven. It is how it handles asynchronous communication of the ViewState and page element rendering. –  maple_shaft Mar 16 '12 at 11:22
    
@Vilx- This may come as a shock, but controls like Data Grids are enormously complex. Perhaps you just have too many elements on a single page? –  maple_shaft Mar 16 '12 at 11:23
    
@Vilx- Perhaps it's time to look at your control usage then, if they're generating crazy markup (the default asp.net controls don't in most cases if you're using things like Repeaters instead of DataGrids etc.) then perhaps you should roll your own controls (or move to hand-written HTML in UserControls instead). –  Ed Woodcock Mar 16 '12 at 11:30
1  
@maple_shaft - Or, more specifically Flex, which (as I understand it) is built on top of Flash for exactly such purposes. It's another idea I've been toying with for some time. But... as much as I've tried mentioning this to others, I've only received negative response, so I can't imagine pulling this through. It would also require all of us to learn something completely new. –  Vilx- Mar 16 '12 at 11:59

Yes you can but..

You need to make sure you have graceful "degradation" so that critical parts of your application will still work without Javascript.

This is how I build most apps "HIJAX" style.

share|improve this answer
    
The apps are already javascript-heavy and don't work without it. Our clients are fine with that and have never complained. And, to be honest, I've yet to find a user that has Javascript disabled this day and age. Note also that these applications do NOT need any kind of SEO (it would be a disaster if a search engine could access all that sensitive information), and are NOT intended for use from mobile devices. We're also thinking about making something similar for mobile devices, but that's just in concept stages for now, and we don't even know if there would be a demand. –  Vilx- Mar 16 '12 at 11:02
2  
"And, to be honest, I've yet to find a user that has Javascript disabled this day and age." Well hello then. I have noscript installed so the default for me is to have javascript disabled when landing on a new website. And if nothing works I usually just close the website's tab. –  Arkh Mar 16 '12 at 11:18
3  
@Arkh you are thinking like a programmer not a user, we account for a small minority in the grand scheme of things. Lets not turn this into a "to js or not to js?" because its been done to death around these parts :) –  Darknight Mar 16 '12 at 11:20
1  
People who disable JS are usually well aware that in doing so they may encounter sites which rely on it and thus will not work. Whether they want to enable it for a particular site is their choice, but if they purposely disable a standard technology I don't mind if they are not able to browse a site. On the other hand, I do not know about JS support for screenreaders. That may a be a bigger issue. And of course there is the problem of indexing. But when one wants to make an application that does not need indexing and will not be usable by blind people anyway, it makes sense to rely on JS. –  Andrea Mar 16 '12 at 11:30
1  
maple_shaft I like you, so I will say it nicely, lets not run down that path :) thanks! –  Darknight Mar 16 '12 at 11:33

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.