Does ES6 make JavaScript frameworks obsolete? | Hacker News Reader

Does ES6 make JavaScript frameworks obsolete?

stackoverflow.blog

ES6 a.k.a. ES2015 came out six years ago, and yet the article keeps on referring to ES6 in the present or future tense. I had to double-check the article to make sure that this really was written in 2021. The references to Redux and Flow feel similarly dated, now that React hooks are widely used.

I also just don't see how any of the ES6 features named in the article negate the need for a framework like React. React et al. are built on the DOM API more than any individual language feature.

All in all this article feels very confused.

ES6 was specified years ago, but it's not available everywhere. That's why we still use bundlers/transpilers. We're getting to the point now in browsers and Node where all of ES6 works without a compile step. Mainly because IE is finally, properly dead.

The article is conflating EcmaScript with the browser APIs. Some browser APIs made jQuery unnecessary in some cases, like `querySelectorAll()`. The "next generation" browser APIs like ShadowDom are not even mentioned; they are effectively trying to do what jQuery => DOM APIs did but with React/Angular/etc => Shadow DOM, but failed at doing so spectacularly. THAT should have been the focus on an article titled "Does modern Javascript make frameworks obsolete?" and not whatever this is.

I expected at least a modicum of quality from an official StackOverflow post, but it's so wrong in so many levels that I can only but flag it.

Seems like they do not have a lot of experience actually using JS.

Am I crazy, or does this read like an author who has never actually coded in either vanilla JS or used frameworks, but just assembled a long post based on complaints they have read without vetting any of it?

Even aside from ES6 not being new, the description of what is good and bad about each side are just... not correct. JS coders don't ebb and flow back and forth to frameworks. Frameworks are not niches of coders fighting for their usage in a wider community. The only thing this author got right is that much of ES6 is syntactic sugar.

Of course, that is the exact reason that babel was needed, but as browsers adopt support of ES6, that need diminishes. Put that together with HTTP/2 and there is an argument that our bundling habits and toolchains could be simplified, but that is orthogonal to whether or not we use frameworks.

This article makes a pretty poor case. My company uses and loves Ember.js. We're not using it because classes or modules are hard without it. Ember offers great built-in solutions for routing, writing componentized reusable code, and robust testing. It has its infamous "learning curve", but we've hired numerous developers with React and Angular experience who have been able to start instantly working with it while learning Ember specific features along the way.

Frameworks are quite sensible things to use in a large variety of situations. If you're building a large enterprise application, a framework can provide a lot of stability, a large ecosystem and resources that rolling your own can't provide.

This article makes no sense. ES6 allows you to express things more succinctly, but it's not a React killer. You'd still be missing a declarative UI renderer if you were starting out framework-free, armed only with ES6.

And it's not a killer of other frameworks, either. ES6 doesn't give me the wings I need to ditch Winston for logging or Redux for managing state. Not sure how this article got to the front page, but it certainly shouldn't stay here :P

Is this a joke? ES6 is 6 years old.

I don’t understand what line of thinking leads to such a ludicrous claim. It’s not just this article, there is a push for “vanila js” and “use the platform” in the community.

I’d like to point out that frameworks exist in languages more mature and complex than ES6. So I don’t know what it is that javascript people think only they can see and everyone else doesn’t, after only 5 years or so of having a barely usable programming language.

It's insane, isn't it?

Can you imagine someone claiming it's wrong to use a framework like ASP.NET or Entity Framework instead of "vanilla dotnet"? Or that it's wrong to use Laravel instead of "vanilla PHP"? Or Spring instead of "vanilla Java"?

Maybe they can see the unnecessarily huge size of these frameworks. Or the poor fit of foreign work/code organisation.

That's a critisim of specific frameworks, not frameworks as a whole. Many frameworks are tiny (Preact, Svelte, Solid, etc). Not sure what you mean about foreign work exactly.

Well, I think the “line of thinking” against frameworks and framework-y libraries is presented fairly well in the article: bloat, performance issues, debugging difficulties, steep learning curve, niche use, deprecation, and maintainability. You may disagree with one or more of those points, but I don’t think you’ve offered a strong rebuttal.

My question is rhetorical, and I did not bother to read the article, for that I am a javascript developer myself, and too familiar with these arguments.

The only real valid point is bloat, simply because the web is the only platform that still has a code size requirement of applications from the 80s. It's not that there is no solution for it. Take for example island architecture, there is no such thing in "the platform". So if you do care about bloat and want to load only part of the app that's used, you would use a library, or framework, whatever you call it to help implement that. "write more compact code" or "avoid writing code" sounds like giving up to arbitrary restrictions to me.

Performance isssues are mostly caused by incompetece, using frameworks or otherwise. The rest of the issues can be attributed to anything, and is subjected to improvements, rather than to be seen as reasons to dismiss the whole idea of frameworks.

I'd like to point out another thing, all the tiny, low quality, "unixy" garbage on npm actually exists because of the dogmatic avoidance of frameworks.

Honestly, i feel that JS needs an official standard library. Also, wouldn't it be nice if typescript was a first class citizen (no transpiling).

there are movements in place for both. the Temporal proposal will add date libraries to the language. and Type Syntax ignoring (types are just skipped at runtime so you dont have to transpile) is in the works.

what you need to consider is what qualifies for being in the language in the first place. Having a small core lets JS be usable in all sorts of contexts, like embedded devices and "stored procedures" of auth and database systems. every thing you add is irreversible and globally piles on requirements to everywhere JS is used.

the solution you ACTUALLY need to solve the OP's question is to add to the DOM/Browser APIs, not to JavaScript. Aka, web components (which have their own problems but i dont have the energy to get into right now)

It seems to be happening little by little, for example the development of Temporal is well underway.

I'd like to see more authorization/authentication baked in at some point, data tables and manipulation would be great too.

I don't see how ES6' features remove the need for frameworks. And the "implementing fingerprinting in React is hard" point makes little sense. That's wholly independent of the view layer.

New browser APIs do remove the need for libs for DOM manipulation, date, time, and price formatting, etc.

ES6 makes many things so much nicer to write.

But beyond those primitives, there's little there to replace a framework.

Yeah, the browser fingerprinting example told a lot about the knowledge this person has on React. Doesn't make any sense as an example.

I'd also like to know how they imagine rendering complex DOM structures. It's still a nightmare to do with just Javascript. Without at least Preact or Vue, as the smallest options, it's just tedious and complex.

Check his other blog posts. He has zero idea what he’s writing about

Doing anything halfway complicated with React, such as implementing browser fingerprinting, means building a complex stack of components that you then have to constantly maintain and manage.

The alternative to building a complex stack of components in your framework is to build the thing you want in vanilla JS (exactly as you would with plain ES6) and then call it using a hook. The maintenance overhead for complicated things that don't integrate in to the framework well will be exactly the same, but you also get to use the framework for things that do integrate well.

So no, ES6 isn't going to replace anything. It will augment framework use in some edge cases with high complexity. That's exactly how things work now.

The problem with the article is that the author thinks overcoming the difficulty in building a complex application is a matter of writing better code. That is wrong. The way to build a complex application is to be more organised. That's what frameworks make easier, even if the code ends up being pretty horrible.

I was thinking that, more than a bunch of convenient abstractions, a framework also provides a convention that developers are familiar with (easier to get into the codebase). I feel like I know how NextJS projects will be structured.

I'm just a beginner developer, and I would actually prefer vanilla ES6, but I can picture wildly different ways of doing things with ES6 between each company. So then each company has their own abstractions, libraries and conventions (aka a framework, but localized). Then I imagine documentation about the structure, to get new devs up to speed.

When the girlfriend had to switch to Angular from React at her junior position, it took her a while to get comfortable with the codebase. Not sure how much that matters amongst experienced developers.

I was expecting a blog post from 2015, but no it's from a week ago. It makes no sense.

Is this just clickbait? In what way does syntactic sugar and and a few language features replace a full fledged framework that unifies teams around project structure, data handling, routing, caching strategies, any many more elements.

Apparently arrow functions makes it much easier to implement browser fingerprint compared to using React Components.. w

Yes this article should be ignored because this is wrong: “ Ember, for instance, is probably the most “frameworky” of the frameworks on this list, but it suffers from performance issues, the largest download size, the largest API footprint, and the steepest learning curve of any of the frameworks on this list.”

There are no performance issues with ember.js glimmer engine, large payload argument is also old and wrong for big apps, among other wrong claims in a single sentence.

I will not argue with anyone here below on hacker news. If you reply to my comment chances are I might not respond back. I just skimmed the article and saw this part, made me realize I shouldn’t read this article further.

This article seems to be (in some way) AI generated. It makes a confusion about Javascript frameworks and Javascript language features.

Oh my. If it was some random google search result that gave out such nonsense. But it is from stackoverflow.blog :(

Jesus Christ, who wrote this article? 3/4 of it is just plain incorrect.

js frameworks wont go away until html or the dom makes mutating lists of elements easy

Reply on news.ycombinator.com