I side with Google on this one. IMO we should be breaking JavaScript more often, especially in the name of performance, to make people use less JS and simpler JS on their websites.
Google.
Google is also the pusher of some of the WebAPIs that will give browsers more access to your system (e.g. WebUSB [1])
Do you think Google is breaking JS to make themselves using less JS?
Consider that, to the user, these are all seen as website problems. Breaking Javascript with consensus is great - breaking designs without blame is a slap in the face to web developers.
Why stop there? I say let's make "if" conditions randomly work on false values 1/1000th of the time. That will teach them.
Also if it weren't JS, would it make a difference if the bullshit is created by lisp, java or erlang?
A UI markup language could define forms that are "desktop-like" without involving a Turing complete language.
The paradigm of the HTML form with controls and a submit action has not been developed to its full potential, because it was basically derailed by JS.
It could have a lot more widgets, and there could be some standard way they exchange and validate data, without a full-blown client-side programming language.
For instance, say you want the user to pick a date. There could be a standard widget in HTML for doing that that could be dropped into a form, and it could be configured to communicate its value bi-directionally with some other field. (Perhaps like cells in a spreadsheet or that sort of reactive thing.) A rich set of standard widgets with flexible styling and layout, communicating the content of the data model to and from the server. Something like that.
Yes, I know this is a fool's errand. I don't actually expect this to happen.
90% of what I use the web for is static text and video. And I could live without video. :)
But you know whats gonna happen right? Someone will create a “jqif” library that will run same if 10 times (maybe throw in a transpiler) or whatever then we’ll have 10 times slower javascript that fails with 1/10^11 chance.
Js is here to stay unfortunately.
I'm no believer in Google's faux-altruism, much less sympathetic to their cause (see: AMP). The rollout could've been less agressive, sure. But I don't think equating a step towards sane default behavior with wrench-in-the-gears chaos adds much to the discussion.
It would be a straw man argument as a reply to the article, but it's a reply to a comment that advocates breaking the JS to make developers use it less.
If you need more clarity, see the same commenter's "JS is a pox on the web" comment: https://news.ycombinator.com/item?id=15636056
Though not by pushing it down people's throats in a backwards-incompatible way.
> to make people use less JS and simpler JS on their websites
Let us return to a moment to the WWW's ripe vintage of 1995, when Netscape Communications Corporation released a browser which had 3/4 of the browser market share within a year of release. Their product was advertised as a consistent universal interface to the web. They created custom features for their product, such as SSL, and JavaScript. But many of the features were released to outdo its main competitor, Microsoft, who could dedicate far more resources to development (they had so much cash they didn't even need to charge for the browser!).
Netscape Communicator attempted to be a groupware solution combining multiple products to provide a complete solution for office and enterprise needs. But the design was too monolithic and complicated, and development was eventually halted. Ever since then, many organizations have attempted to build complete groupware solutions, but have been weighed down by the difficulty of developing such a complex suite of applications.
And so came the future. As the web's technologies progressed, so did the capability of content delivered through a "standard" web browser. Even though browsers have traded back and forth over who supports what, most of the time the browser with the majority market share holds all the cards. As long as that browser works the same on multiple platforms, they don't need to worry about cross-browser compatibility, because that isn't their goal. Netscape's original goal was to kill Mosaic, and they did that in spades.
Today, Google provides a mostly-complete groupware solution, delivered on its favorite application platform: its own web browser. The costs of developing and shipping the software to end users are much lower than traditional native apps, and they increasingly control more and more of the pipeline, even to the actual computer (Chromebooks are designed to cement Google's ownership of computing resources, freeing them from the constraints of other vendors' platforms).
They not only don't want you to have "less JS and simpler JS on a website", they don't want you to run a website. They want you to provide an application which runs on their application platform. In service of that goal, they have developed dozens of web technologies designed to further their own application platform, just like the Netscape of old. If they have to break compatibility with other browsers to do it, that's fine with them.
The bizarre thing is breaking existing websites on their own browser. If you can't browse the web reliably you'll stop using their browser, and then their app platform and apps are in danger of becoming obsolete.
If you care about backward compatibility there exists a polyfill for this functionality.
However, that does not absolve Chrome of breaking backwards compatibility, workaround or not. Tossing the responsibility of dealing with their breaking changes back on the developer (with little notice) is what caused this article in the first place.
Web is not a static target. Being afraid to break things gets you a decade of Flash websites. Things that are important will be maintained, and things that aren’t… well good riddance.
Personally, I think we are way past due HTML6. A sort of Vulkan-like platform for Web[1]. HTML5 should be build on top of this next-gen low level platform. That’s the way forward if Web wants to remain competitive. Otherwise in 5 years we’ll all be writing Android Instant apps.
Note that this is essentially what Houdini is for CSS.