Does ES6 make JavaScript frameworks obsolete?
Every time JavaScript goes through a major update, we seem to repeat the same cycle. At first, developers are delighted by the new features. They move back to coding directly in JavaScript, and frameworks become less popular. Then, in the relatively long periods between releases, frameworks begin to offer new features and tempt developers back. Repeat.
With ES6—arguably the biggest change to the language yet—the same cycle could repeat again. Frameworks aren’t nearly as popular as they were when ES6 first came out, while JavaScript is going strong. However, I want to argue for a more radical prediction: As developers get more and more familiar with what ES6 can do, we will finally break this cycle. The JavaScript developers of the future won’t use frameworks. At all.
I know that’s going to be an unpopular conclusion, but hear me out. I’m not saying that JavaScript will see its use narrow—in fact, plenty of companies are hiring JavaScript developers right now. Rather, I think two of the key features of ES6 (modules and classes, specifically) will make many of the most popular frameworks obsolete. In other words, JavaScript frameworks will die in the same way, and for the same reasons, that Flash died—because there was simply no need for it anymore and the inherent security vulnerabilities made it dangerous to use.
So before you get defensive about your favorite framework, let me explain why I think this shift will occur.
The problem with JavaScript frameworks
JavaScript frameworks exist as a tool for developers to abstract away some of the more complex aspects of developing front-end applications. And while frameworks have undeniably been very useful tools, advances in JavaScript’s web component specs have made developing new front-end applications (such as single-page applications) without existing frameworks much easier. This has raised the question of whether frameworks are still even necessary.
Let’s take a look at the most popular JavaScript frameworks today and examine where they fall down. You don’t have to look far for this, because most of the frameworks in use today suffer from a number of fundamental flaws.
Most of us who work with JavaScript frameworks (and yes, I’m among that group) don’t notice those flaws, of course, because we are so used to them. It’s been a devil’s bargain: we appreciated the ease of development that the abstractions gave us, but overlooked the messy JavaScript that they produced. But the simple fact is that most of the frameworks we use are bloated libraries that manage complex processes that JavaScript was not designed for or shortcuts that make debugging code harder.
In addition to these issues, there is another, more important problem: there is actually no good definition of what constitutes a JavaScript framework in the first place. This has led to a somewhat absurd situation in which one of the most popular JavaScript “frameworks”—React—isn’t really a framework at all (no wonder it’s still popular). At best, it’s a library that developers use to build their own, highly-specialized JavaScript frameworks.
All of these issues are manifest in the most popular frameworks being used today. But there are also a number of specific issues that affect individual frameworks. So let’s take a quick look at each in turn.
AngularJS and Angular
The fact that AngularJS has to appear on this list at all is indicative of one of the issues with JavaScript frameworks—that while they will become obsolete, people won’t necessarily stop using them. Plenty of developers, in fact, will tell you that AngularJS is still “the best” way to code JavaScript, even though the framework is (a) deprecated and (b) difficult to understand for anyone who hasn’t spent years using it.
This second issue—of code that is almost impossible to understand—was actually carried over into Angular 2. And while some see this as a reason why back-end developers can earn more, in reality it can make life miserable for developers. Take, as an example, the fact that Angular 2 contains instances of case-sensitive HTML, which not only violates the principles of HTML itself, but also forces many to implement an interstitial parser just to clean up the HTML that Angular 2 produces.
React
The other big JavaScript “framework”—React—suffers from a different set of problems. In fact, in retrospect it’s possible to see the development of React as a kind of reaction (pun intended) to the obscurity of Angular. React promises users that it is easy to use and doesn’t need to be any more complicated than you make it.
That’s true, up to a point. The problem is that React is not really an integrated framework, but rather a set of modules and components that often don’t play well together. 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.
Some will argue with me here by pointing out that systems like Redux and Flux allow complex React stacks to be used even by beginners. I would counter that if you need to use a framework to work with your framework to work with JavaScript, then you are really in trouble. But React isn’t really a framework, so making a comparison isn’t quite fair.
Ember and Vue and Aurelia
Finally, a quick note about some less well-known, and less well-used, frameworks. Most developers don’t have much exposure to any of these three frameworks, for the simple reason that they are not very widely used outside of their own niche applications.
Each of these three frameworks has its own idiosyncrasies, but the main problem with them is linked directly to their niche use cases. None of these frameworks has reached the market share necessary to build a true relationship with the wider JavaScript community (though according to Stack Overflow question statistics, Vue is about as popular as jQuery currently). As a result, developers who love these frameworks are often fighting an uphill battle when it comes to arguing for their use.
It’s also worth a quick note here about why none of these frameworks has gained popularity, especially because in many ways they are the most “fully featured” of the systems on this list. 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.
Think about that for a moment, and you may come to a strange conclusion—that many developers think we need a framework to work with JavaScript, but that when a full framework is actually available, we prefer to use ad-hoc solutions like React. Given that, perhaps we should reassess whether we need frameworks at all.
The promise of ES6
This is the context, then, in which ES6 was released. ES6—also called ECMAScript2015—is the most recent version of JavaScript. It changed some of the fundamental ways we use the language. It introduced a number of new features that the community had been calling for for years.
At first glance, the claim that ES6 will make JavaScript frameworks obsolete seems pretty absurd, because the changes made in ES6 were (at least according to some authors) little more than syntactical tweaks. Seeing the additions that were made as syntactical, however, misses the point.
That’s because most of the “extra functionality” that frameworks provide could be seen in the same way—a method of providing quick shortcuts to features of JavaScript via syntactic changes. Some of these syntactic shortcuts have become so familiar to us that we have come to see them as separate features, but they are nonetheless merely ways of automating existing elements of JavaScript.
That’s not to understate the utility of syntactic innovation. In fact, the majority of the new features in ES6 are essentially syntactic shortcuts. These include:
- Default parameters
- Template literals
- Multi-line strings
- Destructuring assignment
- Enhanced object literals
- Arrow functions
But the reason why these features help make frameworks more obsolete is because they bring functionality that has so far been limited to frameworks right into the core of JavaScript itself. This subsequently reduces the need for frameworks in most situations. More functions—including promises and block-scoped constructs—standardize things we were all using frameworks to do in an ad-hoc fashion. Developers who were previously working in different frameworks can now talk to each other for the first time in years.
It’s two other new features of ES6, however, that will really spell the end of frameworks or at least pause the brutal lifecycle of JavaScript frameworks. These are the novel ways in which ES6 implements classes and functions.
Classes
Plenty of developers now use OOP as standard, and so have been implementing objects in JavaScript for years. Up until now, we’ve been using both frameworks and our own home-brewed solutions, because working with classes in ES5 was a total pain. That always struck me as strange, because it was clear from the outset that ES5 was designed to support classes—in fact, the keyword CLASS was reserved.
What this led to was arguments. Everyone turned to their favorite framework and used it to create an OOP interface. These were generally difficult to work with for anyone other than their creators, and they did not play nicely together.
Now, finally, with ES6, we have a standardized way of working with classes. ES6 classes use prototypes, not the function factory approach, where if we have a class baseModel, we can define a constructor and a getName() method.
Modules
The situation was pretty much the same when it came to modules. In fact, some developers are still surprised to learn that by default there was no native modules support in ES5. It’s just that we got so used to workarounds—implemented via AMD, RequireJS, CommonJS, and others—that we forgot that what we were doing wasn’t really a part of JavaScript.
Now, with ES6, we can all use simple commands—import and export—to work with modules. Or at least some of us can, some of the time. Because, to slightly undermine my own argument right here at the end, this is perhaps the first place in which people are going to turn to frameworks again.
That’s because the way modules have been brought to ES6 is really pretty confusing. They don’t mirror the way modules are used in Node.js, and plenty of people are going to stick to that method.
The bottom line
In short, ES6 brought a host of syntactic changes to JavaScript that greatly reduce the need for most frameworks. Coupled with the fact that most of the frameworks we are using at the moment obscure JavaScript code and add an additional dependency, we could see a tangible and permanent reduction in the use of frameworks over the next few years.
Or perhaps the cycle will simply repeat, and we’ll have only a few years of learning how to write better JavaScript before we retreat into our frameworks again.
Tags: ES6, frameworks, javascript
103 Comments
Did somebody post an old article by accident here? ES6 was released in 2015!
> This is the context, then, in which ES6 is being released. ES6—also called ECMAScript2015—is the latest implementation of JavaScript
Absolutely not! The latest ECMAScript standard is ECMAScript 2021, published this June.
I guess we would have realized by now if ES6 made frameworks obsolete…
I assume this is a date issue with the blog. And the answer is no.
It’s not just a date issue! They actually linked to a few articles dated 2020. I think this was written by someone who is oh-so-very out of touch that it’s downright laughable.
You don’t consider Vue as well known?
I’ve been coding JavaScript since 2005 and I’ve never been attracted to anything but native JavaScript. I can accomplish everything I need to do with native JavaScript. It used to be that a framework was attractive because of the way separate browsers handled JavaScript. However in the past 3 years everybody has gotten on board with HTML5, JavaScript and CSS3. I’ve had minimal compatibility issues lately and really enjoy writing native JavaScript.
Absolutely right ! I totally agree. The best JavaScript framework in 2021/2022 is no-framework at all.
You are my spirit animal, Brian Berry.
I wondered the same. We’re here from the future to say that Frameworks are still alive and well, for better or worse.
Looks like Theo was taking his time with this article… About 6 years. Next article about ES7 could be in 2027 ?
Finally! Someone said it.
I waited for JavaScript to mature before really diving in. Coming from OOP it was just too painful.
Now I do full stack with node.
I won’t say I don’t use libraries, but complete Frameworks just get in the way. The might be quick to develop, but they are always bloated and therefore never fast. And the three days you use trying to do something they were not intended to do, outweigh the time savings in the beginning. And to those saying es6 is already old, until it achieved ubiquity you couldn’t rely on using it in its purest form.
Totally agree!
Really well written nonsense ^^
The author seems to be a eloquent guy, but programming is not his best skill 😉
The only thing this blogpost shows is how wrong the author was. I’m guessing it’s from like 2014 or something.
I was about to post the same thing hahaha. Idk what half this article is talking about. I guess, at the time of writing, vue3 was barely out.. or something.
I feel this article ia a bit disconnected from the world, at least the world that i see.
There are no newer “version” of JS after ES6. They are just yearly “upgrades” or revisions of ES6.
ECMAScript 2021 means the 2021 revision of ES6
Correct Eric, to the point that many developers still often refer to any recent update or revision as ES6 as well. The article has been updated to make this clearer than it was before.
The current version ECMAScript is ES12. Of course they kept counting. https://en.wikipedia.org/wiki/ECMAScript#12th_Edition_%E2%80%93_ECMAScript_2021
I’m glad I’m not the only one massively confused by this post…
lol i thought the same on this article why comparing es6 to framework, i thought I’m missing some updates
Hi Barbapapa and thanks for your comment. Correct! ES6 was released in 2015, but as you may probably know many developers still refer to any version of Javascript released after 2015 as “ES6” because of the multiple new features the 2015 update added to the language (https://www.udacity.com/blog/2021/06/javascript-es6.html). As you see this article was published in 2021 and says the same thing pretty much. Yes there have been more versions released since then, and the article has been updated to make that more clear than it was before, but none have the same level of ‘presence’ that ES6 has in the developer community. Having said that, I will admit that my hyperbolic appreciation of ES6 has made it look like the “world ended” with the release of ES6, but the point of the article is to show how ES6 brought a number of important changes to Javascript that have greatly reduced the need for frameworks is the first place.
“ES6” is a bad name. It basically just refers to anything at all that came after “ES5”.
That’s what makes it a bad name. In fact, the name was already dropped— as you have rightfully pointed out— 6 years ago in favor of year-based versioning.
What this author means when he says “ES6” I refer to simply as “modern Javascript” and what I mean is basically all the same stuff he’s talking about.
I do all work in vanillaJS, but still use this lowTimeJS (https://codepen.io/4m6/pen/bGLvdjm), is this a framework?
Angular (presumably AngularJS?) and Angular 2? Why would you bring up a 7 year old framework (or even older for AngularJS) in this context? Angular is on version 12, 13 is about to land. At least compare apples to apples.
If you find well-structured, modern Angular hard to understand, how do you understand ES6? It sounds like such a spurious argument, as though it is not equally possible to write messy and hard-to-understand ES6.
I guess if you’re reading Angular classes written by someone with the same way of looking at it as you do (like it’s some kind of alien landscape), it might be hard to understand. Bad code written by people who don’t know or respect the framework they’re using is often pretty rough. There is nothing fundamental to Angular that requires “obscure” code. That is the choice and output of the developer who wrote it. It’s ultimately ALL javascript (or rather, typescript + javascript).
This is just silly. Enhancements to the core language after never going to obsolete any front end framework that handles routing, the virtual Dom, etc.
I’ve heard arguments that ES6 obviates the need for libraries like lodash or ramda. Even there I’d say that the value a library like ramda is tremendous. It provides a super capable and consistent “standard library” that is expressive and supports FP.
This article is terribly inaccurate and out of date. The entire premise of discussing ES6 (which has been out for several years) and even suggesting that syntactical improvements in the language will somehow make frameworks obsolete – is just plain idiotic.
This article is utter nonsense
I think that in your article you are drawing the wrong conclusions.
Even though JavaScript evolves over time it is unrelated to the usage of any JavaScript framework. Frameworks are mostly used because they provide lots of utilities such as routing, http, rendering. I do not see how improved JavaScript would replace any of those utilities.
Maybe you rather meant to compare modern JavaScript with Typescript. In my opinion there might be a chance that in the future modern JS comes very close to TS or might even replace it.
As someone who is _not_ a web developer this interesting article was a good overview of the bewildering (to me, as an outsider) array of frameworks and who uses what for what. Thanks!
I gotta say though I am a bit puzzled – I’ve been hearing about ES6 for _years_, what does it mean that it is only just now getting deployed? Not _quite_ as bad a development cycle as, say, Perl, or even C++11, but still … I thought the web was all about _rapid_ evolution? (I’m serious: what’s been going on there? Now I’m curious and have to google around for it …)
It means that this article is very, very, outdated.
ES6 has been in use for years. I and other readers have no idea why ES6 from 2015 is just now getting a blogpost.
The guy accidentally posted an article that was probably written in 2014 or something like that. Don’t let it confuse you. ES2015 has been out for years (I mean it’s in the name) and it definitely hasn’t killed any JS frameworks. If anything, they’re more prominent then even before.
The article is incorrect, ES6 has been out for years and is in wide spread use/support.
Even back when this article was time appropriate though, it didn’t really make sense.
There was never anything in ES6 that was plausibly going to render frameworks obsolete in some way.
People didn’t and still don’t use frameworks in web development because they need better ways to implement OOP or what not, or at least I’ve never had cause to consider that reason and it’s not something that factors in on a team/company level either.
Instead frameworks are much more useful for other reasons, like doing a lot of boilerplate for you in a well tested and externally supported way, and making CRUD easier, and handling interaction between the backend and front end (and it is MUCH better with frameworks than vanilla js).
I’m currently experience all the failings of vanilla JS, primarily that it’s not purpose built to help deliver dynamic html content, in excruciating detail right now myself, because a contractor we hired didn’t do the job to our requirements and for now I *can’t* use a framework, but do need the functionality of one. It’s not much fun, and very time consuming, and I wouldn’t have to do any of the unpleasant time consuming work *at all* if I was say, using react.
Do you mean that by picking a framework you avoid problems?
Frameworks are for people that isn’t programmers but wants to build something that works in the browser.
Developers doesn’t need this help, JS isn’t that hard, it’s quite easy creating websites in vanilla JS
Frameworks didn’t appear solely because the programming language had pitfalls, they also address the code reuse and “don’t reinvent the wheel” issues. If you do enough software development you’ll see the need for a collection of commonly used code, either one written by you, or a 3rd party one.
I think that the author felt nostalgic and post this
When was this article written? It’s been SIX YEARS since ES6 was released.
Looks like it’s not just this article, there are multiple articles from the same author that could be from the past.
Maybe, I’m living in the future?
This is one is the worst articles I’ve read. Clearly someone did not do their research. Even if ES6 was just released (it was released years ago), this article is still terrible.
The idea that frameworks bring syntactical sugar to the table and ES6 replaces that is severely misunderstood. Transpilers like Babel is what ES6 “maybe” is replacing, not frameworks.
Also the assumption that using multiple “frameworks” together is bad, like React/Redux, is completely incorrect.
If there is a tool that does the job well, then use it and completely ignore this ignorant post.
I totally agree with you. It’s a shame that I can’t upvote comments on this website.
Hello and thanks for your comment. Please allow me to explain a little better. I have definitely done my research (I can guarantee you this) but I will admit that I wrote this article as a fan of ES6 and not an objective professional. Of course, ES6 can’t replace frameworks and if you want my honest opinions, it never truly replaced transpilers like Babel either. The title was a “catchy” thing to attract the eye of the reader and read why ES6 still remains incredibly important 6 years after its release. Why it was a game-changer. With all due respect, you and many other commenters, focus on this hyperbole or on the date of its release (despite anything that came after was just an upgrade of ES6) and miss the point. Or maybe you’re one of these few who think that ES6 is trashy and offered nothing, so in that case I can’t change your mind no matter what I write or say to you 🙂
No, the problem is that you’re comparing apples and oranges in this article.
Frameworks like Angular, Vue and React offer so much more than ES6 has. Data binding, DOM manipulation, all kinds of functionality on top of “native” JS, and which would be illogical to add to native JS.
Native JS isn’t going to replace frameworks like that, simply because they solve different problems.
That aside, the fact that you even mention an framework as deprecated as AngularJS… That hasn’t been an industry standard in a -long, long time.
I’m sorry but this is even a worst excuse. You are being punished by the community because your title is clearly a clickbait (or call int “catchy”).
We expect that you defend your position for the title of this article and you, instead, give blurry reasons out of reality.
I’m sorry but it’s not hating ES6, that is great, but the way you, as a blogger/”journalist”/”someone_who_feels_has_something_to_say” covered the topic.
BTW, you miss the main advantage of Frameworks: it facilitates A LOT team working/team switching/landing in a new company. As you see, all the lack of the article is human, not technical.
Have a nice day!
Wow, this is so off. JavaScript features from 7 years ago as others have mentioned do not help with data binding which is what most people want out of React and Angular.
I was going to rant about your poor treatment of Vue (more 1% of the questions asked monthly on SO relate to Vue!!), but I’ll settle instead for disagreeing with your argument altogether instead.
Developers don’t use Vue or React or Angular because JavaScript lacks functionality– they use it because they feel their framework of choice makes standing up apps easier than vanilla JavaScript; frameworks are optimized for this purpose! I can go from empty page to tangible interface in literal minutes with Vue, and I won’t be abandoning that just because ES6 has classes and modules now, and I can’t image I’m alone.
It’s not that JavaScript can’t do “frameworky” things on its own, it’s about using the right tool for the job. Frameworks are an excellent tool, that will continue to evolve and innovate, and make life easier for project developers, for many years to come. Zero chance they go anywhere at all, full stop.
So true!
This is very confusing. How would these frameworks — which are all about re-rendering HTML as the underlying data changes — be replaced by ES6 classes and modules?
Ya trying to say it without sounding rude but it really seems like the author doesn’t know what they’re talking about here at all.
Specially when “modern” frameworks were built leveraging ES6 classes: Angular 2+, React, etc.
Even React now made classes “obsolete” by moving away from them into function components.
In addition to all the comments expressing confusion around ES6 being released in 2021…
…frameworks like React, Angular, and the like are not really generally solving difficulties faced with _JavaScript_– these frameworks are more geared towards adding an abstraction layer on top of the _DOM_ so you don’t have to go finding elements and updating them directly. Instead, these frameworks (generally) allow you to update a data model that is bound to the view so the view updates automatically. This doesn’t really have anything to do with the core features of vanilla JavaScript. I’m a bit confused as to the argument being made here…
Aside from the article being outdated, if the argument hinges largely on classes (and OOP by extension), I have to disagree. I’m not a fan of OOP with JavaScript to begin with, and the community is largely moving away from using the syntactical sugar that is “classes” in JS.
I’m sorry what? ES6 has been around for years.
React is a LIBRARY not a framework
Go home.
I don’t feel like this article captures _why_ someone might choose to use React or another declarative UI framework. React empowers developers to have a UI that is always in sync with their data, without having to write UI update logic. When the data changes, the UI automatically re-renders and deals with attaching and detaching event listeners. Without a tool to handle this, you need to either manage all of this imperatively or write helpers to deal with that for you. Helper functions would likely become a bespoke library that doesn’t handle the edge cases that React or modern declarative UI frameworks handle.
I’ve built vanilla JS apps that are reactive to state. It’s an interesting challenge that you can learn some fun JavaScript tricks from, but it always becomes a problem when another programmer has to take over the maintenance because it’s a bespoke solution in a language that’s very flexible and un-opinionated. Frameworks smooth over those bumps too.
I fully agree with this article. You already see lots of so called Vanilla Javascript components that are written in ES6 without dependencies. VS Code plays very nice if you only use ES6 Javascript. SPA can be created without frameworks. ES6 needed time to become mainstream thats why it looks like the Article is old, but its not. It takes time to realize Frameworks are a dead end. And if you like me who develops a website with plain ES6 you will realize that to.
I’m sorry – there’s no way frameworks are close to dying out. Not only are their popularity increasing (and have been constantly doing so) but the time it takes for a team of individuals to achieve a common goal, is much easier in frameworks than using vanilla es6.
To me, this is like saying “you don’t need WPF because you have a new version of C# and you can achieve the same just by using that” – it just isn’t comparable
Oh, What? I think this article misses how ES6 is going to make JS frameworks obsolete? It’s just a review of frameworks but it doesn’t say anything about how ES6 can make them obsolete.
The only framework on here that’s threatened by es6 is ember, which has the whole ember object thing… other than that, es6 only enhances frameworks.
Also react isn’t a framework.
I think you are missing the point about ES6. Firstly, ES5 reserved the class keyword for future use. It never intended to change the prototypal object model that JavaScript uses. Secondly, I believe you are confusing the accumulation of features in ES6 with what a framework is. The features of a framework tend to establish conventions for things. I don’t always agree with those conventions, but raw object-oriented programming is subject to interpretation in terms of how to implement common services that an application needs.
Take dependency injection containers as an example. Well, you can get by without one, certainly. But, if you want everyone to do it the same way one a project, then frameworks can provide that. Take organization of code. Left to individuals, you never know what you might get. A framework says, sure, you can program, but here’s where you need to put things.
Listen, I’m not a fan of how overboard popular frameworks seem to be, but some framework conventions save you time in the long, long run. You are free to establish your own conventions and see if others will agree with your choices.
Bottom line, when money is on the line, and not just your own personal time, businesses want reliable solutions. That puts the burden on professional programmers to learn not just language features, but frameworks, too.
One is always free to go their own way, just don’t expect to be viewed as the most employable JavaScript developer. It’s a shame, but true in many ways. You can know ES6 and Typescript by heart, but if you don’t know the frameworks / libraries / conventions that aggregate those features, you can lose out. I don’t like that conclusion, but, I have lived it.
Hey Anthony, thanks for your opinion and I certainly understand your point of view. The point I was attempting to establish is that the functions of ES6 and its subsequent versions released since 2015 means that the need for frameworks can gradually be reduced (though I agree with you not fully eliminated) when/where relying on the functions I listed. I knew it would be a controversial opinion as I indicated towards the beginning of the piece, and as I said at the end, we very well may have to retreat into relying on frameworks yet again.
I think you’re confusing frameworks with libraries like jQuery and Lodash… Those libraries are becoming redundant. Frameworks? Not at all.
Uh, show me the model binding and speed of building components in straight JavaScript. There’s nothing reality based here, and saying frameworks are deficient just because isn’t compelling.
C# 10 was release just in the past few days, there goes our need for Asp.net and EF Core because of the new ‘records’ feature. Alas, no.
Actually, since C# 10 was released this week, it’s not really comparable to the argument presented. Don’t forget that C# 6.0 was also released in the past decade, so there goes our need for there goes our need for Asp.net and EF.
…in addition to the confusion from other comments stating ES6 is being released this year… I don’t believe that React, Angular, and similar frameworks are solving problems with JavaScript itself. Rather, they are creating an abstraction layer on top of the _DOM_ so that the developer can update a datamodel bound to the UI instead of having to target elements in the DOM and update them manually. This is entirely regarding the DOM API and has little to nothing to do with vanilla JS, and there is nothing in ES6 that addresses this. As such, I’m a bit confused as to the core argument of this article.
Hey I can see this post just stepped out of a time machine. Welcome to the future. I’m sad to inform you that we still have to re-write our front-end using a new framework at least four times a year, which is then immediately obsolete. On the bright side, nearly all software developers work from home now. Speaking of which, did you happen to bring a hazmat suit with you? If not… well…
That is classic. Great humor!
This article is not worthy of being posted on Stackoverflow, is this a mistake or some joke?
Just the fact Angular is being used when obviously they are talking about AngularJS is enough
Imagine an article so out of touch it’s already outdated by 6 years the moment it gets published. They must’ve accidentally published the wrong article
The way this rant is written seems to be a person that only has done Hello World examples in frameworks and looked at v1 versions of frameworks that were clunky. Frameworks offer tons more than what the author complains about.
Guess what I do? I leverage ES6 inside of the frameworks :mindblown:
Now if the rant would be is JQuery Core or lodash needed, that would be a good rant. lol
Good one Eric! Actually, it made me laugh that you refer to my article as a “rant” as this is something my colleagues would say about me. I think some of you have taken the article’s purpose the wrong way. I won’t deny that I am a big admirer of ES6 and I will admit that in some ways I make it look like before ES6 there was nothing as John Lennon said for Elvis. I should have probably taken a more objective “look” while writing this article. However, I feel like many of you are focusing on dates, and the newer versions of ES6 and miss the point of this piece. It’s a medley to ES6 and all the drastic changes it brought. Let’s be realistic here, it doesn’t matter if it’s ES6 or ECMAScript 2021, as frameworks can never truly be replaced by it. I should have not exaggerated with the title and content as much as I did in order to “worship” #S6hoever denies the vast importance of ES6 is in serious denial I am afraid.
“However, I feel like many of you are focusing on date”. Why wouldn’t they? You picked a specific version of javascript. The ‘newer versions’ of ES6 are not called ES6. Are you *really* saying that this was written today, honestly?
I think you are using dial up connection with IE because they are pure and that is the reason of this ancient scroll.
> “Or perhaps the cycle will simply repeat, and we’ll have only a few years of learning how to write better JavaScript before we retreat into our frameworks again.”
Since when are “learning how to write better JavaScript” and “[using] frameworks” mutually exclusive? That’s like saying if you use Java with Spring or C# with ASP.NET or Entity Framework then you don’t know how to write “good” Java/C#.
This is ridiculous. The portrait of Ember here doesn’t represent the current reality. Ember is for complex projects, which is a big differentiator.
Haha, every time I hear the term arrow functions I have to laugh, poor old javascript, stuck in the lowest common denominator time-warp.
This article is weird. It has very strong wording about popularity, but no data to back it up. I am guessing this might be an opinion based on old US job data or something, but based on other metrics React certainly doesn’t have a marketshare that completely dwarves everything. Honestly, if you want to talk about marketshare, jQuery dwarves about anything this article talks about. The author seems self-obsessed with the complexity of a very very outdated version of a library/framework. The article claims that it has shown why frameworks will be obsolete, but it completely misses the point why people use these frameworks. And the features this article promotes in ES6 I have literally been using for years now, and I have never felt that the things ES6 do for me make the things the framework do for me obsolete.
People won’t stop using *any* framework because nobody will start writing things from scratch. It has nothing to do with language features and last, people writing in typescript will growth because developers are lazy and typescript saves you from documenting stuff
Vue is an obscure and little used framework? Huh?
I guess you could, in theory, make an update to JavaScript that removed the need for frameworks. But you’d need to put in all the features people use in these frameworks.
And, yes, obviously this article is old and the guy was wrong. What I wonder is what the state was of these frameworks back then. Did ES6 implement most of what the frameworks provided?
What I find that ES6 has basically replaced is any need to use jQuery. Sure, it has some easier to type versions of the things I do, but it’s easy enough to just use pure JS.
omg you are somehow writing this from 2015.
well if you can see this, in 2020 there is a new deadly virus and we already have a vaccine in 2021.
ah and no, the es6 wasn’t the end of js’ frameworks.
GL
The most important reason why developers use frontend frameworks is easy DOM manipulation. That’s not mentioned anywhere.
Either an old blog was posted accidentally or this is an out of season April fools joke.
Well… I just wasted time reading a very opinionated article about a language version that I have personally been using for at least a couple years now… in production. As someone stated in an earlier comment, I could see widespread adoption of ES6 all but completely eliminating the need for libraries like LoDash, Moment (once the new features for Date are fully available) and others. But eliminating frameworks like Angular, React, Vue? There’s not even a comparison. Those frameworks do much more than what ES6 does and in fact, many of those frameworks ride on top of ES6. This article is almost akin to saying “The new V6 engine design will render all vehicle manufacturing plants obsolete.” Couldn’t be further from the truth.
Where is the dislike button?
Agreed, no need for .js frameworks anymore.
This makes virtually no sense (in any year). Frameworks weren’t invented to patch language shortcomings. Maybe you could make that case for some sort of library of helper functions like classic jQuery, but not with modern frameworks that are all tied up with issues around UI and data modelling. It makes about as much sense as a new version of C# rendering ASP.NET obsolete.
It may be more appropriate to say “modern” javascript or “ES6+”, but the author is right about libraries at least (jquery, commonjs, lodash, axios, etc…). And some modern features do make frameworks less necessary (i.e. template literals and web components, which nobody but the author has mentioned). Those, among others, reduce the amount of code it takes to make reusable data-bound DOM components.
Example:
form.append(
…Object.keys(dto).map(
(key) =>
new CustomTextbox({
value: dto[key],
oninput() {
dto[key] = this.value;
},
})
)
);
This is almost enough code to create a whole form full of textboxes bound to a dto/model object, using a custom component, with its own scoped styles, imported from a module. It’s not perfect but it’s getting closer.
IMO the nail in the coffin will be if they add some kind of DOM object literals like JSX, and simpler data binding
It often boggles my mind when engineers ramble on and on in public about things that they don’t understand well. Do they not get that in the best case scenario, they severely hurt their reputation and in the worst case, foster bad practices by having an impact on among lesser experienced or skilled engineers?!
I personally can’t wait for ES6 to come out along with iphone 7, Windows 10, and headphones called Airpods.
In all seriousness, this is a fairly unlikely proposition in my opinion. Just look at J2EE vs. Spring in the Java world. I’m sure many thought Spring would become obsolete years ago. Also, the obvious point about databinding and web frameworks not being in the core library.
“Coupled with the fact that most of the frameworks we are using at the moment are either obsolete or unnecessarily obscure, we could see a tangible and permanent reduction in the use of frameworks over the next few years.”
I disagree on all parts.
Would be really interested to hear some reply of the author… Was is really posted accidentally like everyone assumes or is it your true opinion?
In case of the latter, would you please explain why? Because there was no real reason why Es6 should replace frameworks at all. You didn’t compare those frameworks and their features in any way (routing, data binding, Dom manipulation etc) Es6 has no out of the box features like these. Yes all of this can be written in Es6 without these frameworks but that was never to disquiss. You can walk 1000 miles as well and don’t need a car but the majority would do so.
Discuss*
Well, it has links to new articles, so it was at least written recently, and someone must have at least thought this was a good enough of an idea to write it at all, even if posting it may have been an oversight.
Honestly it’s not like I haven’t seen embarrassments like this almost daily on Medium, but it does make me cringe a bit to see something this . . . uninformed coming from such a well known organization.
OGX.JS solves all of the problems stated, as it is more working at component level where many components actually use one another, and where a tree of component and HTML templates can be written with a JSON markup. But it is hard to “compete” or even propose a new framework with a different philosophy because of the popularity of these mainstream frameworks, and gain some traction, and also because most programmers want to program and not really build products. If you want to build products, you should check out OGX.JS.
Side note about the CLASS keyword that is actually pretty slow in terms of performance.
I asked on Meta regarding this blog post. https://meta.stackoverflow.com/q/413092/2799037
There is a lot of author bashing going on here when I think a lot of people have missed the point. Angular has a huge upfront learning cost. React is quicker to learn and get going but not when you realize you need to bake in all sorts of libraries for a realistic complex application. It still takes time. This is still true for pure native javascript apps, we rely on a multitude of libraries. But do we need an opinionated *framework* with all it’s overheads today? No we do not.
We used react so we could create reactive UI based on state. VDOM is used. This can be completely replaced using native ES6 javascript features, template literals. Have you not seem “lit” https://lit.dev/docs/. How about “μhtml” https://github.com/WebReflection/uhtml? No VDOM required, totally native and reactive and lightening fast.
The point is you can build your own tech stack based on some libraries that use native browser features. We still may need to use bundlers, transpiling, polyfilling etc to support older browsers but as every day goes by, more and more people do not bother to support IE11 as an example. Hence why this article may seem old and out of place. We’ve all been supporting older browsers which are not ES6 compliant and so rely on frameworks to do a lot of the hard stuff for us. But this is less of an issue now. Modern browsers allow me to create a single web page that imports web-components etc and which renders in a browser as is and is reactive. No compiling or using a framework, just a simple html file.
So I think the author is just saying that the important functionality that frameworks gave you can now be done natively in a modern browser so if you assemble the libraries you need (e.g. lit, μhtml, redux etc etc) you can develop in a browser with no compile steps required and no magic framework stuff in between.
Thank you so much for this comment, Paul. I am truly happy that some people won’t focus on the tree (the title’s hyperbole and program’s release date) and see the “forest” behind it.
@Theodoros: but why didn’t you say so in the first place? If you said and explained how great ES6 is, the majority had agreed.
Es6 is awesome and it clearly can replace certain libraries or at least reduce the need of certain helpers (array methods and such) I guess there is no doubt about it.
But your article was not “how good ES6 is” instead you compared it with frameworks and made it look absolutely awkward.
I mean what would you say about an article stating how awful js is, that there are no classes, security issues, nearly no features… It’s slow, you can’t even select html elements – only via id and class… Javascript is just a pain in the ass. The only reason people use it is because there is no alternative.
Everyone – Including you I bet would disagree and say this is all the way wrong. Then I say “well I was talking about the very first release of js, and it is actually not about how bad it is, but how good it became”
I tought as programmers technical articals wouldn’t require to interpret what the author might had in their mind… We are not in school anymore.
“There is a lot of author bashing going on here, when I think a lot of people have missed the point.”
No, we have not. The author clearly asks “Does ES6 make JavaScript frameworks obsolete?” and answers “yes”, at least three times. This is his point, there’s no doubt about it.
And it’s just wrong, in many ways. For example, JavaScript modules are providing a standard, but it will never be possible to serve them efficiently without a bundler. The same way, JSX and other feature must be parsed ahead of time to be efficient, it makes no sense to include them in the living JavaScript. Many framework’s features like data binding, store handling, routing and so on would not be included in JavaScript anyway soon to keep it agnostic. What about server side rendering? And type checking? And that’s just a bunch of examples – half of the post is made of misleading, hyperbolic or outdated sentences.
It’s just like wondering, “Do we need numpy now that Python is more efficient? Do we need C++ now that C has an improved standard?”. Of course, we need them.
Thanks god there’s a lot of author bashing going on. This post should be removed.
It’s not only wrong – it’s dangerous. It’s suggesting to leave frameworks and program in plain JavaScript, which is terrible advice. A beginner may see this post and think that’s the right way to code.
@Paul French: are you a freelancer? This article only makes sense to a guy living in a basement.
Frameworks exist because there are actual TEAMS out there, and COMPANIES, making actual money and not theorical work.
The author and his article are self-conceited, the guy basically thinks he has invented hot water and wants everyone to know.
The comments ridiculing the article are well-deserved. We code for a living. I’m not sure he does.
Can we talk about AST for class components without babel for reading html? https://codesandbox.io/s/admiring-haibt-hnmkp?file=/package.json
I don’t see that a “framework” has much to do with some version of JavaScript (or an alternative such as TypeScript) other than one must use whatever scripting language(s) a framework supports. The power of frameworks is mostly with their directives and such that extend HTML in some very useful ways. Am I missing something? So frameworks will not become obsolete until HTML is extended to be able to natively accomplish what frameworks do with their extensions to HTML.
Of course not, es6 empowers library/frameworks, does not kill them.
Obligatory “Betteridge’s Law of Headlines” (google it)
You lost me when you brought up classes. No one should be using classes in 2021. Functional paradigm is way better and framewoks like React have accepted and rolled with it which has made them 10x better.