3 ms·

EDIT: Lots of downvotes for saying that there are other ways to program apps besides doing everything on the client. Render content on the server, enhance conte

EDIT: Lots of downvotes for saying that there are other ways to program apps besides doing everything on the client. Render content on the server, enhance content presentation on the client. --- I don't get it. Is this 1996? Why are people just now 'discovering' that you don't need to throw JS at an application to have it completely usable? > All modern websites, even server-rendered ones, need JavaScript. There is just a lot of dynamic stuff you need to do that can only be done in JavaScript. Really? Look at Linode, Amazon, or even Google (including GMail, and probably others). All of which are big names that can and do work ENTIRELY without JavaScript. > Client-side JavaScript applications are damn fast. Another (AJAX) HTTP request + rendering the returned data on a tiny mobile phone is faster than one HTTP request for the entire webpage and having dedicated machinery pre-render the content for you? I don't think so. He does talk about this point later on, but which is it? Client-rendered JS apps are, or aren't fast? --- JS Hipsters offloading rendering everything to the client for absolutely no reason is the 'everything-looks-like-a-nail' or the 'everyone surfs the web like I surf the web and has my specs' problem. Worst of all, in doing so, they completely neglect actual content. You don't know how many million-dollar VC-funded company webpages I've visited that don't even have a damn tagline visible on their landing page without JavaScript enabled. <h1>s with actual content inside of them are too complicated now? The solution is very simple: render all the data on the server, and progressively enhance subsets of your app with JS, by overriding the defaults of the rendered page. It's literally like we're discovering DHTML all over again.

azakai 12y ago
> GMail, and probably others [..] All of which are big names that can and do work ENTIRELY without JavaScript. Gmail uses massive amounts of client-side JavaScript (perhaps compiled from a different language, of course).
- chrisdotcode 12y ago
  There's an option for the basic HTML layout available if you have JS disabled. That's the second-best approach. The first is using a JS-redirect to the flashy AJAX page, or just overriding all the default handlers necessary with JavaScript (remember, at this point, your content was already (supposed to be) properly rendered for you by the server).
  - azakai 12y ago
    Sure, there is an option for a no-JS version of Gmail, but the default definitely uses Gmail, because the user experience is much better - I think that's pretty clear. I agree doing some work on the server can also make sense, and that the new pre-rendered JS is an extension of progressive rendering which is not a new technique. It's a new way of doing it, though.
- dredmorbius 12y ago
  What you've failed to grasp, twice, is that these sites do have javascript-free versions. Which work. Not that they don't also have JS-infested versions. Which also sometimes work.
  - dsrw 12y ago
    In most cases these are separate apps. "Just build it twice!" is necessary in some cases, but is far from idea. Progressive enhancement is hard, at least for complex interfaces that need to maintain state. Hard enough that many sites, if they support disabling JS at all, do so by writing an entirely new frontend with a simplified feature set. Ember + Fastboot provides many of the advantages of progressive enhancement, but is far more productive in many cases.
ta_75000 12y ago
> Why are people just now 'discovering' that you don't need to throw JS at an application to have it completely usable? I think a new generation of developers for whom the web has always been, essentially, a rich and dynamic applications platform is 'rediscovering' that it's really just document markup with Turing completeness on the side.
iamstef 12y ago
> Really? Look at Linode, Amazon, or even Google (including GMail, and probably others). All of which are big names that can and do work ENTIRELY without JavaScript. I think we can all agree, maintaining two discrete code-bases is a sub-optimal experience. Especially for companies without the resource of the "big names" you point out. > Another (AJAX) HTTP request + rendering the returned data on a tiny mobile phone is faster than one HTTP request for the entire webpage and having dedicated machinery pre-render the content for you? I don't think so. He does talk about this point later on, but which is it? Client-rendered JS apps are, or aren't fast? Several reason why this experience results in a faster mobile experience. - cached data serves extremely quickly ;) - pre-emptively loading data to prime the cache. - data is smaller then data + html. - the app remains usable during loading phases. Additionally, separating the concerns of rendering and data loading, does afford more creative optimizations as the need arises.
- chrisdotcode 12y ago
  As I've said, > The solution is very simple: render all the data on the server, and progressively enhance subsets of your app with JS, by overriding the defaults of the rendered page. It's literally like we're discovering DHTML all over again. Client.js, rendered on the client: render(template, data) Server.js, rendered on the server: render(template, data) --- They're exactly the same. You use a templating engine library for either JS, or your server language to process the same data. What client.js should do is change things dynamically, progressively.
  - iamstef 12y ago
    One hard part becomes synchronizing ephemeral UI state between client and server. Such as data not-yet saved, or various UI components that are toggled into some sensible state. As the complexity increases, this problem explodes. One can use local storage (when available), but unfortunately this isn't always available, or needed. Another thing you can do is bounce state back & forth with requests. Unfortunately this becomes a synchronization nightmare. It is extremely nice to allow ephemeral UI state to remain in the UI. Merely syncing non-ephermal state, and populating a client side pool of data that is quickly addressable, and thus "instant" from the perspective of the UI. Mitigating the latency of mobile networks is key here, no latency due to data-locality is the only way. Short of Quantum entanglement Physics isn't on the side of server-side rendered experiences.
jjbiotech 12y ago
> Another (AJAX) HTTP request + rendering the returned data on a tiny mobile phone is faster than one HTTP request for the entire webpage and having dedicated machinery pre-render the content for you? I don't think so. He does talk about this point later on, but which is it? Client-rendered JS apps are, or aren't fast? Very large generalization, it depends on the specifics of an implementation. Plus this isn't as scaleable since you're consuming CPU cycles rendering views on the server. > The solution is very simple: render all the data on the server, and progressively enhance subsets of your app with JS, by overriding the defaults of the rendered page. It's literally like we're discovering DHTML all over again. So you're telling me to write a web app that consists of: A Server-side application, multiple page-specific JavaScript "widgets", and an API endpoint for AJAX communication. That doesn't sounds very fun or efficient for the programmer. It's is taking a step back in time in terms of developer happiness, and application complexity (and possibly efficiency but that's implementation specific). Also, what about saving UI state?? Good luck with that... What sounds better to me is a single RESTful interface and a JS application that renders all of your views. It does have it's downsides (SEO + tin-foil hat people disabling JS), but it's a much more elegant solution.
mixonic 12y ago
Linode, Amazon, and Google all absolutely use JavaScript. Tom isn't saying that they use JavaScript on the server, he is suggesting that JavaScript is involved with their website despite using a different language on the server. Look, saying "client-side JS apps are damn fast" is a vague statement. What we are talking about here is the architecture of a client-side application in any language. If you can ship application code to a local runtime, then that application code will always be able to respond to user interaction faster than fetching the results of a UI interaction (like a click) from partway across the globe. The benefits of Client-side JavaScript applications do not come directly from JavaScript. They come from the architecture you can build when treating the Browser as a runtime for applications. Progressive enhancement (beyond very small apps) is a challenge to maintain, since UI state needs to be shared between a server runtime and client runtime. I don't think there is disagreement that a pure server-rendered app or a pure client-rendered application would be simpler. And your comments about shitty execution of web pages and apps could apply to any shitty app. They have nothing to do with client-side JavaScript applications. I expect a better argument than "I once saw a webpage that sucked".
- chrisdotcode 12y ago
  > Progressive enhancement (beyond very small apps) is a challenge to maintain, since UI state needs to be shared between a server runtime and client runtime. It does? Why? The server is handling the data to be rendered either way, and as I say in response to another comment, rendering the data is as simple as: res.end(render(template, data)) > And your comments about shitty execution of web pages and apps could apply to any shitty app. They have nothing to do with client-side JavaScript applications. I expect a better argument than "I once saw a webpage that sucked". The argument is "you are VC-funded, and taking a 1mil+ dollars to build the Next Big (S|P)aaS. You are spending tons of money on A/B testing, designers, mockups, UI specialists, and your page does not even load for the lowest common denominator - and easiest to manage (static HTML) users of the web?" The web was built for content-first, not flash.
  - iamstef 12y ago
    My experiences may be biased, but most startups I work with have target audiences that do not include tin-foil hatted JavaScript disabling individuals. To the contrary, for them investing any energy in servicing this minority would be a mistake. I suspect their exists some subset of startups were this may be reversed. But they are absolutely in the minority.
sanderjd 12y ago
You don't seem to have that many downvotes right now, but I downvoted you, not because you said there are other ways to program, or even because I disagree with you that we've swung the pendulum too far toward the client, but because your comment seems to willfully ignore everything the article says. Here is what I mean: > JS Hipsters offloading rendering everything to the client for absolutely no reason Whether you think the reasons given are good or not, it is inarguable that the article lays out man reasons, so coming back and simply claiming there is no reason is not in good faith. What's interesting is that the solution described in the article is functionally equivalent to what you think the solution should be, but you still don't seem to like it, presumably because retains the advantages of an approach you dislike.
ctide 12y ago
You're getting downvoted because you miss the point. You want the web to cater to you, and big companies with infinite resources will, but smaller companies just won't. The cost to support users such as you is just not worth it, you're too small of a segment. People are going to focus their design + resources on the 99% of users who have decided they want the web to work properly. I mean, shit, lots of startups completely eschew IE support, and they're a way more significant portion of the market than the neckbeards who disable javascript.
- chrisdotcode 12y ago
  > The cost to support users such as you is just not worth it, you're too small of a segment. You don't understand. The web is content-based. Like motherfuckingwebsite.com [0] shows, you don't need dynamic content to present your message. If I need to download 1MB of JS to see your freaking tagline, then that's ridiculous. [0] https://news.ycombinator.com/item?id=6791297 https://news.ycombinator.com/item?id=6791297

azakai 12y ago

> GMail, and probably others [..] All of which are big names that can and do work ENTIRELY without JavaScript. Gmail uses massive amounts of client-side JavaScript (perhaps compiled from a different language, of course).

chrisdotcode 12y ago
There's an option for the basic HTML layout available if you have JS disabled. That's the second-best approach. The first is using a JS-redirect to the flashy AJAX page, or just overriding all the default handlers necessary with JavaScript (remember, at this point, your content was already (supposed to be) properly rendered for you by the server).
- azakai 12y ago
  Sure, there is an option for a no-JS version of Gmail, but the default definitely uses Gmail, because the user experience is much better - I think that's pretty clear. I agree doing some work on the server can also make sense, and that the new pre-rendered JS is an extension of progressive rendering which is not a new technique. It's a new way of doing it, though.
dredmorbius 12y ago
What you've failed to grasp, twice, is that these sites do have javascript-free versions. Which work. Not that they don't also have JS-infested versions. Which also sometimes work.
- dsrw 12y ago
  In most cases these are separate apps. "Just build it twice!" is necessary in some cases, but is far from idea. Progressive enhancement is hard, at least for complex interfaces that need to maintain state. Hard enough that many sites, if they support disabling JS at all, do so by writing an entirely new frontend with a simplified feature set. Ember + Fastboot provides many of the advantages of progressive enhancement, but is far more productive in many cases.

ta_75000 12y ago

> Why are people just now 'discovering' that you don't need to throw JS at an application to have it completely usable? I think a new generation of developers for whom the web has always been, essentially, a rich and dynamic applications platform is 'rediscovering' that it's really just document markup with Turing completeness on the side.

iamstef 12y ago

> Really? Look at Linode, Amazon, or even Google (including GMail, and probably others). All of which are big names that can and do work ENTIRELY without JavaScript. I think we can all agree, maintaining two discrete code-bases is a sub-optimal experience. Especially for companies without the resource of the "big names" you point out. > Another (AJAX) HTTP request + rendering the returned data on a tiny mobile phone is faster than one HTTP request for the entire webpage and having dedicated machinery pre-render the content for you? I don't think so. He does talk about this point later on, but which is it? Client-rendered JS apps are, or aren't fast? Several reason why this experience results in a faster mobile experience. - cached data serves extremely quickly ;) - pre-emptively loading data to prime the cache. - data is smaller then data + html. - the app remains usable during loading phases. Additionally, separating the concerns of rendering and data loading, does afford more creative optimizations as the need arises.

chrisdotcode 12y ago
As I've said, > The solution is very simple: render all the data on the server, and progressively enhance subsets of your app with JS, by overriding the defaults of the rendered page. It's literally like we're discovering DHTML all over again. Client.js, rendered on the client: render(template, data) Server.js, rendered on the server: render(template, data) --- They're exactly the same. You use a templating engine library for either JS, or your server language to process the same data. What client.js should do is change things dynamically, progressively.
- iamstef 12y ago
  One hard part becomes synchronizing ephemeral UI state between client and server. Such as data not-yet saved, or various UI components that are toggled into some sensible state. As the complexity increases, this problem explodes. One can use local storage (when available), but unfortunately this isn't always available, or needed. Another thing you can do is bounce state back & forth with requests. Unfortunately this becomes a synchronization nightmare. It is extremely nice to allow ephemeral UI state to remain in the UI. Merely syncing non-ephermal state, and populating a client side pool of data that is quickly addressable, and thus "instant" from the perspective of the UI. Mitigating the latency of mobile networks is key here, no latency due to data-locality is the only way. Short of Quantum entanglement Physics isn't on the side of server-side rendered experiences.

jjbiotech 12y ago

> Another (AJAX) HTTP request + rendering the returned data on a tiny mobile phone is faster than one HTTP request for the entire webpage and having dedicated machinery pre-render the content for you? I don't think so. He does talk about this point later on, but which is it? Client-rendered JS apps are, or aren't fast? Very large generalization, it depends on the specifics of an implementation. Plus this isn't as scaleable since you're consuming CPU cycles rendering views on the server. > The solution is very simple: render all the data on the server, and progressively enhance subsets of your app with JS, by overriding the defaults of the rendered page. It's literally like we're discovering DHTML all over again. So you're telling me to write a web app that consists of: A Server-side application, multiple page-specific JavaScript "widgets", and an API endpoint for AJAX communication. That doesn't sounds very fun or efficient for the programmer. It's is taking a step back in time in terms of developer happiness, and application complexity (and possibly efficiency but that's implementation specific). Also, what about saving UI state?? Good luck with that... What sounds better to me is a single RESTful interface and a JS application that renders all of your views. It does have it's downsides (SEO + tin-foil hat people disabling JS), but it's a much more elegant solution.

mixonic 12y ago

Linode, Amazon, and Google all absolutely use JavaScript. Tom isn't saying that they use JavaScript on the server, he is suggesting that JavaScript is involved with their website despite using a different language on the server. Look, saying "client-side JS apps are damn fast" is a vague statement. What we are talking about here is the architecture of a client-side application in any language. If you can ship application code to a local runtime, then that application code will always be able to respond to user interaction faster than fetching the results of a UI interaction (like a click) from partway across the globe. The benefits of Client-side JavaScript applications do not come directly from JavaScript. They come from the architecture you can build when treating the Browser as a runtime for applications. Progressive enhancement (beyond very small apps) is a challenge to maintain, since UI state needs to be shared between a server runtime and client runtime. I don't think there is disagreement that a pure server-rendered app or a pure client-rendered application would be simpler. And your comments about shitty execution of web pages and apps could apply to any shitty app. They have nothing to do with client-side JavaScript applications. I expect a better argument than "I once saw a webpage that sucked".

chrisdotcode 12y ago
> Progressive enhancement (beyond very small apps) is a challenge to maintain, since UI state needs to be shared between a server runtime and client runtime. It does? Why? The server is handling the data to be rendered either way, and as I say in response to another comment, rendering the data is as simple as: res.end(render(template, data)) > And your comments about shitty execution of web pages and apps could apply to any shitty app. They have nothing to do with client-side JavaScript applications. I expect a better argument than "I once saw a webpage that sucked". The argument is "you are VC-funded, and taking a 1mil+ dollars to build the Next Big (S|P)aaS. You are spending tons of money on A/B testing, designers, mockups, UI specialists, and your page does not even load for the lowest common denominator - and easiest to manage (static HTML) users of the web?" The web was built for content-first, not flash.
- iamstef 12y ago
  My experiences may be biased, but most startups I work with have target audiences that do not include tin-foil hatted JavaScript disabling individuals. To the contrary, for them investing any energy in servicing this minority would be a mistake. I suspect their exists some subset of startups were this may be reversed. But they are absolutely in the minority.

sanderjd 12y ago

You don't seem to have that many downvotes right now, but I downvoted you, not because you said there are other ways to program, or even because I disagree with you that we've swung the pendulum too far toward the client, but because your comment seems to willfully ignore everything the article says. Here is what I mean: > JS Hipsters offloading rendering everything to the client for absolutely no reason Whether you think the reasons given are good or not, it is inarguable that the article lays out man reasons, so coming back and simply claiming there is no reason is not in good faith. What's interesting is that the solution described in the article is functionally equivalent to what you think the solution should be, but you still don't seem to like it, presumably because retains the advantages of an approach you dislike.

ctide 12y ago

You're getting downvoted because you miss the point. You want the web to cater to you, and big companies with infinite resources will, but smaller companies just won't. The cost to support users such as you is just not worth it, you're too small of a segment. People are going to focus their design + resources on the 99% of users who have decided they want the web to work properly. I mean, shit, lots of startups completely eschew IE support, and they're a way more significant portion of the market than the neckbeards who disable javascript.

chrisdotcode 12y ago
> The cost to support users such as you is just not worth it, you're too small of a segment. You don't understand. The web is content-based. Like motherfuckingwebsite.com [0] shows, you don't need dynamic content to present your message. If I need to download 1MB of JS to see your freaking tagline, then that's ridiculous. [0] https://news.ycombinator.com/item?id=6791297 https://news.ycombinator.com/item?id=6791297