Web apps are dead, long live web apps
blog.gaslightsoftware.com
blog.gaslightsoftware.com
Like, why is AJAX/client-side MVC pointed out as something that overcomes the HTTP request/response cycle? No, it doesn't. It just means you don't have to refresh the entire screen every time a request is made. Whether the server now sends back "a wad of HTML/javascript" or some JSON to be parsed by the Javascript MVC framework du jour, nothing you are doing is transcending the HTTP protocol either way. AJAX changed the way users interact with web applications, but it did not change anything really fundamental about their architecture.
Second, Coffeescript does not liberate you from Javascript. It IS Javascript. It makes it easier to control some of Javascript's difficult areas, like the meaning of "this" as execution context changes as one example, but it doesn't suddenly give you license to write browser code the way you would write Python or C++.
In any case, let's not confuse convenience with paradigm shifting.
The best way I've heard coffeescript described is as a better syntax for javascript. Though at first this may not seem like a big deal, in my experience it's been a huge deal in the effect it has on how I approach client side code. Now that I can write code I really love on the client, it's greatly lowered the barrier for me to do so.
As for Coffeescript, anything that tames some of the nasty bits of Javascript is fine by me. I don't dispute Coffeescript's usefulness. My point was just that Coffeescript is like syntactic sugar for Javascript, not a paradigm shift in client side coding.
The way I write web apps these days is to have static javascript code, that contacts a web service to fetch its settings, and to load the data to be edited. Then it performs all editing client-side, without contacting the server. When it's done, a single save() method call to the server persists the data. That the communication occurs across HTTP is almost irrelevant.
That's eerily familiar to the desktop apps I've implemented. In a sense, it's a paradigm shift back to the way stuff used to be built, except there is no dll hell, because the client always has the latest version of your "executable".
The relative balance of the work may have changed, but I don't see it as a revolution except in terms of user experience, where AJAX has definitely drastically changed the way users perceive a web page.
Otherwise, the development model of HTTP - the server sends me something, I send a reply, and it sends me back something else - is still alive and well. That's to be expected, since browsers were built with HTTP in mind and the supporting technologies, Javascript included, all must live within that box. The server is still intimately involved with the behavior of the page, but its involvement is encapsulated into individual actions rather than an entire page load (i.e. the server returning an error can be responded to in the context of the HTML form that caused it, rather than with a page redirect or some such). Again, I don't deny that's a helpful thing.
Substance: the actual matter of a thing, as opposed to the appearance or shadow; reality.
This piece is hype. Those that push off hype as substance are swindling your valuable time and are basically saying "come on everyone, let's hope on board the train and base our infrastructure off of unproven, new shit." Which is fine; but only because most of these people are just writing the same social shopping website over and over again; and will do so until the next hyped idea makes its way into the business world.
- URIs, i.e. ability to connect all the documents on the Web. - Standardized UIs that are easy to create. - Security. You don't need to execute unknown code to load a page, yet you can use web interfaces to do a lot of different things. - Control an transparency for the users. Browser is your software, you decide what it will and won't do.
With the increased used of heavy JS clients, most of these benefits are fading away.
An article I'd love to see is something expounding on that analogy.
Admittedly, that helps with security, but when you're making something trivial, it's not necessary to push all of the traffic back to the server to get session variables, templates, and the like.
It doesn't have to be hard. I'm currently using Backbone in a project. I added OpenStep/Cocoa's autoresizing masks to Backbone.View and now layout is a breeze. The CSS layout model actually lends itself really well to this if you're willing to use JS to do the calculations.
Then it dawned on me: the DOM and CSS API's simply aren't meant to be used directly. They're like the X11 API. You need to wrap them into something saner to make sense of them. After that I adopted ExtJS. It puts a cross-browser wrapper around the browser API's, with its own component and layout system. Way easier to program with.
Sproutcore is much more powerful. If you haven't checked out 2.0, you really should. I've been following it for years and always thought they had the best KVO system but avoided it due to the js-based layout and enormous size. The 2.0 version binds to handlebars--slightly extended mustache--templates instead of relatively opaque widgets and reduces the wire size to right around the size of jQuery. It's larger than backbone and you have to wade through more concepts but you add an object to an array and the dom updates without any further input. Eliminates the majority of dom manipulation code in your app.
In SproutCore 2, you'll have very specific DOM elements and attributes observing very specific properties of JS objects. Here's a flavor of the Handlebars.js that connects a view to models:
{{#collection contentBinding="Todos.todosController"
tagName="ul" itemClassBinding="content.isDone"}}
{{view SC.Checkbox titleBinding="content.title"
valueBinding="content.isDone"}}
this.model.bind("change", this.render);
this.notes.bind("add", this.addNote);
The problem I ran into was composition. It could have certainly been my failure in design but when I started trying to nest views inside other views I found myself unable to just do a innerHTML (i.e. dumb/idempotent) .render() call and instead wound up writing a significant amount of DOM manipulation code to get things working. It's been a few months and the details of exactly why this happened escape me but that's the general outline. The obsessive focus in SC on converting EVERYTHING to a model attribute change altered my thinking process for KVO so maybe I could now use backbone the same way.
My impression (since I still haven't done SC2 for more than toy projects) is that the more declarative nature of SC's approach yields cleaner composition. In theory, you should be able to do the same thing with both systems but in practice I found myself having trouble.
Web apps can be cached locally. Web apps can run in PhoneGap or Prism and have access to your desktop. Sure, they aren't for everything. But having a common platform of HTML and Javascript and CSS is actually pretty great, especially for hiring purposes!
The native bindings can be extended either using drop-in plugins or by hiring native developers to do really well defined tasks. Which once again is good news for both stability, speed of development, and hiring.
I believe that if we don't recognize the fantastically valuable feature, then the rush for 'richer' 'user interfaces' (UIs) and 'better' 'user experiences' (UXs) will get rid of this fantastically valuable feature.
Yes, UI/UX are IMPORTANT. Okay, I accept that.
BUT here's the fantastically valuable feature we just MUST retain: I explain the feature with two examples.
First Example -- Microsoft Word
While I can't speak for anyone else, I work hard to avoid using Microsoft Word. Several times I've used it, learned its UI well enough to get my work done, and rushed to f'get about Word and its UI.
Instead, for my high quality word whacking, I use D. Knuth's TeX that I find MUCH easier to use. Why easier? The documentation is rock solid, a jewel of software documentation. The software has a 'conceptual model' well explained in the documentation; with this conceptual model, it is fairly easy to understand what is going on. What TeX does is actually quite reliable and predictable and as explained in the documentation. Word is DIFFERENT.
I hate the Word UI/UX. For me, for each significant new usage, the UX is sometimes yelling and screaming in frustration. When I want to do something new to me, there's no solid documentation and no good 'conceptual model' for how Word works. So, I don't really know how it works. So, when I want to do something, I go around on the screen and left click, right click, double left click, double right click on everything in sight and see what happens. Commonly I type in something, get it as I want it, and then for no reason Word just throws away what I did. After a dozen times of such efforts throwing my work against the wall of Word to see what will stick, I start screaming. I HATE Word and all of its intended UI/UX.
Maybe if I got and read the documentation for how to write macros for Word it would make more sense, but as far as I know I would have to pay for that documentation. Besides, did I mention, I HATE, deeply, profoundly, bitterly hate and despise, Word?
My view is that it takes at least two weeks of full time work for someone to get good facility with Word.
Second Example -- 100 Million Web Sites and One Billion Users
As we all now know very well, there are something over 100 million Web sites on the Internet and about 1 billion users. And, nearly any user can use nearly any Web site in their language right away.
So, somehow Web apps save the two weeks of full time effort for each of 1 billion users for each of some hundreds of Web sites they might visit.
That is, HTML is SIMPLE, DIRT simple. Nearly all Web apps built with just dirt simple HTML have a fantastically valuable feature:
Nearly any one of 1 billion users can use the Web app right away.
The Web app UI/UX has this feature, and Word does not.
Why do Web apps have this feature? Because HTML is DIRT simple. Yes, commonly there is a round trip to the server for each little step in the user's work. Right. So, there's a minimum of subtle, dynamic, pop ups, pull-downs, roll-overs, drag and drops, hidden 'side effects', and big changes in the state of the user's work from small actions. Not much is hidden or mysterious. There is minimal need for documentation. The UI/UX is NOT 'rich' -- thankfully.
To layout a page, mostly use just tables and/or divisions and nothing more complicated. So, the screen presented to the user is relatively simple, easy to understand, and much the same from one Web site to another. E.g., the designers of Word may have spent some thousands of person-hours designing each little part of each screen. The resulting complexity is forbidding -- huge BUMMER. With just simple HTML, it's just not practical to implement such complexity -- THANKFULLY.
With just simple HTML, for what we could let a user do, about all we got was (1) to follow a link, click on an image, (2) click on a button, (3) click on some radio buttons, (4) type into a text box, (4) move text to/from the system clipboard, (6) use the key TAB to move the cursor to the next text box, (7) hit the key ENTER in a text box. SIMPLE. Over 100 million Web sites have the 'controls' links, buttons, text boxes, etc.; all of these controls work very much the same on all the sites -- TERRIFIC. When a user clicked on some button, say, "Submit" or hit the key ENTER, the data the user entered was sent to the server, and the server responded. SIMPLE. Any user with any browser can use nearly any Web app right away. FANTASTIC.
Now, if we work at it, say, with much more powerful client side programming tools, then we will be able to build Web apps with a 'rich' UI/UX. We can have dynamic this, subtle that, automatic these other things, asynchronous who knows what, guess and anticipate what the user wants and do it for them as a 'favor', drag and drop, overlays, full motion, and on and on.
We can have rivers of functionality that are subtle, bug ridden, undocumented, not obvious, and, at each site, unique on all of the Web. BUMMER. E.g., I'm still screaming bloody murder at the whole theme of 'icons' because those little images are not English or any natural language, can't be spelled, pronounced, or looked up in a dictionary, and are documented usually at best poorly. Sickening. I HATE 'icons'.
Then, sorry guys, in practice, nearly all Web apps will (1) be much more expensive to develop, (2) will have many more security problems, (3) will be much less compatible with all the common browsers, (4) will usually become a total pain in the neck to learn to use, and (5) will lose the fantastically valuable feature of ease of use, right away, for any of one billion users.
Here's the truth: The UI should be simple, stay simple, dirt simple. The work on the server side might be fantastically complicated, but for the user the concepts of what they want, what data they enter, and what data they get back should remain SIMPLE.
As it is, HTML is so simple it's tough to mess up the UI. With much more powerful client side software tools, it will be tough NOT to mess up the UI.
Be careful about what you wish for because you might get it.
At least be very aware and careful with the fantastically valuable feature of Web apps built with simple HTML.
Any user with a web browser and Google Analytics will have to learn about how to use all its features, hell there are even expensive training courses on it!
Whether it runs in a browser or is an application isn't relevant to how easy something is to use.
Sure, in principle and often in practice can make a mess out of a Web app and can have something nicely simple in a native app.
But your "isn't relevant" is too strong for practice: Again, HTML is a big constraint on what the programmer can do, and this constraint, in practice, forces a lot of simplicity, i.e., ease of use or, if you wish, relatively 'uniform' techniques of use across millions of Web sites with the advantage of learn once, use thousands of times.
Also, your example of Notepad is relevant: Actually, as simple as Notepad is, the average Web app is still significantly easier to use if only because Notepad is nearly unique and there are over 100 million Web apps that, via the constraints of HTML, all work very much the same. So, one billion people can use over 100 million Web apps from learning how to use just a few of them, but nearly all those one billion users would have still more to learn just to use Notepad for the first time. Native apps are so unconstrained they are free to be highly idiosyncratic: Sure, maybe for an app as simple as Notepad the learning time is short, but Notepad is not like an HTML Web app and,thus, needs ADDITIONAL learning time, even if only 5 seconds. In the world of the Web, the 5 seconds learning time unique to one Web site is TOO MUCH.
Again, this uniformity and ease of use pushed hard by the simplicity of HTML is a BIGGIE for the current size and future growth of the Web, and more complexity in client side programming tools is a threat to such growth.
Jeff Jaffe, listen up!
>I believe that if we don't recognize the fantastically valuable feature, then the rush for 'richer' 'user interfaces' (UIs) and 'better' 'user experiences' (UXs) will get rid of this fantastically valuable feature.
>As it is, HTML is so simple it's tough to mess up the UI. With much more powerful client side software tools, it will be tough NOT to mess up the UI.
I agree with where your post is going, but unfortunately we've already made all those mistakes, already lost all the niceties of the web. Our stateless, linked-document viewer is already dead. HTML isn't dirt simple anymore. For years a "web-app" has already has all those undesirable properties. We've made the browser environment complex. The hardest to use applications I have these days are webapps. And when it became complex we didn't give ourselves any of the niceties of native applications, so they're even more of a mess than native ones.
Yes, building a Web site can be as complicated as we please: I'm buiding one now, my first one, and I am surprised at how much there is to it. So far all the work is just routine, but in total there is a LOT to it. E.g., my main Web page where a user enters some data has 160,615 bytes of typing and may top 200,000 before the page is done. I see the page as 'simple', and I hope my users will, but not everything can be simple about 200,000 bytes of typing. Yes, at 50 characters per line, that would be 4000 lines or, at 50 lines per page, 80 pages printed out!
Still, compared with a 'native' application, in practice HTML heavily constrains what a programmer can do with a user interface. So, an HTML interface is constrained to be relatively simple.
My main point remains: In total, one billion Web users can use any of over 100 million Web sites right away. That's a BIGGIE.
In the Web site I'm developing, I'm going with Microsoft and Visual Basic .NET,.NET, ASP.NET, and ADO.NET. Yes, ASP.NET writes some client side JavaScript for me. Fine with me. But so far I have yet to write a single line of JavaScript and intend to keep it that way!
But if do a lot of client side programming in JavaScript or any more capable successor, then risk programmers having fewer constraints, user interfaces becoming more complicated or, just, unique to each Web site, ease of use of the Web for a billion users going into the toilet, and the Web growth being throttled.
For my Web site, the user interface is SIMPLE. Yes, for each little thing a user does, there is a 'post back' and a 'round trip' to my server. Sure, something native could be 'snappy'. But I'm taking the approach, KISS. And, sure, each round trip lets my Web site put up a different collection of ads! For my most complicated Web page, what my server sends is less than 200,000 bits, and that can go to a user and be displayed VERY quickly. So, my site can appear to be nicely responsive.
Some of what's going on deep inside my servers is complicated, but the user interface should be so simple that people who don't know English should be able to use an English language version of my site! I'm drooling over the fact that one billion Web users will find my site easy to use, if they want to use it!
Net, I recommend that we keep the HTML Web UI SIMPLE.