
Rich client side web apps gone too far (2014) - zo1
http://chase-seibert.github.io/blog/2014/05/30/rich-client-side-web-apps-gone-too-far.html
======
chewxy
I have complained about similar things way too much on twitter as well.

A VAST majority of websites on the web serve CONTENT. Why is JavaScript needed
to serve content is really beyond me. You don't need to make your blog look
and feel more webapp-y. It's a blog post. I want to read content. I don't use
other features on your blog. Please just serve me the content and don't try to
SPA that shit. Heck, I'd be willing to bet 99% of websites out there don't
need to store session information to begin with - a static website would have
served as well.

And most interactions on any website are not worthy of making it webapp-y
anyway. Most websites with interactions will do well with minimal interactions
anyway. Not every website needs to be real time. The existence of a listening
loop in a lot of websites has caused my MacBook to crash more than I can care
to count.

OK, sure, webapps like Asana and Gmail have good reasons to use and push the
use of JavaScript forwards, but I really don't see why websites like AirBNB
would require JavaScript. It's a bloody classifieds website. Out of the top 10
most visited websites I use, I can see only 3-4 of them really needing a fancy
JS frontend. The others can get by with much much better UX if the JS in the
frontend were kept to bare minimum.

Does JavaScript enhance the experience to the non-power users? I am not sure.
Is not seeing the white flash when a page loads really that necessary to
improving UX? I've definitely heard way too many complaints about JavaScript
assisted scrolling amongst the non-tech acquaintences I have. I also have
definitely heard complaints about bloated webapps that cause the entire
computer to slow down.

The sad thing is with our modern browser technologies, we can be doing so much
more, but webdevs tend to chase the fashionable, leading to generally poorer
experience.

What's worse is our addiction to fashionable JavaScript things have caused us
to design hacks on top of hacks on top of hacks. When will this madness end?

edit: fun stuff - according to htop, my Firefox, which has one tab open
reading a blogspot page, is using about 12% of my memory. Amazing.

~~~
javiercr
Airbnb has tons of things that would be impossible (or annoying to use)
without JS: search by map, sliders, availability calendars, price calculation,
credit card tokenization, etc.

Here is a recent talk where they explain how they solved some tricky UX
problem by using a "modern" JS framework such as React.js

[http://www.infoq.com/presentations/airbnb-resolution-
center](http://www.infoq.com/presentations/airbnb-resolution-center)

In this other talk they also explain how (and why) they evolved from vanilla
Rails (i.e. more static HTML) + jQuery, to Backbone, and finally to isomorphic
React.js

[https://www.youtube.com/watch?v=gMvvb6F8dgk](https://www.youtube.com/watch?v=gMvvb6F8dgk)

~~~
chewxy
Fair enough. Those features do indeed warrant the use JavaScript. Not quite
convinced that it needs to be super bloated JS, but since I've somehow managed
to miss all those features, I must be missing something. Thanks for educating
:)

------
carsongross
His criticisms of Javascript are, of course, correct. It's a huge mark of
shame for the technical community that we've allowed this language to "win".
Bafflingly, people who even suggest that the hacks-upon-hacks we've had to use
for even basic software engineering techniques like namespacing are just that,
hacks, routinely get shouted down. The whole thing will make an interesting
sociological study at some point.

From the article:

 _" Javascript used to be a tool that you used as sparingly as possible,
sprinkling just the barest hint of dynamic behavior where it was absolutely
necessary. Now it's common to start a new project and assume that 50% or more
of the code will be Javascript."_

I know I've been asked to cool it on the pimping, but this is exactly what
intercooler.js is designed for: you don't need to write much javascript for
the dynamic behavior you want 99% of the time.

~~~
gradstudent
> I know I've been asked to cool it on the pimping, but this is exactly what
> intercooler.js is designed for: you don't need to write much javascript for
> the dynamic behavior you want 99% of the time.

JavaScript is a clusterfuck. More Javascript is not the answer.

~~~
carsongross
Which is exactly why intercooler.js uses plain HTML attributes, rather than
javascript:

[http://intercoolerjs.org/](http://intercoolerjs.org/)

~~~
curiously
very cool! although I feel more comfortable with using jQuery for posting.

------
gingerrr
can we stop conflating the presence of tons of bad practices in the wild with
flaws in JS as a language? every language gives you ways to shoot yourself in
the foot (c++ anyone?), if you choose to pull the trigger it's not the
language's fault. i may not have been writing JS as long as this author (8
years to his 12) but I got over the ambiguity of `this` values 7 years ago.
languages exist to provide a specific set of functionality - in this case,
dynamic scope resolution - it's frustrating to see bad design choices in app
code blamed on the language. vm authors are open with the optimizations
they're making, just write your JS to leverage that performance gain

~~~
mattdeboard
I mean, his assertions are right. JavaScript is objectively not a well
designed language. That said, he still asserts that JavaScript acquired a
reputation worse than it deserved not because of its design decisions but
because of the platform it was targeting (the browser).

Your comment reads like a reflexive defense of JavaScript since "javascript
sucks" wasn't even the point of the essay.

~~~
dgreensp
I think you're going to run into trouble with the word "objectively" there.

All languages have warts, and some are much worse than others. I actually
think JavaScript's warts are fairly minor compared to C's or Python's, for
example, and PHP is in a different league.

In fact, there are almost no other programming languages with JavaScript's
basic features: Unicode support out of the box, proper lexical scoping with
first-class function closures, high-performance garbage collection, and easy
manipulation of strings, arrays, and dictionaries, for example. Python comes
pretty close, with slightly wonky scoping and Unicode bolted on, but then
JavaScript also has another Python doesn't, which is a spec with multiple
first-class implementations, and not to mention a committee that is plotting a
great path forwards into the future with fully backwards-compatible upgrades
to the language.

~~~
orangecat
_Unicode support out of the box_

utf16 support, which isn't the same thing:
[https://mathiasbynens.be/notes/javascript-
unicode](https://mathiasbynens.be/notes/javascript-unicode)

 _easy manipulation of strings, arrays, and dictionaries_

JS objects aren't dictionaries; all keys are coerced to strings, they lack
basic operations like getting a list of keys or values, and iterating over
keys can bite you if you forget hasOwnProperty.

 _Python comes pretty close, with slightly wonky scoping and Unicode bolted
on_

And equality operators that aren't utterly insane, a usable standard library,
local rather than global scope by default, classes, namespaces, modules...

ES6 does look a like a large improvement. Mainly because it fixes misfeatures
and adds capabilities that better languages dealt with years ago.

~~~
chase-seibert
ES6 admittedly borrowed a lot from Python. I just wish Guido had been
successful getting Python supported as a first class language in Chrome; that
might have actually given us a choice in the browser. Even then, I find it
hard to imagine that ALL other browsers would have followed suit.

------
bikamonki
JS is good enough for most cases. Besides, author is missing a BIG point here:
we, 99% of web devs, have never stepped beyond setting up a virtual host in
Apache. What I mean is that we have no clue how to properly deal with server
performance and security. Hacked lately? Most of the code out there is made by
small shops and consultants who cannot afford a server ninja nor have the time
to (also) master that skill; and shouldn't do it anyway: remember
specialization equals progress? So, even with cloudware solving most of the
performance related issues, security is still on the hands of the devs. Take
my example: buy a DO droplet, get a LAMP image, install framework, follow
security best practices, get hacked, rinse and repeat.

So, fat-rich-messy clients will be the norm and BAAS providers will get richer
selling services that take away the headache of running a server. Too bad JS
is the only option to program them clients.

~~~
jbergens
Although you raise a good point I do think much more than 1% of all web devs
knows a lot about server side things. And for me using Firebase or similar is
giving up too much control. I want to be able to build server side logic for
apps.

~~~
bikamonki
Yes and yes. I was exagerating to make a point and the tradeoff is control.
However, unless you run a datacenter with a fat connection, you also give
control to your vps/cloud providers. Now, if by control you mean having
'readable' logic exposed on the client, that is also true, but some services
like parse.com offer cloud code.

------
josephagoss
> The basic idea is that your app should be fully functional even if
> Javascript is disabled.

Honest question, is this really possible? I write webapps and Javascript +
Jquery makes a lot of stuff easy, hooking into button clicks, getting text
from an input box and sending AJAX requests back to my server.

Does anyone have an example of a web application with no Javascript? My next
project will most likely use Golang as the server side, and I'm having a
really hard time imagining how to send AJAX requests back to the server on
user events (such as the user typing into a box in a real time search
application) without using Javascript.

Apparently I've missed a whole area of web development if this is all possible
with no Javascript. Isn't this like saying your Windows game should be fully
functional without a graphics card?

I mean, on most web applications, they are that, applications. Maybe I just
don't know enough, but I feel like I need a programming language in the
browser to create the client side of the application, how do I fire off AJAX
events when a user types something without Javascript?

I'm honestly trying to learn more here, I need examples of web apps with no
Javascript, I need a book or something. Just being told I can replicate my
application in html and css isn't helping.

~~~
callum85
> Honest question, is this really possible?

Yes, loads of things work without JS. You can use Wikipedia, even to edit
articles, with JS disabled – it's all simple HTML forms. JS just makes the
experience smoother (adding buttons to help with WikiText formatting, etc).

Most content and shopping websites work fine without JS. You asked how do you
fire off AJAX requests without JS? You don't. You just design your app so it
basically _works_ as a set of HTML pages connected by hyperlinks and form
submissions. Then you add JS to enhance things.

> Apparently I've missed a whole area of web development if this is all
> possible with no Javascript.

Yes you have. When I started (~12 years ago), JS was only used for little
whizzy effects here and there, not much else. Then JS started becoming more
viable due to prototype and jQuery, but it was always the most flakey part of
web development, and we learned to use it cautiously as an optional layer of
enhancement. You couldn't rely on it always working. It was a way to
'differentiate' your site, not a serious building block.

Now, everything has changed, JS is everywhere and we tend to call things
'apps' more than 'sites'. I spend 70% of my day writing JS. I'm not sure if I
agree with the JS-bashing sentiment of the article. But I do think it's still
good practice to design your app so it delivers your core
content/functionality without JS. Most stuff (blogs, e-commerce, forums, etc)
can be built like this. (Admittedly some things like p2p streaming apps just
can't.) Then you can use JS to enhance things, like enhancing your basic
search form with as-you-type suggestions. This approach makes your codebase
more structurally sound and less entangled, and makes your app more resilient.

~~~
chase-seibert
Certainly a number of common interactions are not currently possible (or at
least not optimal) without being able to use JS. Maybe some day we can get to
a place with web components where many of those common patterns can be
implemented with plain old HTML again.

------
bsaul
He forget that since you're going to have a native app targetting your
website, you're going to need a rest api anyway. So why not have you web
client consume the same endpoint and just code the rendering ?

I find stack designed this way actually much saner.

~~~
QuantumRoar
Why wouldn't it be possible to let your API talk to the back-end of your
website?

Ideally, you want to have the best format for every platform you are
targeting. The phone can have its app but the web should have a website that
works like a website, not like a clone of a smartphone app.

You could also turn your argument around. Say you have a website and now you
want to make a smartphone app. You wouldn't want to write an app that renders
HTML and CSS that's served by a server, right?

I get that it seems sane to make an app out of your website when you already
have an app for phones. But you must recognize that the web is really
something else than a native program. And if you want to do it right, you need
to treat every platform individually.

~~~
bsaul
"you wouldn't want an app that renders html served by a server". I wouldn't
because it would be (almost) impossible to render it differently in order to
adapt it to the device ( since we're talking about native apps).

Logically, a rest API is a layer that is one level "before" html/css, since it
only deals with data, and not rendering ( html needs data, not the other way
around). Since web and native use different rendering technologies, the
logical conclusion is to keep the common part of the stack at the data level,
and not one level above it.

------
dgreensp
I agree that there are some pretty bad rich apps out there that you run into
once in a while, especially ones that were contracted out to the lowest
bidder.

The pet theory is wrong, by the way, it was not mobile that led to the rise of
rich clients. When I worked on AppJet and EtherPad in 2007-2008, the rich
client wave was ahead of the mobile wave. Round-trip latency is significant
when interacting with a UI, even if it is just 100-200ms. It was obvious that
if you could deliver a desktop-quality app that worked on every platform and
didn't need to be installed, that that was the future.

I think it's worth focusing on the _actual_ harm of certain ways of writing
rich apps (e.g. breaking navigation).

------
carsongross
I really wish that the browsers adopted a byte-code standard.(NB: JS with
source maps is Yet Another Hack, doesn't count.)

If we just had a bytecode and VM standard, along the lines of Java, we could
all stop talking and go to hell in our own way.

~~~
zo1
I would vote for Python, if we were to pick one right now for such a thing.

I believe Guido (creator of Python) wrote a browser way back then, in Python.
So naturally it had the capability of scripting the client-side via python.

In case someone is curious:

[http://en.wikipedia.org/wiki/Grail_%28web_browser%29](http://en.wikipedia.org/wiki/Grail_%28web_browser%29)

------
georgemcbay
In an ideal world right now would be just about the perfect time to introduce
a real virtual machine (as a first class citizen with full DOM access rather
than forcing it to live inside a display box) into the the browser space
(including mobile browsers) rather than continuing to rely on a spotty
designed-in-two-weeks (at least according to Netscape lore) language that is
often (badly) used as a virtual machine.

I can't imagine it will actually happen for a few reasons, chief among them
being browser vendor politics and the lingering taste of the failure of Java
applets... but it would be nice.

------
zo1
My biggest gripe with single-page apps is the lack of any sort of standard URL
structure. With normal websites, even dynamic ones, you could pretty much put
bookmarks almost everywhere. And the only times where you couldn't was
probably in spots where the developers didn't want you to for some odd reason
(say an intermediate page within a signup wizard).

But single-page apps completely break that. It then becomes some sort of
hit/miss issue of whether or not that specific implementation of a single-page
app's dynamic URL will behave nicely. Will it post, will it alter something,
will it complain and just send me back to the main page? I don't know, and the
URL doesn't necessarily tell me that.

Ironically, this is how I came across this post. I was trying to find
valid/genuine criticism of single-page apps.

~~~
nacs
That's more a gripe with badly-designed SPAs than all SPAs however.

Many SPAs use the history API[1] to make a URL for everything -- Backbone,
Angular[2] and such support this for example. React.js apps typically use some
kind of router component that supports this (or they can use Backbone's
Router).

[1]:
[http://diveintohtml5.info/history.html](http://diveintohtml5.info/history.html)

[2]:
[https://docs.angularjs.org/guide/$location](https://docs.angularjs.org/guide/$location)

------
igl
I use webapps every day. I don't really have a problem with the majority of
them and i do not run into most issues he described often. When he talked
about mobile i got to think: Hey most of the native apps on my mobile suck!
Awful UIs, crashes, "bookmarkable state?" forget about it! Calendar widget not
loading any entries? Restart the device!

Javascript is not the killer platform. I got it. Can we stop complaining?

Also: 10+ years of experience - does not understand `this` ha.

------
bottled_poe
I remember reading javascript for the first time some years ago. It was hate
at first sight. Why are there so many ways to write the same thing? Why is
this forsaken language so horrible to read? Compiler support? Type system?
Debugging tools? Someone needs to clean up this mess. As long as javascript is
the dominant web client programming language, the browser will continue to be
the platform of the future, but never the present.

------
cromwellian
"I wrote a single page web based email client in 2003, years before the launch
of Gmail"

Gmail was launched in April 2004, not "years before". A nit, I know. I can
summarize this article as "Javascript sucks".

That was true for a long time, but the world has moved on since 2003. ES5
strict mode fixed some of the issues. ES6 fixes a lot more. Since then many
frameworks and tools have been developed as coping mechanisms. Closure
Compiler, CoffeeScript, GWT, TypeScript, Flow, etc.

I'd actually say that client side Javascript hasn't gone far enough. There is
much to do to improve the Web platform itself, and relying excessively on
server rendered markup that gracefully degrades is not going to convince
people to stop writing native code, if anything, it'll make it far worse, as
network radio latency makes relying on server round trips for UI transitions
bad on even the best mobile networks, and extremely bad in developing world
wireless environments.

------
woah
Huh... I'm not sure what he is having an issue with, exactly. His mention of
"this" may indicate an adherence to JS OOP antipatterns... other than that,
it's hard to see what the problem that he is having is.

~~~
mattdeboard
He is ranting about the practice of creating "rich client side applications"
when they are not necessary. His argument is predicated on the following, as
far as I can tell:

1\. JavaScript has numerous design flaws, mainly wrt giving developers many
very large guns with which even experienced devs can easily shoot themselves
in the foot.

2\. Languages and frameworks targeting the server-side of the web are suited
very well -- better than JavaScript, historically -- to creating dynamic HTML.

3\. Complex UI interactions typical of single-page applications are inherently
difficult to do well.

I am not sure why the first two commenters seem to dismiss his entire essay
because he uses scoping issues as an example, but that's pretty unfair &
close-minded.

~~~
TheAceOfHearts
1\. JS has a lot of quirks, but you can find quirks in anything that has been
around for a long time. From just using a linter you can avoid a TON of
problems (and realistically, how many people code in any language without any
kind of linting?).

2\. I don't know what to say about this. Maybe historically, yeah. But
nowadays? You can build your API with any language or framework, and have
nodejs running an isomorphic app. This means you can do server-side rendering
and then delegate to the client once it loads. This provides the best possible
experience. And you avoid code duplication, since you can run the almost the
exact same code on the server and client. (You'll usually have to do some
minor tweaks, which I'd consider reasonable.)

3\. From what I've seen, complex UI interaction are difficult to do well
regardless of your environment. (This is also why I've been really excited
about react+flux, since it provides a much better experience when developing
applications.)

~~~
mattdeboard
Not all quirks are created equally, friend, and not all languages of a
particular "generation" (e.g. python, javascript, java all released in the
early- to mid-90s) are essentially equivalent. PG put it well:

> But when our hypothetical Blub programmer looks in the other direction, up
> the power continuum, he doesn't realize he's looking up. What he sees are
> merely weird languages. He probably considers them about equivalent in power
> to Blub, but with all this other hairy stuff thrown in as well.[1]

Anyway, we probably agree on this topic but are dickering over something
tangential (whether JavaScript sucks). I'm a big React+Flux fan as well. I
never enjoyed front-end development, and really I avoided it, until React came
around.

[1] [http://www.paulgraham.com/avg.html](http://www.paulgraham.com/avg.html)

~~~
chase-seibert
+1 I think that React.js is actually a much better model, closer to how you
would render full page renders on the server.

------
curiously
There's so much frontend jobs now that as much as I hate it and no it's wrong,
I am forced to learn it to keep up.

There's just no choice. The stakeholders have decided suddenly JS is the new
way to write apps, these type of people won't know how to code if you put a
gun to their heads, even worse are developers refusing to use conventional
tools like PHP or Python or Ruby for writing server backends.

I've never forced JS or SPA on someone that had no place for it but
unfortunately they are willing to pay more to have it rewritten in JS.

