17

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)?

Vilx-
  • 5,320
  • 4
  • 20
  • 24
  • `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 ``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
  • @maple_shaft - I'm sorry if I offended you. Apparently this is a sore spot for you. :( But I really wish to "see the light". And understand how it was meant to be. Yes, I do feel a lot like "going against the grain", but I just can't see how I was supposed to do it the "correct" way. Can you maybe point me in the right direction, please? – Vilx- Mar 16 '12 at 11:46
  • @maple_shaft - Also, just to note, currently the UpdatePanel/AJAX isn't so much for performance, as for preventing the dreaded refresh-button-resubmit and prevent flickering. I can't imagine (for the reasons above) how to use it for performance gains. – Vilx- Mar 16 '12 at 11:49
  • It isn't for performance because page rendering isn't your biggest bottleneck, it is sending and receiving massive requests and responses because of bloated ViewState. Your trying to make a complex fully featured desktop application within a web page. As suggested earlier, RI applications give you desktop app power over the web and this would be a more suitable architectural choice for your requirements. The only other thing I can think of would be to try setting GZip compression through IIS as this can help decrease the request response sizes (if you haven't already). – maple_shaft Mar 16 '12 at 12:01
  • 1
    @maple_shaft - Sorry, but I actually profiled this stuff. It was/is slow on local developer computers too, and Fiddler clearly showed that the HTTP connection was opened for less then a second, while the page only appeared several seconds later, and all the while the browser was using as much CPU as it could get and was basically frozen. That's not bloated Viewstate, that's bloated HTML/Javascript. – Vilx- Mar 16 '12 at 14:30
  • ASP.NET webforms is your performance bottleneck, switch to something that doesn't suck. If you have to stick to .NET use [Nancy](https://github.com/NancyFx/Nancy) – Raynos Mar 18 '12 at 00:27
  • @Raynos - Dude, just... read the previous comment right before yours. I'm getting tired of repeating the same stuff. – Vilx- Mar 18 '12 at 22:22
  • @Vilx- I'm implying any architecture provided by ASP.NET will be inefficient, ASP.NET is large and bloated, you want performance, go close to the metal. It's not hard to be close to the metal with HTTP, HTML and JS. It's just something you have to do – Raynos Mar 18 '12 at 22:26
  • @Raynos - this whole Stackexchange thing is built on top of ASP.NET (ASP.NET MVC, to be precise). I've yet to see a performance problem. – Vilx- Mar 18 '12 at 23:07
  • @Vilx- competent developers can write performant applications with any mediocre technology, facebook runs on PHP and is performant. Sure you can do it with ASP.NET but enjoy fighting against the tool at every step – Raynos Mar 18 '12 at 23:36
  • @Raynos - And what would you suggest? C/C++? Because I cannot honestly think of any other language/environment that would be "closer to the metal" and more performant. As far as platform choices go, C# is pretty close to the top, I think. Java would win on the portability, but the rest of them ("them" = popular web-development languages today) are interpreted languages which will have worse performance by definition. – Vilx- Mar 19 '12 at 01:21
  • 1
    @Vilx- there's nothing wrong with C#/.NET (Apart from windows only / cost). There are big problems with the bloat that the ASP.NET WebForms frameworks puts on top of it. As mentioned try Nancy if you like .NET. But this is completely off topic, it was just a comment that you would fare better off if you stopped using webforms – Raynos Mar 19 '12 at 01:28
  • @Raynos - I know, I'm not fond of webforms myself, and my colleagues agree about the bloat. We will already be exploring the viability of MVC. Hence this question - how far should we take the MVC. As I stated previously, I do feel very fond of the "widget" concept. Business forms like we make are all so much alike, that it should be possible to churn them out at great speeds. Spending hours on each form, manually tweaking the HTML/Javascript, seems like the wrong direction to me. – Vilx- Mar 19 '12 at 08:41
  • @Raynos - The way I see it, you should be able to just write a little markup with the controls needed (similar to the webforms .ASPX), write a bit of code for that "individual touch", and move on to the next form. Ideally you won't need to think any more about UI programming than just picking and arranging the few controls that you need. In fact, I do suspect that Webforms could also be a quite fine platform, if it had a good set of thoroughly thought-out controls. – Vilx- Mar 19 '12 at 08:44
  • let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/2829/discussion-between-raynos-and-vilx) – Raynos Mar 19 '12 at 11:59

6 Answers6

10

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!

Ed James
  • 3,489
  • 3
  • 22
  • 33
  • 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 James Mar 16 '12 at 11:30
  • @maple_shaft - I'll drink to that, but alas - it's beyond me to change that. If a "document" is complicated enough that all this stuff is needed, then I need to represent it to the user. I can split it into several tabs on a tabpanel, in hopes that it will make things lighter, but they do need to be all there. – Vilx- Mar 16 '12 at 11:30
  • @maple_shaft - To clarify a bit, the ERP system I'm writing against has this concept of a "document", and our forms map pretty much 1:1 on these "documents". – Vilx- Mar 16 '12 at 11:32
  • @maple_shaft Nope! ASP.net sites don't require Javascript at all; some controls do, which is a very important distinction. Obviously if you're using something like UpdatePanels then you're going to see "better" results with JS on, but you do not need to have javascript on to view a .net site. Viewstate is just a hidden field that's used for various validation operations (it doesn't get changed client-side, in fact it is required not to IIRC), and I'm not sure what you're referring to as "page element rendering". – Ed James Mar 16 '12 at 11:34
  • @EdWoodcock - True, but it gets really difficult really fast to do without Javascript. Plus, the rich UI that is required (our clients practically want their windows application ported to the web) would make it a hell for anyone to try and do without Javascript. – Vilx- Mar 16 '12 at 11:38
  • @Vilx- Yeah, I'm in the same boat, semi-internal system (fixed userbase) with requirements that would be a better fit for a desktop app, you definitely need JS for that kind of situation. By the sounds of your comments on the actual question you don't need a switch to full-js though, just a switch in development style. Have you considered moving to MVC? That could be done inside your existing .net app, and would help fix some of the issues you're having with excessive HTML generation. – Ed James Mar 16 '12 at 11:47
  • @Vilx- You have massive pages and controls with more polygomous relationships than a cult, and you openly admit that this *cannot* change. Even if the design could change, it sounds so hopelessly complicated that it would constitute major refactoring. I am going to be straight up honest with you then and not charge you my typical consulting fee, ASP.NET was a **BAD** choice from an architectural perspective. If you are looking to refactor, then I suggest avoiding JS, HTML based frameworks altogether and go for Rich Internet Applications. Look at Silverlight + WCF/RIA web services. – maple_shaft Mar 16 '12 at 11:49
  • @maple_shaft I certainly don't agree about the silverlight point (someone making that decision has bitten me in the butt before), it's really just a question of how you go about solving the issues with the web-based approach that dictates your success. There's plenty of ways to mitigate the issue of heavy html and stateful functionality that don't involve plugins. – Ed James Mar 16 '12 at 11:54
  • @maple_shaft - Can't say that I'm proud of that choice. And I don't want to refactor it overnight either. I'm just trying to figure out, in which direction to move. I'm not sure Silverlight would be much appreciated among our clients, since it has to be separately installed on each client machine, which is exactly why they want the web in the first place, and not a typical desktop application (which we already have, btw). But Flash might be acceptable, since that's almost everywhere by default anyway. – Vilx- Mar 16 '12 at 11:56
  • 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
8

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.

user281377
  • 28,352
  • 5
  • 75
  • 130
  • 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
  • In terms of complex interfaces it does quite well. If you go to their website they have a lot of demos you can try including some pretty fancy forms. I have done things like you describe and ExtJS kept up no problem. BTW ExtJS also has very nice documentation – Zachary K Mar 16 '12 at 12:26
  • Vilx: In general, working with ExtJS results in a web-app that looks and feels mostly like GUI. Our application uses a really sophisticated layout, nested tab panels, grouped tab panels, with countless grids. Performance is good, even in IE. The only thing that notably slows it down is a large grid with several thousands of rows, all shown concurrently (with scrolling, not paging). – user281377 Mar 16 '12 at 13:46
  • My answer was turning out too similar to this, so I'll comment. You can also look at some some similar libraries, like backbone.js and underscore.js. For large grids SlickGrid really is slick, it dynamically creates/destroys the visible HTML in an intelligent way. Also, I've given up on server side controls and just provide a JSON API. It's so much more straightforward than ASP.NET., easier to test, harder to write injection attacks into JSON. – psr Mar 16 '12 at 18:20
  • @Vilx- Regarding not everyone being comfortable with Javascript - you are writing a web app with features that require Javascript. If you stick to ASP.NET controls and let Microsoft handle the big scary web stuff you will be stuck with what Microsoft gives you. I'm probably preaching to the choir in your individual case, but your coworkers need to move out of their comfort zone if you want to do a better job. – psr Mar 16 '12 at 18:37
  • ExtJS is good. Dojo is also free... – Daniel Voina Mar 17 '12 at 20:11
  • Use generic library X (which is not free) is not the solution to your problem – Raynos Mar 18 '12 at 00:29
  • @Raynos, I don't think that is always true, if spending $500 will save me 2 weeks of work it is worth it (of course deciding if that is the case is another story) I have found ExtJS to be a good solution to some problems and would use it again in a case that fit into that space – Zachary K Mar 18 '12 at 04:59
  • @ZacharyK The issue here is "use library X" is not the answer, it's a subset of the tools you would use to solve the problem. It's like answering "how do I select elements?" with "use jQuery" – Raynos Mar 18 '12 at 05:10
  • @Raynos - I don't see him advocating ExtJS as a panacea, but as just that - a tried and trusted tool in your toolbox. – Vilx- Mar 18 '12 at 23:05
  • @psr: Using the BufferView extension, ExtJS grids can dynamically create/destroy html too. – user281377 Mar 19 '12 at 07:25
  • @Raynos: I fail to see your point. OP asks about creating a 100% javascript web UI. That's exactly what ExtJS does, in a IMO very sophisticated and matured manner. Trying to do the same without the help of any lib would be inefficent at least. There may be other libs doing the same trick, an I hope to read of them in the answers, but ExtJS is the only one I use daily, so I can say something insightful about it. – user281377 Mar 19 '12 at 07:30
  • @ammoQ whether ExtJS is a useful tool (it's not) is a seperate conversation. The point is your recommendation of a tool should be a comment not an answer. – Raynos Mar 19 '12 at 12:01
  • @Raynos: I beg to differ. IMO ExtJS is great. You might be right that my answer should be a comment, though. – user281377 Mar 19 '12 at 13:19
8

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.

Joeri Sebrechts
  • 12,922
  • 3
  • 29
  • 39
3

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.

tdammers
  • 52,406
  • 14
  • 106
  • 154
1

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.

Darknight
  • 12,209
  • 1
  • 38
  • 58
  • 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
  • given those circumstances, you *may* be able to not have to worry about having a fall-back. However it is usually advisable to have a fall-back when ever possible. – Darknight Mar 16 '12 at 11:06
  • I know, but with the rich UI required, I don't think it would even be possible. – Vilx- Mar 16 '12 at 11:11
  • 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
  • @darknight I would say that having a fallback is important in a web page style setting, but less so in an application type setting. It really depends on the customer and what they want/need. – Zachary K Mar 16 '12 at 11:19
  • 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
  • My Blackberry browser has JS disabled and extreme privacy advocates still disable it. Non-JS users are still very much alive and well in the world. – maple_shaft Mar 16 '12 at 11:26
  • 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
  • @All I agree, lets not go down this path because it is an offtopic (although interesting) conversation. The chat rooms are open for those who would like to talk about it. – maple_shaft Mar 16 '12 at 11:53
  • @Darknight I'm not thinking like a programer by not having js enable by default. I'm thinking like a user who don't disable security measures on his rig. – Arkh Mar 16 '12 at 14:45
  • Deciding to go a full JS route with no fallbacks has some costs, in that you will loose some people and may have more bandwidth in some cases. But deciding to have fallbacks for everything also has a cost in that some features may not be doable that way and others will have to be implemented twice. Which way you go on that depends on a lot of non technical factors. – Zachary K Mar 18 '12 at 05:01
1

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.

pllee
  • 1,212
  • 1
  • 9
  • 13