After I took issue with some thoughts of Aaron Gustafson regarding JavaScript, Aaron has clarified his thoughts elegantly.
His key issue here is summed up by one sentence from his post: “The fact is that you can’t build a robust Web experience that relies solely on client-side JavaScript.” Now, I could nit-pick various details about the argument he provides (I’ve had as many buggy modules from npm or PyPI as I’ve had from the Google jQuery CDN, and if you specify exact version numbers that’s less of a problem; writing software specifically for one client might allow you to run a carbon copy of their server, but server software for wide distribution, especially open source, doesn’t and shouldn’t have that luxury) but those sorts of pettifogging nit-picks are, I hope, beneath us. In short, I’ll say this: I agree with Aaron. He is right. However, this discussion uncovers some wider issues.
Now, I’ve built pure client-side apps. The WebUtils are a suite of small apps which one would expect to find on a particular platform (a calculator, a compass, a currency converter, that sort of thing), but built to be pure web apps in order that someone deciding to use the web as their platform has access to these things. (If you’re interested in this idea, get involved in the project.) I built two of them; a calculator and a currency converter. Both are pure-client-side, JavaScript-requiring, Angular-using apps. I am, in general and in total agreement with Aaron, opposed to the idea that without JavaScript a web app doesn’t work. (And here by “without JavaScript” we must also include being with JavaScript but JavaScript which gets screwed up by your mobile carrier injecting extra scripts, or your ISP blocking CDNs, or your social media buttons throwing errors, or your ads stomping on your variables. All of these are real problems which go unacknowledged and Aaron is entirely right to bring them up.) However, the policy that apps should be robust to JS not working, by being server apps which are progressively enhanced, does ignore an elephant in the room.
It is this. I should not need an internet connection in order to make my calculator add 4 and 5.
A web app which does not require its client-side scripting, which works on the server and then is progressively enhanced, does not work in an offline environment. It doesn’t work when you’re in and out of train tunnels, or at a conference with bad wifi, or on a metered data connection. The offline first concept, which should be informing how we build apps, is right about this.
So, what to do? It is in theory possible to write a web app which does processing on the server and is entirely robust against its client-side scripting being broken or missing, and which does processing on the client so that it works when the server’s unavailable or uncontactable or expensive or slow. But let’s be honest here. That’s not an app. That’s two apps. They might share a bit of code (the server being node.js and using JavaScript might help here, but that’s not what I was talking about last time), but in practice you’re building the same app twice in two different environments and then delivering both through one URL.
This is a problem. I am not sure how to square this circle. Aaron is right that you can’t build a robust Web experience that relies solely on client-side JavaScript, but the word robust is doing an awful lot of work in that sentence. In particular, it means “you can’t build a thing which you can be sure will work for everybody”. Most of the time, for most of the people, your experience can be robust — fine, it’ll break if your ad JavaScript sods you up, or if your ISP blocks your jQuery download, and these are problems. But going the other direction — explicitly not relying on your client-side JS— means that you’ll be robust until you’re somewhere without a good internet connection. Both of these approaches end up breaking in certain situations. And making something which handles both these camps is a serious amount of work, and we don’t really know how to do it. (I’d be interested in hearing examples of a web app which will work if I run it in an environment with a flaky internet connection and having redefined window.Array to be something else on the client. I bet there isn’t one.)
This needs to be a larger conversation. It needs discussion from both JavaScript people and server people. These two camps should not be separate, not be balkanised; there is an attitude still among “real programmers” that JavaScript is not a real language. Now, I will be abundantly clear here: Aaron is not one of the people who thinks this. But I worry that perpetuating the idea that JavaScript is an unstable environment will cause JS people to wall themselves off and stop listening to reasoned debate, which won’t help. As I say, I don’t know how to square this circle. The Web is an environment unlike any other, and as Aaron says, “building the Web requires more of us than traditional software development”. We get huge benefits from doing so — you build for the Web, and do it right, and your thing is available to everybody everywhere — but to “do it right” is a pretty big task, and it gets bigger every day. We need to be talking about that more so we can work out how to do it.