
Web apps are dead, long live web apps - joshowens
http://blog.gaslightsoftware.com/post/10859784934/web-apps-are-dead-long-live-web-apps?utm_medium=hackernews
======
abrenzel
Some things from this article just don't make sense to me.

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.

~~~
gaslightchris
The important difference I see in the approach used by backbone is it gets us
away from having the server be in control of navigation and UI events. After
the initial page load, I'm exchanging simple data as json with the server. It
wasn't HTTP I was arguing with, it is having a server side framework managing
the UI navigation.

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.

~~~
abrenzel
I just see this as an incremental development, rather than a revolutionary
one. As I mentioned above, the server is still very involved with UI events
and navigation. If the user causes a UI event that saves data to the server,
even if there is client-side validation it will often be the server that
responds with an error and forces the page to do something with that. The nice
thing is that we now get to encapsulate the server's influence on the
application into definable actions, rather than by a single request. That's a
rather good thing for us developers, but it is still well within the bounds of
the traditional HTTP model.

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.

------
kristopolous
Hype: A clever marketing strategy which a product is advertized as the thing
everyone must have, to the point where people begin to feel they need to
consume it.

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.

~~~
joshowens
I am glad you were around to debunk the "hype" and steer us straight for all
our social shopping website coding needs!

------
romaniv
Does the article's author realize that the HTTP's request-response model
wasn't some technology limitation of old times, but conscious and pretty
sensible design that led to current popularity of the web? Here is what it
allowed:

\- 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.

~~~
joshowens
I would disagree, the article never said do away with server side security or
anything like that. I don't think it said anything about ditching URIs either.

~~~
icebraining
Security is for the _client_. And ditching URIs is often a direct consequence
of using AJAX to load the document dynamically, since the current URL doesn't
represent the current document anymore.

------
scarmig
tldr: "Client side code is awesome with backbone.js and CoffeeScript! Come to
our seminar!"

~~~
merijnv
tl;dr: Let's all reinvent an even less standardised X11 in JavaScript and
HTTP!

~~~
scarmig
Heh, is that that terrible?

An article I'd love to see is something expounding on that analogy.

------
MarkTraceur
Good points--but it looks from my limited knowledge of web frameworks like
most people aren't even using AJAX, much less to its full potential. Maybe I'm
wrong, but it seems like Flask/web2py and other MVC frameworks are more
interested in keeping track of things on the server, not pushing things to the
client.

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.

------
ebiester
I thought the biggest complaint was still the endless checking on platforms
(IE 6, 7, 8, 9, Firefox, lynx...) and the difficulty in layout (negative
widths, anyone?) Try three resizable columns sometime! (I'm still trying to
figure out a solution to this one. Even the new layouts of CSS3 break in funny
ways.)

~~~
joshowens
Only if you are a designer, which I am not. I am guessing the article writing
isn't either.

~~~
ebiester
How many web designers are exclusive front or back end anymore?

------
grayrest
> Backbone.js is the best client side MVC framework I’ve used, but there are
> certainly others.

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.

~~~
jashkenas
I had the pleasure of discussing all this with Yehuda last week, but the
reason why Backbone doesn't try to do full keypath-KVO-with-template-binding-
and-ArrayControllers etc. isn't because the end goal is so very different, but
rather because there's a difference of approach in how fine grained your Views
are with respect to the DOM.

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"}}
    

Whereas in Backbone, you'll tend to allow coarser grained views -- logical
chunks of UI and DOM -- to update all together, whenever the underlying model
changes. Here's a flavor of the view code that connects to models:

    
    
        this.model.bind("change", this.render);
    
        this.notes.bind("add", this.addNote);
    

The end result of both is that you'll be able to add an object to an array,
and the DOM will update without any further input. But the style in which you
get there is different.

~~~
grayrest
I don't mean to disparage backbone. It's simple in both design and
implementation. I had my own KVO system I was using on a project when you
announced backbone and I wrote a 10 line patch to add computed attrs and
dropped my system for yours.

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.

------
snorkel
There's only so much business logic you can push off the client. If the app is
mostly in the client seems like that'd be adding a whole new level of
complexity to how to seamlessly deploy new versions, model changes, etc.

------
EGreg
Disagree.

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.

------
evanwalsh
I was prepared for a link bait blog post and I ended up getting a quality
piece of writing. Pretty good.

~~~
AdamTReineke
I disagree. Basically he says he loves Backbone and CoffeeScript because they
remove the headaches of Javascript and "chatty web-apps", but doesn't get any
farther than that, instead plugging his company's training class.

------
alexholehouse
Content irrespective, that's some difficult to read text...

------
NY_Entrepreneur
'Web apps' have had a fantastically valuable feature nearly never mentioned.
If we make big changes in how a Web browser client interacts with a Web
server, then we risk getting rid of this fantastically valuable feature and
seriously hurting our Web apps and the growth of the Web.

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.

~~~
cbs
>'Web apps' have had a fantastically valuable feature nearly never mentioned.
If we make big changes in how a Web browser client interacts with a Web
server, then we risk getting rid of this fantastically valuable feature and
seriously hurting our Web apps and the growth of the Web.

>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.

~~~
NY_Entrepreneur
Sure, it's possible to write some really bad Web apps. E.g., at my bank, they
keep changing their Web site so that once each few months I have to click and
click and click to look for where they have moved the page to let me download
the PDF of my bank statement. Their 'navigation' is NOT clear.

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.

