Stop Pushing JavaScript(unixsheikh.com)
unixsheikh.com
Stop Pushing JavaScript
https://www.unixsheikh.com/articles/stop-pushing-javascript.html
17 comments
The point is pushed a little forcefully and I would say from an extreme camp, but there are definitely good facets being presented here. Fighting for good accessibility in SPA websites is a huge chore because for some reason nobody gives a shit.
Writing like this makes it very hard to take the author seriously. I guess it’s supposed to be a rant?
> You do remember what plain HTML is right?
> Web development is not about how to make the work fast and easy for the "lazy" frontend developer who long since has forgotten how to manually do anything and as a result no longer knows or understands how to put a simple website together without the use of a barrier producing framework or technology.
> You do remember what plain HTML is right?
> Web development is not about how to make the work fast and easy for the "lazy" frontend developer who long since has forgotten how to manually do anything and as a result no longer knows or understands how to put a simple website together without the use of a barrier producing framework or technology.
> The optimal solution will always be to make sure that basic functionality works without JavaScript.
That's not the world we live in.
Already since the inception of the Web, the browser has been perceived as far more potent then simple rendering of hypertext. Rich Web Applications have always been part of the larger vision. It's the idea that you can deliver entire functional applications - interactive user experiences - to the end-user without having to install anything on your computer.
Remember Flash, Silverlight, Java Web Applets? All of these were attempts to fill a functional gap that browsers lacked through the 90's and 00's. The implementation of browser API's over the decades have allowed for the development of rich web experiences. For better or worse, the gateway to interact with these API's is JavaScript. Even so, the language is by and large inconsequential to a degree: the same basic concerns - security, accessibility - would always remain if browser API's were implemented in any other language.
> And the fact of the matter is that the majority of frontend developers aren't developing applications for niche markets with specific JavaScript requirements, rather they are developing regular websites, applications that in the end are just plain simple HTML.
There's no clear separation between "applications" and "websites". It's a spectrum. There are applications that render static hypertext, and there are websites with components that really act like applets. Hybrids do exist. And they are a completely valid business case.
Yes, accessibility and security are concerns. But treating them as a categorical imperative while ignoring the diversity and complexity of what the Web has grown into, well, that just won't do.
That's not the world we live in.
Already since the inception of the Web, the browser has been perceived as far more potent then simple rendering of hypertext. Rich Web Applications have always been part of the larger vision. It's the idea that you can deliver entire functional applications - interactive user experiences - to the end-user without having to install anything on your computer.
Remember Flash, Silverlight, Java Web Applets? All of these were attempts to fill a functional gap that browsers lacked through the 90's and 00's. The implementation of browser API's over the decades have allowed for the development of rich web experiences. For better or worse, the gateway to interact with these API's is JavaScript. Even so, the language is by and large inconsequential to a degree: the same basic concerns - security, accessibility - would always remain if browser API's were implemented in any other language.
> And the fact of the matter is that the majority of frontend developers aren't developing applications for niche markets with specific JavaScript requirements, rather they are developing regular websites, applications that in the end are just plain simple HTML.
There's no clear separation between "applications" and "websites". It's a spectrum. There are applications that render static hypertext, and there are websites with components that really act like applets. Hybrids do exist. And they are a completely valid business case.
Yes, accessibility and security are concerns. But treating them as a categorical imperative while ignoring the diversity and complexity of what the Web has grown into, well, that just won't do.
The article disregard that most of the time JavaScript is introduced into the fray because the product needs some level of interactivity that cannot achieved without it.
JavaScript right now is the only way a program can run in a page on the browser side.
The article also conflates problems caused by 1.) JavaScript being a hard dependency of an application, a misarchitecture, and 2.) low JavaScript code that is common in the wild
Those are different problems with different solutions. Both can be solved without removing JavaScript.
There are technology which can help reduce the importance of JavaScript in the client side. GatsbyJS is one of them. It allows generating static site and dynamic frontend app depending on what you need. Although GatsbyJS has its own problem that sometimes shoot you in the foot.
What we need is to raise awareness to service and product providers that browsing without JS is a thing! That way the whole industry can move in a more efficient manner. Rather than a struggle between engineering and product team, it will be the provider's struggle to provide for paying customers.
Meanwhile low JavaScript code quality in the wild - I don't really have a solid idea for it. I can be sure that wisdom can be gotten from the days of old where resource are scarce and things have to be super smart in order to work. There are hidden engineering gems and wisdom over there, but I don't know how to propagate it quick enough to match the growing number of devs. Meanwhile devs will keep coming because of the high demand and nowadays low barrier of entry. What we can do is to encourage the culture of rigor, thriftiness, and constant learning to keep code quality high.
JavaScript right now is the only way a program can run in a page on the browser side.
The article also conflates problems caused by 1.) JavaScript being a hard dependency of an application, a misarchitecture, and 2.) low JavaScript code that is common in the wild
Those are different problems with different solutions. Both can be solved without removing JavaScript.
There are technology which can help reduce the importance of JavaScript in the client side. GatsbyJS is one of them. It allows generating static site and dynamic frontend app depending on what you need. Although GatsbyJS has its own problem that sometimes shoot you in the foot.
What we need is to raise awareness to service and product providers that browsing without JS is a thing! That way the whole industry can move in a more efficient manner. Rather than a struggle between engineering and product team, it will be the provider's struggle to provide for paying customers.
Meanwhile low JavaScript code quality in the wild - I don't really have a solid idea for it. I can be sure that wisdom can be gotten from the days of old where resource are scarce and things have to be super smart in order to work. There are hidden engineering gems and wisdom over there, but I don't know how to propagate it quick enough to match the growing number of devs. Meanwhile devs will keep coming because of the high demand and nowadays low barrier of entry. What we can do is to encourage the culture of rigor, thriftiness, and constant learning to keep code quality high.
I thought the article was going to be about "stop push Javascript outside of the browser", which would have been a bit more interesting.
There are web applications and there are web documents. Both utilize HTML and CSS. Applications typically also need JavaScript.
We've been discussing, no arguing, whether web technologies are appropriate for building applications. It's a moot point now - we've been doing it for twenty years. The horse has done left that barn. Besides, we don't have an alternative that's nearly so multi-platform across a wide variety of devices. For better or worse I simply don't see web applications or JavaScript going anywhere anytime soon.
We've been discussing, no arguing, whether web technologies are appropriate for building applications. It's a moot point now - we've been doing it for twenty years. The horse has done left that barn. Besides, we don't have an alternative that's nearly so multi-platform across a wide variety of devices. For better or worse I simply don't see web applications or JavaScript going anywhere anytime soon.
I think frontend developers are not pushing Javascript. They are pushing cross platform development and distribution environment with UI rendering, REPL, debugger and profiler, which is able to run on almost every consumer device. There are no competitors here. Unfortunately JS comes as the default language in that otherwise brilliant package. But it does not mean you should use JS - fortunately due to it's simple and permissive nature JS has become a platform for tens if not hundreds of other decent languages.
The article feels like a plea to go back to the 80s and it's not entirely clear who the author is pleading to. There's no cabal of Frontend Developers pushing their Agenda. Instead there's employers, customers, and requirements. Can I write a serverless React-esque web app without using any Javascript?
The author also keeps mentioning "simple" web pages that shouldn't require JS (eg personal blogs), but in practice very few people code those from scratch.
The author also keeps mentioning "simple" web pages that shouldn't require JS (eg personal blogs), but in practice very few people code those from scratch.
Everything is awful, can I code in C again please?
I’m having a hard time imagining the post changing anyone’s mind. It read more like a rant than a request or call to arms, and I found the arguments to be thin versions of what the HN crowd will be familiar with.
I hope to be wrong and that more people will eschew JavaScript by default. Has anyone changed (or considered changing) their stance on JavaScript after reading?
I hope to be wrong and that more people will eschew JavaScript by default. Has anyone changed (or considered changing) their stance on JavaScript after reading?
I got a few sentences in and couldn't take it seriously so came back here to read the comments and see if anyone else felt the same way.
Haha exactly what I did too. Honestly Javascript is wonderful, should be used and provides a solid foundation for the Internet's foreseeable future front-end (and back-end) development. The only thing one should be weary of when using JS is accessibility and SEO, which can now easily be taken into account. Security is not more of an issue than with any other language.
As we say in Australia... yeahhh but nahhh
Sounds like someone is making excuses for not learning modern web development, and is writing rage posts instead.
Security or bad code are potential issues regardless of the language. Stop pushing bad articles ;)
Does markdown have security issues, regardless of the fact that it isn't executed? It is a markup language, so by your comment it will.
"Another point worth mentioning is that more and more people disable JavaScript uncompromisingly, using extensions such as NoScript, due to very valid security concerns." - source?
"If a website isn't working without JavaScript it is loosing potential visitors and customers on a regular basis." - none of my clients would want such visitors or "customers" anyway.
Now, I don't think JS should be used for everything, nor do I think the JS ecosystem is made of well designed code, but I think we should definitely stop pushing for bad HN content such as this one.
I genuinely wish there was a debate around alternatives to JS in the browser, but around better written articles.