Hacker News Reader

Comment by alistproducer2 | Hacker News Reader

I'm a JS evangelist for sure. I love the language, but I'm not a true believer. Believe it or not, I keep JS turn off on my mobile browser because I enjoy instant page loads. I remember the first time a coworker asked me "but what if they have JS turned off?" I thought "what a dinosaur. Who doesn't have JS turned on?" Obviously I had a change of heart on the subject.

I never write JS > ECMAScript 5. Why? Because I want my apps to work in as many places as possible and I don't feel like arrow functions are worth breaking backwards compatibility. I know there are those who will disagree. I'm all for pushing the web forward, but I feel like, in the process, some of us have lost sight of what the web is ultimately about.

View on HN

> I never write JS > ECMAScript 5. Why?

That's a bold statement. Why EcmaScript 5 and not JavaScript 1.4 for that matter?

Programming languages change and evolve. EcmaScript 6 introduces a lot of features, including some that greatly improve the readability, maintainability, and cleanliness of the code. Sure, right now you may need to hold back on some features if supporting legacy Internet Explorer versions is your goal and you don't use a preprocessor such as BabelJs, but at some point the only browsers that don't support ES6 will be browsers that are unsupported by their vendors and inherently unsafe; so why stick with ES5 in particular? Or are you simply waiting for the moment all current browsers support ES6?

I get not wanting to use bleeding edge features supported only in the latest developer edition of Chrome or Firefox, but at some point ES6 is supported in 100% of the browsers people can safely use, and a few years after that ES7, and so on.

> That's a bold statement. Why EcmaScript 5 and not JavaScript 1.4 for that matter?

Because most devices will run most of ES5, very few devices will run any ES6.

Now there are transpilers sure, but I remember a time Javascript was about simplicity and not relying on a complex grunt pipeline + Babel. Now JS tooling is more complicated than Java's only with JSON in place of XML. The irony.

I think for most people the time you save using ES6 features is more than the time it takes to set up a build system, at least for larger projects.

I would have to disagree. There's no way saving a few keystrokes on an arrow function or being able to use 'class' will ever compare to understanding, let alone debugging, gulp streams. IMO JS tooling has gone way overboard, but in code, as in any artform, everything is subjective.

I think you might be misreading the parent statement as "I will never write JS > ES5".

I too find that the easiest to implement features are (not terribly surprisingly!) the least interesting; they are not worth the terrible friction that I'd see in my current organization. I have a hard enough time trying to get folks to write good test coverage and understand the gotchas of writing async code everywhere. So for me, there's way bigger fish to fry than (exaggerating a bit here) saving a few characters with arrow functions.

But that's still not to say I won't ever use it.

you are probably too young to remember the time when using <script type="javascript1.2"> was bold and bleeding edge. (probably got the syntax wrong, because, well, that what happens to memory when you are not too young)

I feel like JS is an expected part of the web just like HTML and CSS. How can you build engaging web applications if you are not even allowed to rely on standards like JS (e.g. if the user turns off JS)?

>How can you build engaging web applications if you are not even allowed to rely on standards like JS (e.g. if the user turns off JS)?

You can, but you an't force the user to interact with your 'web application' in the way you prefer. But you could never rely on the user's browser settings being optimal for the experience you wanted to provide anyway.

If you want absolute control over what the user sees and doesn't see, then build a native app. The price you pay for the ubiquity and convenience of web applications is putting control over the interface in the hands of browser vendors and end users.

> I feel like JS is an expected part of the web just like HTML and CSS. How can you build engaging web applications if you are not even allowed to rely on standards like JS (e.g. if the user turns off JS)?

The web is not about 'engaging web applications'; the web is about webs of interlinked documents. Every time you require JavaScript to display a simple document; every time you load images with JavaScript instead of <img>; every time you replace an <a href=> link with a JavaScript event handler; every time you fail to even link to a page; every time you use JavaScript-loaded fonts to display symbols: you break the web.

'Web application' is a misnomer: it should be 'browser application.' Despite my loathing for documents (e.g. blogs, articles &c.) which require code execution in order to be read, I don't mind browser apps where they make sense. Google Maps makes sense: it doesn't bother me that it doesn't work in eww, or links, or with NoScript.

Blogger doesn't make sense: there's absolutely no legitimate reason for it to show an empty page with JavaScript turned off: Blogger is breaking the web. imgurl's failure to show all images, and Cracked's failure to show any images, without JavaScript makes no sense: they are breaking the web.

People who break the web should be deeply ashamed.

I agree you're getting the most accessibility by making a blog that renders on the server. But rendering front ends with javascript shouldn't be considered breaking the web. It's a tool that's available in the browser, and many use it to try and make a better experience for their overall users. I think it's a shame we have the "first load no content" problem, but developers are doing this with good intentions. Making UIs respond faster, reducing back & forth network requests, and trying to make more interactive content on the web.

There are some warts we need to sort out and get better at, but I still see it as progress.

> But rendering front ends with javascript shouldn't be considered breaking the web.

If it doesn't work without JavaScript, it's breaking the web.

I have absolutely no problem with progressive enhancement. I have absolutely no problem with choosing to enable JavaScript when it makes sense. I have a problem with requiring a privacy-destroying technology in order to consume content.

> rendering front ends with javascript shouldn't be considered breaking the web.

If you want to serve an empty, broken page as a first impression, you can. I strongly recommend against it because it makes your site look half-finished, poorly designed, and generally unprofessional.

> available in the browser

That isn't always true. You don't know anything about the browser a priori.

> make a better experience

Of course. Javascript can add nice features, which is why you progressively enhance the page to add features when the underlying requirements are available. Do you skip the check for NULL when calling fopen(1)? Checking for errors is always important. On the web, this means you should gracefully handle problems like missing javascript (intentionally or otherwise) or other resources.

> Making UIs respond faster

Requiring two additional HTTP requests (one to load javascript, and another to load the actual page content) isn't making the page faster. After the first request your javascript will be available most of the time for partial loads in any case.

> interactive content

That is rarely a good idea, but it's your page so do what you want. Progressive enhancement doesn't affect this at all.

Do you develop, professionally, for the web?

I think you and I are talking about the same thing. I was more responding to the extreme circumstances the other person posted. I agree that when you're making public facing content, it should render on the server. The faster UIs is true when you don't have to do full page reloads to load new content, but just grab serialized data from the web server instead.

I agree with your distinction between browser application and the web. Its very frustrating to be bombarded with tons of javascript that introduce nothing of value; usually advertisements and petty fanciness.

But that being said, ive been developing a heavy javascript SPA ( Single Page Application ) and have been writing javascript that is going to be very useful to (certain types of) users.

Im more than happy to download a large bundle of javascript (and css) if im getting an application (and preferably not on my phone)

And in defense of SPA's which dont even have web in them, good ones are a portal to a location on the web (a model type and id) loaded usually via json with html re-rendered on the client. And even better ones have history implemented. So they can feel very like the web...given js is enabled(!)

But of course I understand the "why reimplement what browsers already offer?" SPA's feel almost indistinguishable from a desktop app if done right...

What are your opinions on SPAs?

> What are your opinions on SPAs?

I think that some of them make sense, but many many many would be better implemented as RESTful apps instead. Once the REST layer is written and works without JavaScript, implementing an enhanced version which requires JavaScript and minimises redownloading of new data is relatively easy.

Imagine a chat app. The pure-HTML version could serve a chat message at /chats/{partner}/{message-id}, with a prev link to the previous chat; it could serve a chat sequence at /chats/{partner}/{message-id}?history={length}; it could redirect /chats/{partner} to the most recent message in a sequence. A form could easily enable POSTing a new message to the chat.

Once all that's done, it's dead-easy to write some JavaScript which ties it together in a single-page app. Instead of requesting each message as text/json, the JavaScript client could accept application/json (or another format, if you like). It could subscribe to a WebSocket or server events. It could do anything — but the basic HTML-based app would still work, and be usable from a command line, from a simple phone, from anywhere.

> the web is about webs of interlinked documents

If this is true, and my browser can follow a link to a Blogger page, displaying the intended document using universal browser features, then the Web is not broken.

This kind of evangelism makes no sense. The whole idea that "the Web is about documents, specifically" was shattered as soon as Javascript was added over two decades ago. It's no longer about that idea and hasn't been for a long time. Interlinked resources, yes, and documents became a subset of that idea in 1995.

The desire for document-type content to display without JS stems from a strange desire to see the technology used how it was invented in 1990. The Web was hodge-podge of technology then, and it's even more so now. If you intend to pick and choose what parts of the hodge-podge to use, you will find yourself frustrated forever. And you gain no advantage by arguing "but I want the _original_ hodge-podge to work with the type of content it was design for!".

JS _is_ the Web just as much as HTML because all (Edit: popular) browsers support it. As soon as that happened, compatibility with the Original Hodge-Podge was dead, permanently. For better or worse, that is the reality.

It also comes from a desire to use tools that are not browsers on the web. To archive, to search, to display them nicely when sharing them, ...

I agree.

Before the prevalence of JS you could simply download the text. But now, much of the text interpreted. So if you wish to get all the text, you must also do the interpretation step. Which essentially means running a headless browser to pipe it to you. And it's simply not practical to tell your text sources to avoid using so much interpreted text. They're using Web standards.

> If this is true, and my browser can follow a link to a Blogger page, displaying the intended document using universal browser features, then the Web is not broken.

Your second premise doesn't hold for all browsers: links cannot display Blogger pages; Firefox with NoScript cannot display Blogger pages; the Tor Browser with high security cannot display Blogger pages.

The Web is, fundamentally, about resources — documents — and their state, not about behaviour.

> JS _is_ the Web just as much as HTML because all browsers support it.

No. They. Don't. eww doesn't. w3m doesn't. lynx doesn't. links doesn't. elinks doesn't. Firefox with NoScript doesn't. The Tor Browser with high security doesn't. That is the reality.

The reality is also that allowing JavaScript exposes users to severe privacy and security threats. Disabling JavaScript is the only way to control those threats.

Every site which requires JavaScript to function is like a serpent tempting a user into giving up his privacy and security. That is the reality.

> Firefox with NoScript cannot display Blogger pages; the Tor Browser with high security cannot display Blogger pages.

These configurations disable universal features, so the premise holds.

> The Web is, fundamentally, about resources — documents — and their state, not about behaviour.

Yes, in 1990. Also, you choose to conflate "resources" with "documents".

> w3m doesn't. lynx doesn't. links doesn't. elinks doesn't

These are browsers that choose parts of the standard hodge-podge and they suffer for it by not being able to display all pages.

I'm not arguing the situation is great or that you should like it. Hell, I don't even like it. Your criticisms of JS are valid. But your expectations of how the Web should work are _broken_ and they would have been broken 20 years ago. Whether it's 1996 or 2016, the only way your reality could come true is if there was an HTML-first programming style enforced universally. It's so impractical it's barely worth mentioning, so why evangelize?

> These configurations disable universal features, so the premise holds.

> These are browsers that choose parts of the standard hodge-podge and they suffer for it by not being able to display all pages.

So, the Web is not broken because all browsers which use a feature are able to display pages which use a feature — anyone who disables that feature is responsible for breakage due to pages using it, and anyone using a browser which doesn't support that feature is responsible for choosing such a browser.

Your logic would justify every vendor-lock-in attempt from Apple & Microsoft; it would support the idea that all the Internet's IE.

> But your expectations of how the Web should work are _broken_

No they most definitely are not. My expectations of how the Web should work are based on mathematical truth. REST is symbolic manipulation: it's correct in the way that only math can be.

> Whether it's 1996 or 2016, the only way your reality could come true is if there was an HTML-first programming style enforced universally.

Not HTML-first, resource-first. Figure out what your resources are, figure out how they are related, figure out what behaviour makes sense, then wire it all together. Once you have all your resources (images, HTML, whatever) working well, then feel free to wire it up with JavaScript.

HTML's power is that it is declarative, not imperative. It shares that character with plain text: when you read my words you do not give me root access to your brain. No-one should be forced to execute unknown, newly-served code in order to read a document.

When you require JavaScript, you break the Web. Please don't.

> Your logic would justify every vendor-lock-in attempt from Apple & Microsoft; it would support the idea that all the Internet's IE.

Except in this case the "vendors" are the makers of every popular browser and the standards body governing Web technologies. Not exactly apples-to-apples.

> My expectations of how the Web should work are based on mathematical truth. REST is symbolic manipulation: it's correct in the way that only math can be.

Right, a programming style. Your 'mathematical truth' is arbitrary given current web standards. The lack of it does not break interlinking, which, by your own admission, is what the Web is about.

> Not HTML-first, resource-first. [...]

You didn't actually address the fact that you would need to have everyone follow this style. You expect the Web to work in a way that can never be enforced; that is a broken expectation. I agree, this is the way it should be done but it's completely obvious it won't ever happen. The incentive to follow that style is no where near enough to generate any sort of defacto standard. So why evangelize?

I just wanted to say this is a really fascinating comment, and it's given me a lot to think about. It's an interesting perspective that I haven't run across before.

> I feel like JS is an expected part of the web

You feel wrong. I enable it when I have to, only.

> How can you build engaging web applications

Not my problem. I want quick loading sites with as few malware vectors as possible.

You should be building web applications which facilitate the transfer of information. You don't need javascript and all the other crap people are using these days for that. I mean, if you're all about pure eye candy and doing..I dunno, mandelbrots or something in the browser, then yeah, you're going to need javascript. But it's not going to work on mobile. Hardly anything like that works on mobile, which is fine by me; I do most of my browsing there.

To be honest, I think there's a market for a firefox addon which removes links to sites which don't work on mobile/require you to have javascript enabled to save me the effort of clicking back when i arrive at am empty page or when the screen is dimmed and all I can see is the corner of some dialog I have no interest in zooming out to look at.

A few months ago I wrote a web-app that lets you pick an image off your computer, and convert it to a cross-stitch pattern.

I did it using javascript entirely client side, so it works offline, it's secure (as it doesn't send the images anywhere), and it is fast to load (letting you change settings and get the new cross-stitch in the blink of an eye).

With your idea of doing things, i would need to pay for a server (and would probably need to then charge my users who wouldn't pay, so it's now DOA), it would be significantly slower, it would be less secure/private, and wouldn't be able to do things like auto-change the size of the resulting image depending on the screen size of the browser (important for mobile! don't want to overload the browser with massive images).

That needs javascript, and for you and others to keep acting like anything that uses javascript is a toy that shouldn't exist is arrogant and wrong.

You should be shipping that as a browser extension. As it stands it's not good as a website, but it meets every criteria for a good extension.

It's even the kind of thing that passes for a native application in Chrome OS.

But if i shipped it as a "browser extension" i would need to make multiple versions for each browser, and it wouldn't work on most mobile devices...

And even as an app it's not that good. It's very single-purpose, there aren't really any "settings" that need to be saved, an app for this would be overkill.

As a website, it's quick to find on any device (desktop, laptop, phone, my damn TV!), it's extremely fast to install (if it takes more than a second to load on home internet i've done something wrong), has little to no footprint on the disk of the device, and does one thing and does it well.

> How can you build engaging web applications if you are not even allowed to rely on standards like JS (e.g. if the user turns off JS)?

What do you do for accessibility? Screen readers etc?

> How can you build engaging web applications if you are not even allowed to rely on standards like JS (e.g. if the user turns off JS)?

I think it skews the conversation to talk about JS being "turned off", rather than unavailable, as it assumes that every user agent (browsers, screen readers, crawlers, CLI commands, etc.), even those cobbled together 5 minutes ago to do one quick job, is capable of running JS, has a DOM, is up to date, implements various APIs, that those APIs even make sense (what's the screen resolution of wget running in an SSH session?); and that the user has manually told it not to.

>I never write JS > ECMAScript 5. Why?

Because you started too early during the web's rise, and are now too old for that...

>Because I want my apps to work in as many places as possible and I don't feel like arrow functions are worth breaking backwards compatibility.

They are not, since everybody uses them with Babel.

> Because you started too early during the web's rise, and are now too old for that...

ES6 has some nice features -- all other things being equal I'd chose to write it over ES5. Or even ES3, since it fits with that sloppy ageist accusation you tossed off.

As soon as you say "Babel" (or another transpiler), though, all other things are not equal. I've already chosen to work with ES6 anyway in some circumstances, but honestly, when it comes down to it, the benefits are marginal enough over ES5 that there's a reasonable case that anyone already effective with ES5 doesn't need to transition.

And I might even go so far as to speculate that a programmer who is unable to be effective with ES5 might simply be the kind of programmer who can't really be effective whether they'd be working with Python, Ruby, Go, C#, whatever... but that would probably be tenuous bullshit on par with assuming anybody who doesn't want to add a transpiler to their toolchain in order to do essentially the same things they can do without it is Just Too Old.

The problem is not with the individual programmer. One can make wonders with Commodore assembly too. Of course they can do stuff in plain JS.

But they'd be reimplementing the wheel a lot. If you want to take advantage of the JS ecosystem as it stands in 2016, you need to use its tools.

E.g. just consider using React with JSX -- you already need a transpiler for that.

Reply on news.ycombinator.com