Rich client side web apps gone too far (2014) | Hacker News Reader

Rich client side web apps gone too far (2014)

chase-seibert.github.io

65 pointszo155 comments

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.

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

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

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

I would have to disagree here for 2 main reasons:

1. The vast majority of content I consume is, in fact, not static content, the only exceptions being HN and my bank statements. For almost everything else, I much prefer the interactive experience made possible by an SPA. This includes anything with a map (Yelp, Airbnb, Redfin), charts (google analytics), autocomplete (stack overflow) or chatting (google hangouts).

2. All SPAs are not the same - for every 10 second-load monstrosity (gmail), you have someone sending the markup from the server on the first load (airbnb)

With the explosion of mobile apps, people have a certain level of expectation in terms of UX, and a static site won't always meet those expectations.

I agree. I value what javascript enables for those experience as well. I just wish more sites could implement those useful pieces and still get all the basic interactions correct. Too often, those are broken, I assume due to ignorance.

True, coming from Backbone, I've run into my share of broken views, but we're beginning to see newer libraries, like React, that provide better abstractions and reduce the possibility of introducing bugs.

I take it you've experienced the event-ghost nightmare or the parent-child view disaster? I've used bbjs 2yrs now and are also looking to try react. Have you? What bbjs problems does it solve? What do you miss from bbjs? I also understand the two are not strictly comparable: bbjs is mvc, react is v. Do you use react for views only?

React isn't just 'v', but you do generally want to use something alongside it that takes care of the data. I've had a great experience using the flux pattern with Reflux.js (which is one of the 'simpler' flux implementations.) Another interesting option is Baobab.js, although that still seems to be in heavy development.

I've also used flux with Ractive.js, which in some ways is perhaps an easier introduction into the flux/react approach. Might want to check that out.

I find it hard to describe how incredibly simpler everything is now that I don't use BB anymore. With some of the stuff that 'just works' in my current setup I can't even begin to think of a clean way to do in Backbone.

@mercer pretty much nailed it - I use react+reflux, and it's made life a lot easier. If server-side html is important to you, check out flummox.

As for mvc, I would say react+reflux is more like mvvm than mvc. I don't miss anything from backbone and can't imagine going back, good riddance.

The game played on web development is that javascript is used to make for deficiencies in the basic functionality of browsers - both bad implementation of web standards as well as functionality missing from the standards. Developers would be much better of if web browsers provided a high-quality, full featured experience to create web applications/sites. Of course, this is not easy to do, especially when there are several browsers competing for the same market. As long as this happens, javascript will be aways be used to provide the extra functionality that is needed, even on content-only web sites.

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.

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

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

http://intercoolerjs.org/

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

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

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.

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.

Unicode support out of the box

utf16 support, which isn't the same thing: 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.

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.

Garbage collection is a function of the particular runtime, no? Which probably isn't anything to do with the language... right? I'm asking sincerely, these aren't loaded questions.

while the particular effectiveness of a runtime's GC is determined by the VM, JS the language doesn't provide operators or types to represent manual memory management - so it's a pretty core feature of the language that whatever VM it runs on will use garbage collection (or at the very least transparent automatic memory management) to reclaim memory.

the fact that "javascript sucks" wasn't the point of the essay is EXACTLY my point - in an article that should be about calling out bad practices in designing web client experiences, there are judicious sprinklings of criticism of the underlying language, without attempting to distinguish those harms from the harms of bad choices in implementation. that sort of conflation is intellectually sloppy and ultimately leads to both sides 'reflexively' responding.

I'll definitely agree that javascript has room for improvement, but i'm not sure by what objective standard you're measuring its design chops. If you consider the goal of JS to be an incredibly flexible, light language with powerful runtime dynamicism and a strong focus on client-only needs, I'd say it's fairly well-designed. If you're holding it up against python as a server scripting language, it probably doesn't quite measure up. and if you're holding it up against all other languages and measuring by some 'general-purpose utility' ruler, that's a pretty pointless exercise - as I said in my original comment, languages are designed to solve specific problems, and JS is no exception.

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.

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.

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.

What is "BASS"?

BAAS -> Backend as a service. For example: parse.com or firebase.com * It was mispelled, fixed it already

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

The idea behind progressive enhancement is that you prioritize your features, and then make the most fundamental features of your site work without Javascript while still giving JS-enabled users something extra to play with.

So in your example - no, you would not send AJAX requests back to the server in a real-time search application. It would not be "real time" at all. But you would still be able to search, and get back results. Then you add JS, and you can search as you type.

Relatively few sites do it like this these days - in general, anything that's a SPA that talks to JSON won't work at all with JS disabled. It takes a good understanding of your tools and of your users to prioritize like this, as well as a good dose of humility. But it also often results in better usability and UX design overall, because you know which features are really key and which are "nice to haves", and you don't compromise key features for extras.

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

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.

"is this really possible?"

Well, sure.. of course it is possible, just a lot more work because the divide between having logic on the client and no logic on the client is quite big thus you often end up needing to solve problems in two ways (and these differences can permeate various layers of the app) and then commit to maintaining both.

"such as the user typing into a box in a real time search application"

Well you could always just not support real-time search if JavaScript is not enabled. The argument that JavaScript should be optional for all sites sort of pre-assumes that the experience when running sans JavaScript will be different, but you'll be able to get the same things done. In this one specific situation the difference being that you won't get any search feedback until you actually submit the form, old-school web style.

>Just being told I can replicate my application in html and css isn't helping.

You can't. But do you really need to? Couldn't your webpage work without suggestions popping up as query is typed into the input box? Your webpage should not stop working if you can't validate user input client side, etc... .

See:

http://en.wikipedia.org/wiki/Progressive_enhancement

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.

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.

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

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

It is. However, since the API is already designed to be used securely by a client, it'll be a lot less work to make the browser be the client of the API.

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

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.

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

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.

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.

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

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

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.

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.

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

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.

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.

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

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

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

Perl gets bashed for all its quirks all the time, although there is a huge amount of tooling to write clean and readable Perl (Perl::Critic, Moose, etc). What really amazes me, is how everybody seems to be cool with using tons of tools to work around the many inherent language deficiencies in Javascript (with Coffeescript being the most insane "solution"), but it's a totally different story when it comes to Perl.

I'm not sure the server side is much better. Complex UI is complex wherever you try to implement it. You can say that is not actually possible to create really smooth UI with animations only using server side code. And server side code usually don't want to keep any state at all (to allow the use of multiple servers) which causes a lot of problems. A SPA can keep state and use it if it suits the problem better. Some of the new js libraries actually looks more developed than most server side ones. [edit: spelling and a clarification]

> Complex UI is complex wherever you try to implement it.

Yeah that's what I meant by #3. Independent of runtime, language or implementation-specific particulars. It's... gooey.

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.

Reply on news.ycombinator.com