Hacker News Reader

Comment by bo1024 | Hacker News Reader

Nice article, especially the data, but I'm disappointed they didn't cover more of the most effective approach: Design your site not to use javascript except where really needed!

I think most sites can be broadly classified as (1) "relatively static" such as hackernews itself, news/blogs, text-based sites in general, or (2) an entire program/application running in the browser, such as a game or collaborative text editor. Most sites fall into category 1 and therefore need very little JS to do their job effectively, but they come up with 50 different things for JS to do on their webpage, then spend time and effort optimizing and minifying instead of just not doing those things (or doing them in HTML).

View on HN

> I think most sites can be broadly classified as (1) "relatively static" such as hackernews itself

My entire job experience would disagree. I have yet to work on a static content site. When I do, you can be sure I'll use hugo or some static site generator, but every job I've had so far was to build sites that act on user-specific data that changes frequently.

First, I want to clarify: You and I may be thinking of "static" somewhat differently (maybe I misused the term). I'm not thinking of e.g. HN as static in the sense of unchanging over time, actually it constantly changes in response to user interactions. But when I personally visit a page on HN, the page I receive mostly "static" in the sense of essentially serving me a set of text, not responding dynamically to my actions (except a little bit in the case of HN).

Second, fair enough with regards to your work experience, but for me, most sites I visit are just serving text/images/video, not interactive or barely interactive.

That is where server side rendering comes into play.

Most JavaScript I write, just boils down to fancy form validation or using something like Highcharts.

You are thinking only on two extremes, between a news/blogs and game/collaborative text editor there a thousands of web apps that don't fit the two. What would you call webapp for generating and keeping track of invoices?

While it's possible I'm not understanding some important aspect of invoice generation, I don't believe JavaScript is necessary for this process... Plain HTML form inputs -> Server -> Generate PDF? What am I missing? Why's JavaScript required here?

I think we forget that the web was a pretty productive thing even before JavaScript was widely used. GMail existed (and still does) in a javascript-free form. You can even use Google Maps without JavaScript. Granted, JavaScript enhances both experiences, but it's not strictly required.

Granted, JavaScript enhances both experiences, but it's not strictly required.

Yep, Javascript is not strictly required but that was what I was trying to refer to, the enhancement part.

A blog or news site like HN doesn't really need much enhancements, a web app for invoices lends itself to be way more interactive than HN.

In your gmail example, the HTML version doesn't have:

Chat

Spell checker

Keyboard shortcuts

Adding or importing contacts

Custom "from" addresses

Rich formatting

> In your gmail example, the HTML version doesn't have:

> Chat

> Spell checker

> Keyboard shortcuts

> Adding or importing contacts

> Custom "from" addresses

> Rich formatting

Sounds excellent. I might give the Gmail Web interface another go (I've always used it through POP and IMAP in Emacs, due to monstrous "features" like these). Whilst I agree in principle with spell checking and keyboard shortcuts, not only does my browser provide both, but Google's poor wheel-reinventing interferes with them (as does that of many other sites, e.g. GitHub).

As for the "chat", my experience has been that even nudging one's mouse in the wrong way ends up migrating a gtalk account to "hangouts", which doesn't support XMPP and it's very difficult to undo.

I just tried it and wow, the "HTML-only" GMail is so much more responsive and usable! Unfortunately it still breaks my keyboard shortcuts, so there must still be some pesky Javascript somewhere :(

For that I use Thunderbird or my Android email client.

JavaScript is like a permission in andoroid or in an addon for the new firefox. If I feel like the website really requires Javascript or benefits greatly by Javascript then I will allow it to use JavaScript. Otherwise I will use the website without Javascript or if it is not usable I will just leave. It's ok to add enhanced features using Javascript. But basic features should work without. If links (<a>) don't work without JavaScript I leave and pick the next search result.

One has to agree with your sentiment. In addition, I have spelling checked on many sites wherein I do not have javascript active - this is a part of the Mozilla functionality.

There was never a time in the modern web era when JavaScript wasn't widely used. You'd have to go way back pre-2000 to find a time when popular websites didn't use JS at all. The Cambrian explosion of 'Web 2.0' wouldn't have happened without JavaScript and we wouldn't be where we are - doing everything on the server sucked big time, I do not want to go back to party like it's 1996.

To use Gmail, the poster boy of Web 2.0, as an example of why sites don't need to use JavaScript is bizarre. It destroyed other webmail sites because it used JS to give users a real GUI mail client on the web - the HTML backup works, but if that was all they'd given us we'd still be on Hotmail.

I thought gmail’s big competitive advantage was giving users 1GB of space instead of 10MB or whatever that other free webmail providers gave us. I don’t recall gmail’s UI being remarkably better.

Also, good spam filtering and alternative access through protocols like imap.

Web 2.0, which "happened" in late 2004 was mostly about user participation a la Wikipedia, Wordpress, etc. It was about tagging things a la del.icio.us. Some JavaScript was used to do crazy things like show full-size images from clicking a thumbnail or making wysiwyg editors. But these thick-client "Single Page Apps" people build today didn't really take off until Backbone.js became popular in ~2010.

Re: Gmail. It won, not because of its slick JavaScript features (really, there weren't many when it came out in 2004). It won because of the impressive (at the time) storage space they gave you.

Although the Wikipedia page may say Web 2.0 was about user generated content and tagging, from a web dev point of view it was about building rich interfaces and using XHR to update content without a full page refresh. Full size images had nothing to do with it.

My point is that JavaScript has it place in modern web dev, and saying we should just get rid of it is ridiculous, and not what this article says at all.

Gmail won for many reasons, but usability was a big part of it, and it wouldn't be possible to even auto-complete an email address without JavaScript

Gmail had an exceptionally well UI, minimal and highly usable. What is bizzare that mailers were extremely bad and you didn't even needed to compare them to Gmail.

JS had maybe it's share, but Gmail was minimal, condensed and fast. Literally no one had that back then and today no one knows because competition is dead. Now every webapp is JS heavy, but there is still a great difference in minimalism. Not saying that google products are small, but they seem to have a better balance in "fancy" user interaction than the rest of the web. The reckless transition to a modern web with more bells and whistles takes it's toll, mostly because "we can", but it should be "make sense here".

I agree, but I would say that Google are performance addicts because of their scale, where seconds actually count.

Most apps are never going to be 'web scale', and most of the time there's no trade off to make. Either the devs use libraries to make something work fast and live with a big js bundle, or they optimise too early and go down the perf rabbit hoe and run out of runway. If your product is of enough value your customers aren't going to care about 1-2 seconds, and if it becomes an issue you can do the perf work later.

Hell, even seconds seem like too much. Google's large enough that they can justifiably be concerned about milliseconds.

Your argument is essentially "sites that need JS as a core requirement to the UX need JS" and "now that everyone uses JS no one shouldn't."

My argument is "most sites need JS as a core requirement of their UX". Whether they need 1Mb of it is very doubtful and that's what the original post is about.

A natural candidate for a desktop app.

I definitely admit it's a simplification that won't fit every scenario. It just turns out to be pretty apt for my web experience personally.

Maybe another way to put it is that I don't mind enabling and loading JS for a site where interactivity is clearly core functionality, but if it's essentially serving text, then a JS-heavy design feels like it's working against the user, not for the user.

Reply on news.ycombinator.com