Advancing JavaScript without breaking the web | Hacker News Reader

Advancing JavaScript without breaking the web

christianheilmann.com

29 pointsrobin_reala7 comments

> That’s why it is good practice to not rely on JavaScript, but instead test for it and enhance a markup and page reload based solution when and if the browser was able to load and execute our script. This is called progressive enhancement and it has been around for a long time.

ONLY only for webSITES not for webAPPS. For Webapps I pretend js-disablers don't exist. For something like a blog, news site, etc yes it should work without JS but if one more person tries to tell me to support people with JS turned off in a webapp I'm going to blow. I simply can't be asked to push the envelope AND support people living in the dark ages. This was fine when we just used JS for some client-side validation or the like but now I'm working with drag/drop interfaces, maps, ajax, single-page apps, and more. Those simply DO NOT HAVE non-js fallbacks without writing shit load of duplicate server-side code. Now node.js may offer a way around this (render on the server-side the same templates that are on the client side) but I'm still not sure how you are supposed to replace a auto-complete dropdown for something like tagging friends or just sending a message to a friend on facebook...

If there are enough people to justify making a non-js version then great, here is an IDE, get started, do it yourself I'll even put a link to your site in my noscript tags. I'm past using JS like a little sugar you sprinkle on at the end of a project, it is integral to most of what I write.

Please show me a company (not Google/FB/etc) that supports a non-js and JS version of their site (A site that is interactive, not a blog or similar).

Your comment inspired me to check out what happens on Google Drive with js disabled - it just never loads and says "Your browser must support JavaScript to display the Google Drive web user interface."

But is it people's fault you are misusing document markup and scripting languages to build GUIs?

I don't see it as misusing anything. Has the web changed drastically in the last 10 years? Yes but just because we are using it differently doesn't mean we are misusing it. I'd argue that HTML5 and ES6 push the web even firther into webapp territory.

> There is no progressive enhancement way around this issue, and an opt-in string doesn’t do the job either. In essence, we break backwards compatibility of scripting of the web. This could be not a big issue, if browsers supported ES6, but we’re not quite there yet.

This post misses the single most important tool for users (to help them try syntaxes), framework developers (to help them be more productive and consistent), and standards developers (to get feedback):

Transpilers.

Because much of ES5 is reflective (and ES6 even more so), it makes a great target for the translation of a new syntax into old syntax. This cycle of reflective-api-to-new-syntax is exactly what Yehuda is talking about in his post http://yehudakatz.com/2013/05/21/extend-the-web-forward/.

The impact of transpilers on ES module syntax, ES classes, and ES promises as been amazing. You can see the same thing happening with decorators/annotations today- real world use in TypeScript is influencing the discussions of TC39.

> The current support table of ECMAScript6 in browsers, parsers and compilers doesn’t look too encouraging. A lot is red and it is unknown in many cases if the makers of the products we rely on to run JavaScript will take the plunge.

I disagree in the strongest terms. ES6/E2015 is a huge amount of changes, and browsers have been driving the discussion and implementing items as they have stabilized.

>> The current support table of ECMAScript6 in browsers, parsers and compilers doesn’t look too encouraging. A lot is red and it is unknown in many cases if the makers of the products we rely on to run JavaScript will take the plunge.

> I disagree in the strongest terms. ES6/E2015 is a huge amount of changes, and browsers have been driving the discussion and implementing items as they have stabilized.

Agreed, I've seen a lot of progress on this front.

Also

> Transpilers

YES, we use babel (6to5) where I work and it's awesome, hook that up with some source maps and you get to write AND DEBUG in ES6. I don't plan on ever going back, my new personal projects all use babel now, I'm already living in a world of ES6 (well for things supported by transpilers and polyfills)

> A broken down escalator is a set of stairs.

Sorry for the convenience.

Reply on news.ycombinator.com