And with modern tools, there's no reason that anything — even a highly interactive app — couldn't be prerendered on the server.
And with modern tools, there's no reason that anything — even a highly interactive app — couldn't be prerendered on the server.
I'm with you 100 percent when it comes to "I can't read this text document because it needs 45 JS libraries to render," that's stupid. But it's probably stupid because it's over-engineered, not because it uses the browser.
I feel like this is going to become a bigger and bigger debate in the coming years, and I'm eager to be proven wrong, or at least understand the other side. But if I'm building the next great web-based spreadsheets application (I'm not), my immediate and overwhelming success is going to be WAY easier to manage if the majority of my code is being executed on the millions of computers calling in to use it, not on the three servers running in my auto scaling group. Why WOULDN'T I pick that option?
There was a giant multinational hamburger chain where some bright MBA figured out that eliminating just three sesame seeds from a sesame-seed bun would be completely unnoticeable by anyone yet would save the company $126,000 per year. So they do it, and time passes, and another bushy-tailed MBA comes along, and does another study, and concludes that removing another five sesame seeds wouldn't hurt either, and would save even more money, and so on and so forth, every year or two, the new management trainee looking for ways to save money proposes removing a sesame seed or two, until eventually, they're shipping hamburger buns with exactly three sesame seeds artfully arranged in a triangle, and nobody buys their hamburgers any more.
I don't think it's analogous to a developer taking advantage of modern consumer hardware to do the work computers were designed to do, because it's not necessarily a worse product you're delivering. If your internet connection is spotty, it's likely a better experience in some ways. It just seems like people have these brilliant machines capable of executing all of this code (more or less) out of the box, but we're treating them as thin clients because... why? Because some people won't upgrade their OS/browser? Because the method of delivery is the same one that's used to inject banner ads and flashy video ad thingies? If that's the case, then it seems like the whole "server-side rendering" option is getting to sound pretty good for advertising, too. Then where are we?
In {the burger case}, {removing sesame seeds} is an act that makes {the product} objectively worse, just in a way that will hopefully not make it worse enough to affect demand.
And in {this case}, {punting things from server-side to client-side} is an act that makes {power usage, wear and tear, security, battery life, bandwidth use} objectively worse, just in a way that will hopefully not make it worse enough to affect demand.
* Security: Yes, there's not too much argument that can be made for unquestioningly allowing arbitrary code execution on your computer. I think part of this will improve with browser enhancements, so long as they go more in the direction of sandboxing than in the direction of "Hey let's give Chrome access to everything in your computer right?!" Doing important stuff server-side is probably safer for users. That said, I'm bad at security. I just don't know enough about it, so I can't put up much of a fight.
* Bandwidth use: I'd actually be really interested to see some research on this. Needing to download a different version of jQuery/AngularJS/Backbone for every website you visit is certainly not particularly efficient, but I wonder how long you need to be on a website before they've sent you more HTML data than you would have had to deal with pulling down the Javascript and just pushing JSON data into it. For the mobile web at least, you win.
* Regarding power usage and wear and tear, I don't consider it a crime to make a computer do computing, which may be our main point of disagreement. If I've got a 2+ gHz processor and a few gigs of RAM, what else am I going to be using it for? Almost all of my apps are web-based, and I'd rather hear my fan rev up a little bit while Firefox renders a big graph instead of waiting for a server to generate a picture of one and just send it to me.
You are not me. (Not to mention I am not against doing most things client-side. I am specificially against Turing-complete languages being required on the client side. Things like charts are fine.)
I do not see why things should be done multiple times when they can be done once. You're offloading visible costs to places where they are hidden and then calling it gone.
I was talking to a young person that sometimes buys her mobile data plan in 20MB prepaid chunks, complaining how fast Facebook eats through that data.
Now I don't have Facebook (or a data plan, my ISP has "hotspots" all over town), I was curious and asked her how much Facebook does 20MB buy you, anyway?
She said sometimes when she does a full reload of the page it costs 3-4MB. I told her, did you know that's enough data to fit the entire LotR trilogy, or the bible? (either of them are about 3-5MB, zipped plaintext).
I agree that the things you say could potentially save a lot of bandwidth, but the reality is, in practice they really really do not, not by far :-)
For one reason, because that one computer can usually do it (or at least most of it) once, and instead you're forcing millions of people to redo the same computation themselves. That's just... wrong.
> But if I'm building the next great web-based spreadsheets application (...) Why WOULDN'T I pick that option?
Well, in this case this is the right way, because you need to dynamically interact with data entered by the user (in this case, people usually make another error - they send data to server that there is no need for; but that's another topic. [0]). You're writing a web application. But a web site, like landing pages, blogs with articles, etc. have exactly zero reasonable needs for rendering everything client-side. It's just making the same compute millions of times because someone was too lazy to compute it once.
[0] - actually, it's not. One could notice that most of the problems with current web come from two things: sending the code that should stay on the server to the client, and sending data that should stay with the client to a server.
I was more disagreeing with the concluding assertion that "with modern tools, there's no reason that anything — even a highly interactive app — couldn't be prerendered on the server." There's no reason it couldn't be, sure, but it's way harder when the clients are just as capable -- and, once things start getting busy, probably even more capable.
Whether or not to take this approach is to be determined on a case-by-case basis. Some tools are too interactive and have too tight a feedback loop to make any sense without javascript. A spreadsheet is an example where I'd probably choose to break support for no-javascript, but it's less clear-cut than, say, a CAD application. An example where I'd opt to support clients without javascript is a todo-list application, or a twitter-like.
Of course, this has always already been the case! That's why we don't stream our webpages as images (or video, if you need to scroll), but instead offload the work of rendering a graphical representation of the symbolic HTML representation to the client-side browser.
It's a pretty solid idea (apart from the Browser Wars), and one of the ideas that made the WWW viable.
The ridiculous part, however, is where people somehow decide that we should wrap more and more and yet another layer of abstraction onto it.
It's not that web servers have grown less powerful and therefore need to offload more work onto their clients. The demands on web servers are higher today, but they've also grown more powerful, and we came up with some pretty clever scaling technologies to deal with those higher demands. But offloading code execution in the form of client-side JS is not really one of those, in practice.
Yes, the idea could technically be used to accomplish that and make less work on the server side, but really, take a look at this page, or any (bloated) page like the problem we're describing; That's not what's going on here, it's about the same amount of work on the server side, nothing's being offloaded, just more work on the client side.
At least the Flash-only-interface websites that plagued the web 10 years ago offered us UI elements that weren't possible in HTML back then (for better or worse), but today's JS bloat truly doesn't add anything that can't be done in a much leaner, less client resource-intensive way.
Even your spreadsheet example. Sure, run the calculations client-side, that only makes sense, no need to throw out JS with the bathwater. But what sort of calculations are we talking about, realistically? For a medium spreadsheet, a few hundreds of summations and multiplications. Nothing of the kind that should make a 5-year old computer even blink. But whatever these types of apps are actually doing they manage to crawl the jankscroll already even on an empty document, let alone when you try to use it.
And large bitmaps are rather bandwidth inefficient, and inaccessible to boot.
I don't mind markup. I mind tech that doesn't include fallbacks, and I mind people using Turing-complete languages for things that can easily be done using a less powerful language. (Turing-complete languages tend to get abused by people to the point that people want them to be executed quickly and with little memory use (which means that the language implementation gets complex, and hence buggy {simple laws of probability}), and almost any vulnerability can generally be exploited by a suitable script in a TC language, and TC-languages can be used to do unexpected things.)
HTML is decent. HTML+CSS is worse than HTML (for the same reason that COMEFROM is worse than GOTO). Markup is better than HTML in many ways, or rather most formal specifications of Markup-like languages are better than HTML. (Unfortunately, most variants of Markup aren't specified beyond "do what I do")
I've been tempted for a while to write a Markup browser. (Mop? Markup-Over-tcP? )
That's the entire reason why js and html and friends have become so popular. You essentially have full applications that have been developed by people who recognize that the bottleneck wrt to a networked application's responsiveness is not cpu cycles and memory in 2015 but internet latency. It's sufficient here to send a small text file and have the client fill in the gaps and have the client ajax for updates than have the server do the heavy work. I think you argued elsewhere, this is a waste of processor time redundantly rendering content, and thus, a waste of energy needlessly (as in real energy, from electrical into waste heat). As a tree hugger, I have to admit I find that argument somewhat compelling. I think a balance needs to be struck between user experience and use of resources. It might be your balance line lies further towards the "saving of resources" than mine's does.
And you can do most of a thin client, if not all, while keeping sane bandwidth use. (Note that almost all cases where bandwidth use would be excessive for a thin client in a web setting, said bandwidth use would also be excessive for a fat client in a web setting.)
It's mainly that current tech has settled on the brute-force approach of "let's stream every pixel and then try to compress it" as opposed to saner approaches (vector graphics, remote compositing, that sort of thing). But note that there are, for example, remote desktop protocols that work well (for most things) over a dial-up connection!
That doesn't mean that websites shouldn't use javascript — I'd not want to use a todo list application that forces me to reload the page on every click — but it's still useful to support that functionality, because some day I might need to access my todos from an environment where I can't use javascript for whatever reason.
People claim that it's too much work to support something so niche, but if you architect your application well, using progressive enhancement, you get support for no-javascript environments, plus a ton of other stuff like server-side prerendering for latency reduction, accessibility, SEO, text-based browser functionality — all virtually for free.
Not that this should be applied everywhere dogmatically, it's not worth supporting no-javascript environments or scrapers in your browser-based photo editor.
It would be even better if servers would return raw data in xml format, with a linked xslt transform to convert it to a structured document, and css to manage the presentation with javascript to control the interactivity, but that idea died long ago, but some modern applications are finally replicating most of the good parts of that system.
I was more wondering what you meant by prerendering things, because even when one opens an html page in your browser which is on your local drive, the client is doing rendering (typesetting, and such). That is an extreme...so, it sounds like you were asking for a return to the pre-ajax internet, which you say here that it doesn't fit everything.
So I think we don't really disagree here, I could have misunderstood you?