JavaScript Is the CO2 of the Web [audio] | Hacker News Reader

JavaScript Is the CO2 of the Web [audio]

changelog.com

105 pointsfeross124 comments

He has some great points.

For 5 or so years I've been the guy who immediately started a SPA and I've turned 180 degrees. I now think SPAs are basically a cancer, with some exceptions where an app-like website is justified (Gmail, etc) or a hybrid app. SPAs introduce unnecessary complexity and bloat for the vast majority of use cases.

JavaScript should be used like a condiment instead of a whole meal. It's led to the bastardization of the web in my opinion.

Like, all we have for dinner is tomato ketchup.

I'm with you. It occurred to me that what I love about things like react or vue has nothing to do with SPA capabilities. It's just developer ease in building reusable, composable, testable components.

I've had similar experiences with scaling too early into microservices for example. I need a seriously compelling reason to consider building around these paradigms now. The overhead is unreal.

Both great ways to solve a problem, but not really a problem I've yet encountered - ever.

I'm still glad I've had great opportunities to learn this, at least.

Thing is, building reusable components was always a feature of SSR Web frameworks since early 2000's, so there is no need for react or vue for bundle the HTML/CSS/JS that makes a fancy calendar widget.

And with WebComponents being supported across the board, even less so.

Web components are useless, you can't pass values around without converting them to string or employing a non-native mechanism, and of course you need to do all DOM updating by hand - which is both way worse than just using React from various perspectives.

Only from the point of view of React devs with their anti-WebComponents agenda.

Everyone else is just embracing them.

There are no tools to embrace them, there is no way to make an universal web component like you can do with a React component without severely limiting what you can do and how you can develop it and how it performs. It's very sad, I'd love to use native Web Components but it's so bad it hurts (or you end up reimplementing incompatible React).

Yep, again the anti-WebComponents message.

Angular, Vue, Polymer, Svelte and a couple of Web based RAD editors look like tooling to embrace them to me.

Since I don't have any plans to ever use React, how does your magical component work with my tooling?

My component is "magical" thanks to the React ecosystem and because it uses the tools the React platform provides to greatly integrate with said ecosystem. The tools you suggested are not comparable to React - React Hooks and Contexts are the part I'm most interested in.

If you use different tooling, then it doesn't work, and that's okay. You don't need to care about React and I don't need to care about Web Components. It was suggested that React is useless and should be replaced with Web Components, and I'm simply saying that Web Components are not sufficient to replace React, not that you should switch.

Naturally my tools are not comparable to React, because by targeting WebComponents they support everyone on the browser instead of the React developers silo.

And best of all, they are even usable from React.

You're not understanding what web components are.

They alone are not a replacement for the entirety of frameworks, they are low level hooks that standardize the more fundamental level of frameworks: component instantiation, component lifecycle, and style and DOM encapsulation.

Higher level features like DOM rendering are left to libraries, and there are some really good libraries for that. And I'm not sure what you even mean by the libraries limiting what you can do how you can develop. There's way more choice in the web components ecosystem than within any single framework.

I think the biggest difference is that I consider DOM rendering a low level feature that should be abstracted away lowest as possible.

Web Components are HTMLEelement instances, which are ordinary JavaScript objects on which you can set properties without any "non-native mechanisms":

`document.querySelector('div').someProperty = {some: 'value'};`

For DOM updates you will generally use a declarative DOM rendering engine like lit-html, just like how you use React's VirtualDOM. In fact, the most popular Web Component "library" [LitElement](https://lit-element.polymer-project.org/) uses very simlar vernacular as React (like the `render()` method), and from a developer perspective feels exactly like using React, except it relies more on builtin platform features.

This is just so wrong. Where did you hear these things? You've obviously never actually tried web components.

So I can pass a complex value as a prop without needing to convert it or catching the underlying HTMLEntity? The tree will update once a property updates?

Ofcourse you can pass properties, I'm afraid your information is wrong in both cases.

A small demo https://jsfiddle.net/zu52o7bq/.

Sorry but this is in no way comparable to what React Hooks, React Contexts and React component props offer, plus the non-existent component lifecycle. I even have to render it myself! Inside the component!!! Where is separation of concerns? And why do I need to register it? I just want a class/function that behaves like a component (with a lifecycle and managed rendering), no registration whatsoever.

These are not React-like components - independent reusable universal blocks that can be used without any knowledge of the component other than that it uses React.

You stated one can't pass props around and you have to resort to strings (this incorrect statement is posted to HN so often I'm curious where does this knowledge comes from).

I just proved you wrong with this simple demo, so you waved that away and pulled out hooks argument.

How is that related is beyond me (not to mentioned hooks are fresh in react world too). If you want to have a discussion at least have decency to not change subject randomly, it is annoying.

BTW. You can use both hooks (via haunted project) or redux (lots of people do that) with WC's just fine. In fact I wrote code that looks almost the same in react and lit-element.

I think we misunderstand each other because of terminology. You understood me as class props, but what I meant is component props: <Component prop={something} />. In React world this is different from class props because if the prop changes it also causes the component to update. React separates the component "template" (class or function) and "node" placed in the component tree, the props are updating the node contrary to WebComponents where you have a class instance directly. In WebComponents I have to catch the underlying HTMLEntity and then set the props on the class (in React we're not setting the props on the class itself, it's separated for the ability to handle updates) and then handle all updates myself instead of just passing the complex object as a prop.

Hooks are an extension of that - it is a different way to pass values around, a very powerful one.

Yes what you need to do as a workaround is a BUG in react, not a problem with WC's - and I think Dan Abramov tweeted that this will be solved eventually (I can't find the exact tweet) - In Vue, svelte, Angular or even preact you would be able to do <my-component prop={something} /> just fine, no need to mess with HTMLEntity. If this is fixed this should be transparent to you and work the same way, you should be able to mix and match both kinds of components.

See here https://custom-elements-everywhere.com/ a list of popular libraries and how they handle events and props.

I meant when I'm not using react

I have no idea what you meant by that statement.

I didn't talk about React-WC cooperation, I was talking about passing props around WebComponents when using WebComponents alone - it allows you to pass only plain values, otherwise you need the underlying HTMLEntity

I still have no idea what you mean by that, implementation detail? I have passed props using WC's alone in a declarative way via LitElement - all other popular solutions allow that too.

The html version of gmail still works great! It also loads in under 30 seconds (near instantly for me) and is incredibly snappy. It also doesn’t look like a PM vomited google product integrations over the screen.

> It also loads in under 30 seconds

Jesus Christ what is going on with the web.

I have a theory. Search is a Killer Feature. And I mean that in the most extreme and broadest way possible. The user interface paradigm of "type a bit of what you want, hit enter, click and immediately be using what you want" was, in hindsight, what users wanted/needed. It was so completely successful that nothing else mattered. It didn't matter that web apps are fundamentally flawed, introducing ridiculous latency on all the other simpler interactions (would you tolerate 200ms latency for a clientside application to respond to you clicking a button?), throwing away all of the work done to create and present unified user interface elements, enabled every click and action to be surveiled, profiled, and datamined, added points of failure completely outside of the users control, locking user data away in someone else's systems, etc. None of that could outweigh the gargantuan power and usability of search. Desktop OS' still aren't treating search as a first-class citizen. You still can't just search and be using a new application nearly immediately. Mobile gets close with their app stores, but there's still friction there. Even though the W3C adamantly refused to acknowledge the web as a platform for interactive applications for 2 decades, it just kept growing and more was shoehorned into their static document presentation system no matter what they did. It amazes me how difficult it still is to find an application that does what you need, download it, install it, then launch it. Unsurprisingly, even that relies upon the web to accomplish the first searching portion. I like to dream that perhaps we are approaching a sort of convergence, though. The web makes sandboxing less and less relevant as users data is all migrated into remote services (protecting your data is what sandboxing was FOR, right?) while desktop OS are making clientside sandboxing and containers easier and easier. Technology never fails to be interesting to watch while it develops alongside us.

I don't think this is true at all. In fact, I have a hard time believing users actually prefer the web over native apps at all. As you say, web apps are pretty terrible. They will never be as fast or reliable as native apps.

> You still can't just search and be using a new application nearly immediately.

You can't? I sure can. Gnome, kde, and Mac all have great ways of searching through your apps. The windows search is a little crap.

But the great thing about a local, native environment is that the user is actually in control. If there is an app I need quick access to, I can map it to a shortcut or desktop icon. That's way faster that searching and scrolling through results.

From my non web dev perspective, the reason there is such a proliferation of bloated web apps is because of the devs. All of a sudden we have a ton of developers with little to no formal training who want to make cool apps instead of good products. So they layer on plenty of dependencies. And when there's a Cool New Framework© next week, they'll incorporate that too.

I just don't think devs have performance and user experience as number one priorities. The web will always be horribly slow compared to an SSD. In my opinion, the web has a couple of other fatal flaws that make it inferior to native for applications. But if we do want the web to be where all our applications to live anyway, we need to be concerned about performance as a high priority.

> You can't? I sure can. Gnome, kde, and Mac all have great ways of searching through your apps

He was talking about using new apps, not already installed ones.

And the Windows search works fine as long as you disable Cortana... As sad as that is.

> type a bit of what you want, hit enter, click and immediately be using what you want

This is a nice idea, but it’s far faster to search with mail.app. The great thing about gmail is just labels.

If you use the right tools, SPAs reduce complexity.

The problem is that most of the popular frameworks today add unnecessary complexity.

I still can't believe that we live in a world were most developers are OK to coding with a 5 to 15 second build delay and source mapping during development. I find is extremely frustrating. It slows me down and breaks my train of thought.

> If you use the right tools, SPAs reduce complexity

Like? I am curious: built a few SPAs (quite complex ones) and it sucked; I got the tools/frameworks from HN.

If you use the right tools ‘tradional’ websites are not complex either.

I do think that sometimes you just need a simple static website and then don't need an SPA.

I think SPAs are good when you have to handle a lot of dynamic data. Especially realtime data.

I built a sample SPA with VueJS, Asyngular and RethinkDB to demo how easy it is.

It's a relatively complex app where all the views update in realtime but all the server code is less than 300 lines.

The framework does most of the work; on the back end, all you need to do is define the data schema and access control rules on the server side. See https://github.com/SocketCluster/ag-crud-sample/blob/6805499...

For the front end, I use VueJS in the simplest possible way without any build step during development. I just define my main app component and setup a component for each page: https://github.com/SocketCluster/ag-crud-sample/blob/master/...

For data, I just use my own model and collection components to bind to the server data in real-time: https://github.com/SocketCluster/ag-crud-sample/blob/master/...

The collection component lets you bind to a 'view' which is declared in the schema on the server.

It's just CRUD with realtime subscriptions built into the model and collection objects, nothing special.

You can achieve a lot more if you just keep things simple (at least conceptually) and use the right tools.

If you go the SPA route you have to, at the minimum, add some form of routing and manage application state and logic. It doesn't matter how good the tools for doing that are, there is always going to be an overhead to do that.

That’s a great synopsis of the tricky bits, which I’ve noticed provide the most value to unit test as well.

There is so much entertainment in SPA vs HTML and similarly Vim vs Visual Studio, static vs. dynamic types etc. debates. But to be boring (sorry!) it all comes down to the most approriate tool for the job. At work it's a SPA because it's an application delivered via the web. Delivering via not the web wouldn't work as well, and delivering it as not an application is a non starter.

My current side project is a HTML sprinkled with JS, turn off JS and you can use most of the site kind of thing. Why? Because ... well mainly SEO to be honest. But there you go ... reasons!

Bah, to hell with your boring moderate stance! I would much rather have endless debates with others about why MY hammer is better than their hammer, and ignore the fact that maybe not everything is a nail ;)

Google recently updated their crawlers to understand "full Javascript websites" ; I don't like the term spa as one could build one with pure css and html and still have a single page.

Now onto the js frameworks, it depends on which one is used. One could build a website watching web.dev and use a budget to make sure it's app is lightweight. There are numerous tools to make sure an app is properly made. But tbh, I like my js framework because the community is so great, I know the framework is good even tough there are arguments there and there.

I guess it all depends on the tool you choose and how you build your end product. Now having a website that loads in 30s is a joke I haven't experienced in the modern web, and my js framework actually provides a powerful caching system that makes the website available even tough I could bring down my dns. To this point I presume we are just in a odd point in web evolution where we have discovered a new paradigm and rushed into it's usage without maturity.

These things will change but I think it is important to know that some JS front framework are not incompatible with a lightweight web.

> But to be boring (sorry!) it all comes down to the most approriate tool for the job.

It does. But, depending on how you look at it, either most web companies absolutely suck at picking right tool for the job, or the job isn't really what you'd think it is.

Taking your typical plain webpage done as an SPA, you could either say (as I would) that the authors picked wrong tool for the job, introducing completely unnecessary complexity both on their end and customer end - or, you could tell that the job of that website isn't to be useful to and considerate of the visitor, but to be e.g. CV-fodder for web developers, a way for the team to show off their sophisticated infrastructure, or for the marketing to play their A/B testing shenanigans, or for the company to show off to the investors, etc.

Once you account for all the "parts of the job" that are orthogonal or even opposite to delivering value to users, suddenly a proliferation of frontend complexity makes perfect sense.

I agree completely, use the right tool for the job, it's just that the SPA pattern has been abused.

"SPA" is a fine, if difficult, architectural pattern. One needs to make a distinction between the processes and tools, and the pattern itself. SPAs are bad because of how they are built; personally, I blame the rise of front-end build tools for this. When it's easy to add dependency after dependency, then you get a bloated nightmare. Transpilers don't help, either, since they just remove you even further from "bare metal" of the browser, which is itself already at a dizzy height from the bottom. You might say that modern javascript programmers are too high, so to speak.

I'm working on a dashboard for a personal project. It involves a few dynamically populated dropdowns and a map with custom markers. In the past I might've used jQuery and maybe Backbone in more extreme cases. After looking into the "modern" options available I ended up writing the damn thing in jQuery. I did it in a few hours without having to involve Node, npm (or yarn), hundreds of dependencies (and associated security concerns) or "(com|trans)pilation)" of anything. The whole process reminded me again of why I went from fullstack to working exclusively on backends years ago.

Out of curiosity - did you chose jQuery because it's so ubiquitous or was it the better choice? There are frameworks like vue.js where you don't have to deal with node, yarn, explicit dependencies and transpilation, that offer virtual DOM and have very little overhead.

Better choice ultimately but I suspect the hype around "modern" everything these days would still lead a lot of people in that direction, even for simpler things like this. I did briefly look into Vue and didn't completely hate it. Although the docs (at least from my cursory glance) were suggesting you would need Node to get up and running with it. Good to know it doesn't need to be that complicated.

Good to know. For small personal things that need JS, I too tend to just go for jQuery, or increasingly stick to vanilla JS. React is ridiculously overcomplicated for small projects[0] IMO. I always thought that Vue is just a React competitor/copycat, so never bothered to investigate it. Since you say it offers more lightweight vDOM with no JS NPM tooling bullcrap, I'll look into it, so thanks!

[0] - I used React a bit, and I can only stomach it when working with ClojureScript, which gives some sanity to the syntax and language - but that's another pretty large and very complex dependency to be included in the pipeline!

For these cases I like to use Vue with a script tag. It's smaller than jQuery, probably more convenient, and depending on your use case you can get away with writing ES6 with no babel.

I don't know, on the one hand, JavaScript is without doubt neccessary for a lot of useful things on the web. OTOH, I always thought of JavaScript as a way to get a better declarative web long term, by experimenting with UI paradigms and trying things that eventually can become part of new declarative HTML UIs. But that feedback into HTML never happened, and it seems we're stuck with an incredibly poor language we're enslaving the next generation of both users and developers in. The worst part is IMHO where we attempt to shoehorn JavaScript into a "serious" language with ES6+ classes, modules, new syntaxes, type decorators and what not; all we've achieved with these inessential extensions is to make future browser implementer's life difficult.

I haven't listened to the audio, but all it takes to get rid of JavaScript-heavy pages (that only exist because young webdevs are being taught and drool about mostly JavaScript, React, and other overkill rather than web basics), we just need to step up the game and demand power-efficient webapps, or no webapps at all.

Experienced engineers use react when it is needed for the enhanced ux. JavaScript is actually a decent programming language if you use the functional paradigm and read enough books and ship enough products to understand its strengths and weaknesses. It’s even better with typescript.

I'm building a web product.

The static pages are in static HTML, because of course they are.

But the product pages need to be interactive. To do that, I need to use JS, and an SPA framework (I use Vue) makes that easier and way less effort than (e.g.) JQuery.

I have one problem, though... the marketing folks want to be able to change the copy on the static pages, but they don't want to learn HTML. They're pushing for me to implement the static pages as a Wordpress site, with a list of pluging that they want, because that's what they're used to.

I don't think JS is the problem here...

It’s fairly trivial to setup a simple text file with all the websites copy so that when the file is updated a script can automatically fire to rebuild the static pages and deploy it.

That doesn't answer the marketing folks' concerns in GP. They don't hate HTML because they prefer markdown or whatever; they want a WYSIWYG/drag-and-drop site builder because it's what they're used to.

Vue is not an SPA framework. Vue only makes components with data binding and reactivity.

Vue Router, a plugin, adds the SPA functionality.

good point. I haven't quite gone that far, but it's on the trello board for consideration ;)

I'm tired of discussions concerning "Javascript" and "the web" where absolutely conclusions appear to be drawn. JS is a language, the web is a platform. Ofcourse overusage of JS results in annoying bloated websites, but when you want to build interactive applications that can easily be distributed to the entire world, the combination of JS + web is a virtue. The web isn't only for displaying static content, it's time to accept that.

I'm all for dynamic content, as soon as anyone can find a decent use-case for it.

Yeah, I've never understood the yearning for effectively plain text html. I remember recently a submission that had a "brutalist" styleguide.

I wonder how much of this is a reaction to the complex and volatile nature of frontend patterns, in a psychological sense.

If anybody catches the titular moment, drop the time index here, please.

around 20:45

Does this mean Svelte 3 is the Tesla of the web? No virtual DOM it's like it doesn't even use gas. XD

tl;dl around 20:45: They're comparing javascript and the tools you use for it to transportation modes. Saying things like Angular was the H2, React is the H3, vanilla javascript is riding a bike. They really are just saying don't over engineer things and use the right tools for the job.

Douglas Crockford's Javascript the Good Parts, is imo the best when it comes to getting a feel for what the right/wrong tools are. That book was a perspective changer for me. People like to get very passionate about frameworks and how Javascript should be done. JS The Good Parts made me realize it's better to play the strengths of what's available to you here and now. To accept the tooling as it is with its pros and cons - exploit the strengths and minimize the impact of the cons.

> JS The Good Parts made me realize it's better to play the strengths of what's available to you here and now.

So... use what?

Use your own experiences and your common sense to make good decisions yourself.

Of course I do, I was just wondering what you used.

I'm wanting to enhance a server-rendered template with a bit of JavaScript to fetch data from the server and update the DOM.

I like that Vue can be "dropped in" to any HTML page, like jQuery, without completely taking over the frontend development process, but it still weighs in at 30k. Also, the Vue docs are primarily oriented towards a pre-processing SPA workflow.

Are there any light-weight libraries like Vue, around 2k-5k, that enhance static HTML with declarative DOM manipulation reactive data binding?

Is there a "plain JS" approach to declarative DOM manipulation?

Correction, Vue minified and gzipped seems to be around 20k, so might still be my best bet for sprinkling declarative DOM manipulation into the static HTML.

Is there perhaps a library in the 2k-5k range, or somehow a way to use only specific parts of Vue (like a custom build)?

https://github.com/choojs/choo

I'll check it out.

I’ve been enjoying the simplicity of keeping it plain using lit-html. It lets you write declarative markup and they’re template literals.

Thanks for the suggestion :-)

I’ve used HandlebarsJS for the same thing. I can’t imagine you can get much simpler.

ES6 template strings make a reasonable templating language and are built-in to most browsers nowadays.

Keep a sense of scale. 30 KiB is small. If all the libraries you use add up to less than 50 KiB, then really, no one will notice.

Think of a "modern best-practices" site that uses a big framework and some big addons and feature libraries, and ends up with like 500 KiB of JS. Some end up with megabytes! That's crazy. I think these developers don't have a sense of scale. They probably think I promote premature-optimization, that they're good engineers who follow best practices and use best-in-class tools and techniques ... but they don't have a sense of scale to see how the results are not reasonable.

30 KiB is small. 100 KiB total is probably quite OK. 500 KiB is very fat. 2 MiB is crazy town. Sense of scale :)

Good perspective.

I can probably stick with the 20KiB Vue dependency, particularly when it doesn't require any build system or other dependencies.

lit-html lets you write declarative, reactive templates in plain JS, and is ~3.3k. Check it out here: https://lit-html.polymer-project.org

That sayHello function declaration burns my eyes.

Why?

Because it's the first time you've seen JS lambdas, the "html`foo`" syntax, and/or JS string interpolation?

This function looks perfectly 100% normal to me, but that's probably I spent a whole workweek once almost entirely in ObservableHQ documents, where you'd use md`...`, html`...`, etc. all the time.

It's not the first time I see JS lambdas, or lambdas. I'm just not sure why

    let f = (a, b) => a + b

can be considered prettier (or clearer) than

    let f = function (a, b) { return a + b }

or (given the differences in runtime behavior)

    function f (a, b) { return a + b }

It saves typing for trivial functions, sure, but it's yet another syntax for the same thing.

I prefer it for

1) Less tokens: less noise, more signal. `a + b` is the important part, let's not obscure it.

2) Lexical `this` binding.

3) Shorter and less likely to line-break.

4) No hoisting when used with let and const

5) Actually const when used with const. const module exports are faster.

I've come to like the arrow-function lambda syntax, but that's mostly because it is exactly what C# uses, and I write vastly more lambdas for LINQ and higher-order functions on the back-end than I do in JS.

The only downside is you've got to involve babel to transpile it down to the shitty old browser versions that we need to support, so you go from a simple reload to a webpack or grunt invocation that takes 30 seconds to a couple minutes, depending on how invasive the corporate anti-virus is feeling today.

Just don't compile during development. Only compile for testing on and differential serving to legacy browsers.

Yeah, I was excited about Polymer when learning about Web Components.

I'll read more about lit-element. Thanks :-)

I also like that it comes with no virtual dom, but just remembering direct references to the "holes" that need filling. It's funny that vdom has gotten so much traction albeit being inherently inefficient.

Hyperapp gives you a declarative model in a tiny framework (around 3.5kb) inspired by the Elm architecture. https://github.com/JorgeBucaran/hyperapp

Sounds cool. I'll check it out :-)

Ah dang. Requires a bundler. I am really just wanting to enhance an existing HTML template.

It seems many of the JS frameworks add a lot if, IMHO unnecessary, complexity.

Ah my mistake, I thought you could drop it in a script tag.

May not be exactly what you are looking for, but take a look at https://svelte.dev/blog/virtual-dom-is-pure-overhead if you haven't seen already.

and this https://youtu.be/AdNJ3fydeao

Yeah, I really like the idea of Svelte. I'm just coming from the perspective of wanting to sprinkle in a little JS in my development flow, and avoid pre-processors or compilers, if possible.

There is also Preact which is a 3kb alternative to React with a similar API. https://github.com/developit/preact/

Disclaimer: I'm one of the maintainers.

Thanks for the suggestion. Really great work keeping the framework so tiny! :-)

Can Preact just be "dropped in" to an existing HTML template, like jQuery?

No, but my understanding is that Stimulus (rails) does that.

Stimulous seems pretty nice, and can beused without a bundler :-)

https://stimulusjs.org/

yup, just add the script tag and you're good to go! It's frequently used along with https://github.com/developit/htm for a jsx-less template syntax. No build tools required :)

If it's smaller, faster and react-compatible, then are there any downsides? Otherwise a switch would be a no-brainer.

I just write the DOM updates into a controller layer’s setter functions, or use event listeners. I find it easier to work with than angularjs, but haven’t used angular 2+ or react so maybe I’m missing out on something.

Basic MVC goes pretty far

Check out reLift-HTML, https://github.com/mardix/relift-html, A very small (3kb) view library that allows you to create Web Component, Custom Element, and helps you make any HTML page reactive without the bloat of big frameworks.

I think that VueJS is a great framework because it's very flexible. I love being able to build entire apps without a bundler and no build step. I hate bundling during development. It's so slow.

So Javascript is the problem? Not the trackers, and ads but Javascript which is simply a programming language. May not be the best, but its not the worst either.

So the rats and lice are the problem? Not the plague?

Javascript was a poorly thought out language designed in two weeks. It is a problem... so much so that features keep getting stacked on it because by now we are stuck with it.

It is such a mess that it is now mainstream to compile some metajs langauge to js.

Is it the worst language every created? Certainly not, but is it the worst language being actively developed and used? Yes. Is it poisoning the minds of young programmers with bad practices and a fear of concurrency? yes.

The first prototype was designed in 10 days. The language itself underwent several iterations and I think it's not fair to say that it was "designed in two weeks".

Other languages (and newer versions of JS) compile to ES5 so they can be run in JS engines supported by commonly used browsers. Not because JS itself "is such a mess". This allows one to roll out new language features to developers without having to wait for browsers to pick up a new standard (or language). Pretty much every language I am aware of adds new features and changes over time. Do you call them a mess also, because they make changes?

I think your comment is highly opinionated, not well supported by facts and sources, and IMO on the edge of being insulting to a lot of people.

Fair points, but the fact it has to be compiled negates almost all the benefits of a scripting language. Not to mention that using these tools is error prone (see leftpad).

TL;DR JS has become more of a target over time than a source which might be a hint that there is something deeply wrong with it. People wouldn't reinvent the wheel if it was round to begin with.

JS has become a target rather than a source because of convention. It's the way modern frameworks and tools work, and it's part of the process that companies employ. The original intent behind tools like Typescript and the compile-to-js paradigm might have been dissatisfaction with the language, but the ubiquity of that paradigm is due entirely to the influence of Node, Facebook and Google.

Yeah, it's so much of a problem and so badly designed that the whole web runs on it every day, enriching the lives of billions of people and providing them with access to valuable software.

You know, I guess that's why I come to think more and more that I have a real issue with the attitude of some of the more deeply technical folks: You completely neglect the success of this ecosystem and what it does for all of us, because of technical details that apparently do not matter a lot to end users.

Yes, for technical people having to deal with that ecosystem, it can introduce new quirks and issues. It's your job to deal with that and create value for customers.

Do something about it instead of ranting and whining.

Being forced to use electron-based apps hardly feels like an enriching experience (Microsoft removing the legacy QT based app for one without push-to-talk, Discord, Slack etc.)...

My final comment would be success of proliferation isn't always a result of quality. I am not saying it doesn't provide value - it is just a very poor programming language which, being popular, means people who learn professionally my get stuck in a minefield of dogma instead of focusing on sound principals.

https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...

Javascript was a poorly thought out language designed in two weeks.

The problem is not JavaScript the language, the problem is abusing client side programming. I can't imagine what kind of perfect language could have prevented that. If you can, I won't believe you, sorry. The feature that matters, sandboxing, it's there yet.

Most languages are terrible in nitially. More important I think is the ability to evolve.

And JS is evolving, faster in some areas than others but it is evolving. Compared to the first time I used JS, now its very convenient language with some quirks. But the main reason actually it is rising in popularity so much is that's probably the most cross platform language today. And I am ot talking about what you compile language to, I mean what do you use to ship software to people.

Well, CO₂ is also a fine little molecule that's crucial to most life on Earth. The problem with CO₂ isn't the molecule, it's the amount of it being released, and that despite the dangers being widely known, the market is greedy and just doesn't care. It's the same with JavaScript - the language is what it is. But the ads, the trackers, the Node tooling, the ever-increasing frontend bloat, the user-hostile design stemming from it - these are the problems.

I don't see how you can put ads, trackers and node tooling in the same basket. Also the node tooling is helping to contain the frontend bloat.

Simple: ads, trackers and proliferation of node.js all ultimately contribute to increased amount of unnecessary JS I have to download when visiting a page. Node and surrounding ecosystem (Babel, Webpack, etc.) are subject to Jevons paradox[0] - by making it easier to deal with bloat, they allowed and encouraged vast increase of it.

[0] - https://en.wikipedia.org/wiki/Jevons_paradox

I don't get the sentiment about JS. Where all the hate is coming from? Maybe it's just confusion. People hate SPAs, but talking about web. IMO web and SPA are two different things. Maybe overuse of JS on web sites is problem, but A in SPA stands for "application". And applications written in JS are perfectly legit to me.

One complaint is developers defaulting to using SPAs for building traditional websites which aren't apps, recreating the functionality that modern browsers are already good at, and there's plenty of good backend frameworks that have been around for while, where content can be loaded quickly, so a full page load isn't a big deal as long as it doesn't have a bunch of JS it has to wait on.

What is there not to get? Javascript in browser simply sucks as platform.

1) No memory limits (technically, there is a limit, but it is much bigger than, say, app heap limit on Android)

2) Background tabs can use setTimeout() to indefinitely run code long after user left them

3) Websites can start background processes (Service Workers) without user oversight. Users can't prohibit that or kill them via easily available means.

4) Applications are non-optimized by default, need massive CPU resources for JIT-compilation

5) Rendering a page with five sentences requires executing tons of said unoptimized code.

6) No permission system for majority of things. All important user controls have to come with browser add-ons.

7) Applications can update themselves anytime without user consent

8) Most web apps do not work offline

9) Everything is tied to proprietary web services with overarching surveillance and dodgy EULAs...

take literally any language, and there's a laundry-list of complaints about it.

there was a whole thread here a few weeks ago hating on SQL (a battle-tested veteran of ~50 years) and giving a laundry-list of "things that are broken in SQL"

there are routine threads discussing the manifest flaws of Go, and why everyone should switch to Rust/Elixir/Nim/whatever the newest flavour is.

no language is perfect (not even LISP), every language is a bit broken in some ways.

JS is a great language for its role. It allows newbie coders to write some godawful web code that works!!!1!1!! while they're learning (without having to understand a lot of CS), and veteran coders to write some really elegant code if they want.

Learning to use JS powerfully has been a great education in coding for me. I'm still not using it as well as I could be using it, and I like that it has depths still to discover.

Every item in your list describes a problem with the way browsers are designed, with the way the web works, or with the standard practices and incentives of web development culture, and all of them would likely still exist were javascript replaced with any other language.

It's ironic that JS as a language is hated to the point of near derangement on HN while being the least relevant component of the problems people here have with the modern web.

Relevant discussion titled "Why I'm still using jQuery" (27 May 2019, 237 comments):

https://news.ycombinator.com/item?id=20021289

So what's the view on using Gatsby for building content or ecommerce sites?

Better than using other static site generators sprinkled with JS?

I've not done any research yet, so curious to know what the HN community thinks.

I urge you to use a well designed language like Elixir. And work with a well designed Framework like Phoenix. And then try to use Javascript for once. You'll see how fragile the language itself is, let alone its eco-system.

No, I'm not a JS hater, In fact I LOVE VueJS and I think you can do a lot of great things with it. For example, I built a completely offline cart system without any server backend using just VueJS. But then, between VueJS and something like LiveView, I find its infinitely easier and faster to develop on vanilla server-powered CRUD applications than SPA/JS only frontends with "serverless" backends.

With each year in web development, the complexity only seems to keep increasing to get something as simple as loading a web page fast or without refresh.

These days, I've started using LiveView and Turbolinks which basically means I have absolutely no necessity to touch Javascript at all and I can get everything done with the same language I write for my backend - Elixir. It's pretty amazing.

Much love to José and Chris.

Languages do not have to be "amazing" to be useful.

Also, being able to use the language directly in the browser is a pretty useful property.

It's really not genuine to label a language "useful" if it's the only option you've got.

Yes it is. Utility in a language doesn't only exist relative to other languages that target the same platform, a language can be useful on its own merits.

In the case of the web, the utility of javascript comes from being able to script the DOM and execute code in a browser. If there were other languages which could also do so (as was the original intent implied by the <script> tag,) those languages would also be at least as useful as javascript.

so, http is the methane(ch4) gas on the internet?

Then I guess the DOM is the radon of the internet, because most JS developers have no idea what it is or what its for and are scared to death to approach it without 3 layers of abstractions plus safety scissors.

dom - https://dom.spec.whatwg.org/

radon - https://en.wikipedia.org/wiki/Radon

Arguably, JS should be methane, and HTML should be CO₂ - the gas that's an important building block of life, and to which methane eventually breaks down (after doing its thermal damage to the planet, of course).

(Then, web developers would be cows, and web fashion/standards would be food for said cows; unlike in real life, here we transitioned from algae-based food to whatever farmers shove into livestock today, making the cows start burping large amounts of methane in the process. NPM would be an open-air landfill.)

Reply on news.ycombinator.com