Today, Web Development Sucks

<i>Write once, run on the continuum between the server and browser, and forget that theres actually a difference between the two. Validations can be shared and server dependent ones can be run there...</i><p>This might be an interesting goal to work towards, but I'm not convinced that one actually wants to achieve it. I'm skeptical that abstracting away the boundary between client and server is a good idea. Unless you're a DRM true believer, there will always be an essential difference: The server is (more-or-less) guaranteed to be running the code you wrote, and the client <i>is not</i>. In the end, unless you are comfortable with allowing an AI to dynamically adjust your application's attack surface for you, you'll always want visibility and control of what gets done where.<p><i>SEO works fine because the page can be rendered entirely server side.</i><p>Are we missing the point that web-based applications and web pages have totally different semantics? The major difficulty with getting Google to index my single-page application is not the need to run multiple rendering engines. It's that Google indexes web pages, and my application is probably not built out of web pages -- not without a great deal of creative thought, anyway. Try to imagine an iOS application that could be fully rendered for Google. How would you do that? Does each possible window and window state get a URL? How should Google index the little popups that appear when the user executes a three-fingered leftward swipe with a twist?<p>The reason why you're writing your views and rendering twice is probably that you need to design them twice. You can either make your users view your app as Google does, as a series of HTML pages at distinct sensible URLs with a minimal amount of Javascript sprinkled on top (which was good enough for 1998, and even 2008, but perhaps not good enough to compete with iOS long-term), or you can design a glorious GUI experience for your users that is largely opaque to Google, or you can do the work twice: Figure out one view of your data that appeals to humans and another that appeals to indexing bots. And that job probably can't be done for you by some magic framework. Figuring out sensible views of your data is design work, for humans.<p><i>A departure from the routing paradigm found in Rails, Sinatra, Sammy, and Backbone. The traditional one URL maps to one controller action routing table no longer applies.</i><p>We didn't converge on this routing paradigm arbitrarily. Among other considerations, it is very strongly influenced by Google, a company that literally <i>pays you money</i> if you design a URL scheme that can be usefully interpreted by Googlebots.

Yes, we thought this in early 2005 and created NOLOH (<a href="http://www.noloh.com" rel="nofollow">http://www.noloh.com</a>) as a solution. You write your app in a single tier, rather than having to worry about all the plumbing (Cross-browser issues, AJAX, client-server interaction, Comet, etc). You can even use your existing HTML, JS, CSS, if you like, and NOLOH then renders a version of your app targeted specifically towards the end user, whether it's IE, Chrome, Mac, Windows, etc. or a search engine robot, in a "lightweight" (only the correct and highly optimized code is loaded for a specific user) and "On-demand" (only loads the resources that are absolutely necessary at a given point) manner, thus allowing for rich web apps like gmail, to load instantly, and as needed, rather than a traditional web fat-client.<p>Every few months someone will write a post like this, and I wince. We've written several extensive articles for php|architect magazine and have presented NOLOH at several major web development conferences around the world. The fact of the matter is that tools like NOLOH exist, there are others, and they can be used now. Today, web development doesn't need to suck.<p>If you're interested in the specifics of the above stated "lightweight" and "On-demand", specifics can be found in the article "Lightweight, On-demand, and Beyond" in <a href="http://www.phparch.com/magazine/2010-2/november/" rel="nofollow">http://www.phparch.com/magazine/2010-2/november/</a>.<p>[edit] Link to free December issue of php|architect article "NOLOH's Notables" so that you can more easily see what I mean without the November issue paywall. <a href="http://beta.phparch.com/wp-content/uploads/2010/12/PHPA-DEC-12-noloh.pdf" rel="nofollow">http://beta.phparch.com/wp-content/uploads/2010/12/PHPA-DEC-...</a><p>Disclaimer: I'm a co-founder of NOLOH

This whole article complains about something simple. Web development sucks, but not because of form validations, it sucks because of IE. But that's another story.<p>&#62; Services must be adapted to spit out JSON data for interpretation and rendering client side, or have their view code refactored to be accesible by fragment for use in AJAX calls.<p>It must be real hard to call your JSON encode function on your data set, that would make it 1 line longer. :)<p>&#62; A radical departure from the jQuery mindset of DOM querying and manipulation, and use a UI kit instead. We aren’t in Kansas any more folks, its time to go where every other platform has gone and use the language to its fullest.<p>People wouldn't query the DOM if that wasn't the most effective way of getting stuff done. jQuery has a UI kit, it's called jQuery UI. And how is using jQuery equals to not using JavaScript to the fullest?<p>&#62; The DOM should become an implementation detail which is touched as little as possible, and developers should work with virtual, extendable view classes as they do in Cocoa,QtGui, or Swing.<p>The author said "using JavaScript to the fullest" and now the author tells us to create "extendable view classes" in JavaScript. JavaScript is a prototypical language, you can't use it to the "fullest" if you force OOP on it.<p>&#62; If we want to build desktop class applications we need to adopt the similar and proven paradigms from the desktop world. Sproutcore, Cappucino, Uki, and Qooxdoo have realized this and applied these successfully.<p>"proven paradigms" is a ridiculous term by itself in software development, putting it in web development context just makes it dumber. If desktop apps are so good, then how come web apps are still around? There is a reason why people still prefer jQuery over many of those.<p>Overall I feel this article is highly biased and the author doesn't really understand web development. The author's complaint's are invalid because the stuff that he is missing are already around.

There are two frameworks that come close to this, both of them are rarely mentioned and I am not really sure why other than the fact that they aren't "sexy".<p>First is SmartClient:<p><a href="http://www.smartclient.com/" rel="nofollow">http://www.smartclient.com/</a><p>SmartClient has the best databinding support I've seen in a JS lib. Binding is automatic between server and client, between controls, and validation code can be written once. It also has the richest UI control library I've seen, full of controls that actually work and aren't just a shiny layer over simple code.<p>Second up is OpenLaszlo:<p><a href="http://www.openlaszlo.org/" rel="nofollow">http://www.openlaszlo.org/</a><p>OpenLaszlo provides a much more raw layer for creating UX on the web, similar to the OP's complaints about not having a UIKit like API. Additionally, it provides a declarative language for laying out controls, and also provides expression binding, so you can say "the width of this element is always 2x the height of this other one" and the binding and event handlers are created automatically. Its declarative language is XML, so there are some nice homiconic properties you get by making it possible to return XML from a web service to generate UI elements. As a bonus, it can generate Flash or DHTML.<p>Edit: Of course, both of these frameworks have their downsides. They're horribly ugly to look at (out of the box.) The declarative language for SmartClient is really ugly Javascript, and the language for Laszlo is really ugly XML.<p>However, they've solved the hard problems and left the "easy" ones. They're both open source. If someone were to come along and clean up some of the syntax and add some real polish to either of these, I think they'd really be remarkable technologies.

We've taken the view that the server side code and the client side UI are two different applications and should be developed as such.<p>We write all the server side stuff as "REST-like" web services and then use whatever makes sense for the UI, whether that is javascript, html emitted from the server, action-script or native binaries.<p>Separation of concerns.

You can still handle your validations server-side in a single-page application. The client JavaScript code sends a JSON packet to the server containing whatever data it needs to process. The server responds with a JSON packet which looks like<p><pre><code> {"status": "ok", "data": ...} </code></pre> to signify success, or<p><pre><code> {"status": "validation_failed", "details": {"email": "malformed email"}} </code></pre> to signify validation failure. Then the client-side code updates the UI appropriately. The client JS code does not bother with validation at all. If this seems wasteful in terms of hitting the server, remember that you have to talk to the server for this task anyway.

This could be extended to say "Today, Development Sucks." Today, not only do you need a web-accessible application to stay competitive, you best develop native iPhone and Android apps. Even better, whip together a native Mac app.<p>You think both client-side and server-side validation is bad? Try developing 4 different client-side applications on different languages and frameworks.<p>Evernote came out and said it attributed part of its success to developing native apps for Android, iPhone and now Mac. Adobe Air and HTML provide an inferior user experience on respective devices.<p>This is also the reason I feel 37Signals is falling into obsolescence. They just launched a mobile "site" for Basecamp. Not an app, but an HTML, mobile-optimized site. Their blog admits to simply wanting to focus at "what they are good at" which is the first foot in the obsolesce coffin. They hired an iOS developer for their Highrise iPhone app, but said they felt the talent should be in-house for future projects. I agree, but their decision, again, was to keep doing the same old thing. Not exactly an innovative, hacker mindset in my opinion.

Strangely he didn't mention server-side javascript, which would be the obvious way to share code between client and server.

Just a small note, but despite the common belief, Gmail isn't written with GWT. Serious web app development seems to result in creating a framework of your own, as your examples show, so I'd agree some useful frameworks would be good, but we have not yet worked out what they should do.

<i>Google built the GWT so they didn’t have to write code twice, but I don’t want to be stuck in the Java world or be forced to learn the whole GWT and make any open source buddies of mine learn it too.</i><p>Groovy/Grails works well with GWT. Idiomatic Groovy looks more like Python than Java. Another possibility is Vaadin, which is built on GWT.

Agree with you on most points.<p>However on some points I'm not as convinced. Take the DOM abstraction, it works and is implemented by several SPA frameworks. You can design good looking, "desktop class" applications pretty fast. But problem arises quickly when your graphic designers send you those PSD mockups, full of great looking artwork waiting to come to life.<p>With a normal DOM approach you've always been able to solve this. With hacking some HTML, tuning CSS and a lot of swearing you pull through. But with SPA frameworks that favor "components" over low-level, raw DOM elements things usually aren't as straightforward. Very often you need to start picking apart the provided "ready-made components" to get any work done. Ends up being very contra-productive and usually takes way longer to do.<p>It has happened to me numerous times before with both GWT and Adobe Flex. Nice and shiny, given you don't try changing the layouts too much. Surely, I'd be one happy camper if this wasn't the case, web development need to move forward. And I hope the goals proclaimed by both Cappuccino and Sproutcore will work in practice some day.<p>Regarding your other point about routing, departing from the route paradigm will be only be true if what your designing is not a document-centric application. In my world, an SPA can be either document-centric or desktop-like (containing a lot of UI state, as you mention). Think the answer to that is the boring "it depends".<p>Worth mentioning, many of these issues are stuff we've been trying to resolve with the Planet Framework (<a href="http://www.planetframework.com" rel="nofollow">http://www.planetframework.com</a>), essentially bridging the gap between client and server.

I'm with him on most of this, but I just can't agree that frameworks like Sproutcore or Uki are good fits for all or even most of the the web apps out there. We've spent years showing off the beautiful things you can do with HTML &#38; CSS and most web users have come to expect that.<p>Sure, the desktop-in-browser approach works in some places, but ignoring standard elements and replacing them with non-semantic, inline-styled &#60;div&#62; elements, and script handlers (e.g. inspect elements on <a href="http://ukijs.org/examples/core-examples/controls/" rel="nofollow">http://ukijs.org/examples/core-examples/controls/</a>) strikes me as cavalier and reminiscent of how SOAP treated HTTP.<p>The DOM is not something to be coerced and abstracted upon: it is the presentation structure for the largest aggregation of human knowledge ever. It deserves some respect! :-)

For validations, at least, there are Rails plugins for checking model validations in the browser (by augmenting the form helpers to generate Javascript which does the checks). For example, <a href="https://github.com/dnclabs/client_side_validations" rel="nofollow">https://github.com/dnclabs/client_side_validations</a><p>This won't work to forward more complicated logic, though. For those who are really feeling the pain, the best cure might be writing the back end using server-side JS, so you can run that code in either environment.

I'm surprised there was no mention of WebSharper in here, it's almost exactly what the author is asking for. And it's implemented in a functional programming language too...