Many beginners ask "which framework should I learn?" and "How much JS or TS do I need to learn before a framework?" - countless opinionated article...
For further actions, you may consider blocking this person and/or reporting abuse
Can you actually back this up? I know for a fact Vue scales well and it's used in large real world applications and there hasn't been too many big projects with Svelte to even state that.
Good question. In fact, I do, thanks to the work of Ryan Carniato who took the pains to make precise measurements: dev.to/this-is-learning/javascript....
That being said, not too well doesn't mean that this would be automatically prohibitive for it's use in larger projects. As so often in development, it depends.
At 80 components Vue is in the Preact, SolidJS ballpark.
Vue simply had a higher overhead per component than those two for lower component counts.
From that perspective Vue scales as well as Preact and SolidJS for high component counts.
Vue and Preact always fare better than React while it takes at least 1080 components before React requires less code than SolidJS.
Svelte's per component overhead doesn't seem to amortize (as quickly?) at higher component counts.
Does 80 components already count as big? That's probably arguable.
As far as I understand it, in the context of the article it's 80 identical components rather than total number (though not really sure if it matters).
I think the criticism of Vue was related to the hybrid approach of mixing reactive/vDOM, locking itself out of optimal runtime scenarios for either.
The argument is that reactivity scales best when it isn't tied to components.
Components are Pure Overhead
Ryan Carniato for This is Learning ・ May 10 '21 ・ 6 min read
Yeah Vue scales well on component size. If you go far enough it will be smaller than all the others. 80 "components" is loose. That might be accurate for like SFC styles but I'd say like in React the equivalent of those 80 components is more like 200 components because they tend to come smaller. I only went that far because for a single page load that is about as far as I'd want to go. Obviously apps will be larger with code splitting.
So any concern I had with Vue scaling would be on reactivity + VDOM overhead, but I haven't actually benchmarked Vue that way to an extreme so I can't speak to it.
Another concern with Vue is backwards compatibility, something react is surprisingly good with. There are many Vue 2 apps without a strategy to move forward.
React may still support class components but in the case of Etsy:
was enough to tip the scale towards migrating to Preact v10.x instead.
So even with React there is continual pressure to modernise the code base just to be able to stay on a supported version.
I remember a similar migration, but we had only three instances of changed behavior, which were fixed in a few hours. It probably depends how much you rely on internal workings of the framework/library.
Still, with Vue 2, migration to v3 basically means a rewrite of the whole state and logic.
I will disagree with this, Alex
Vue 3 supports Options API fully (which is what Vue 2 is based on). The only major things that change are how the app is instantiated and how global configs and plugins are set into the parent Vue object instance.
There's a handy @vue/compat package that detects where critical changes need to be made to make this migration process easier
Oh... wow, I've never seen such a great overview of the technical concepts of all these frontend frameworks! Thank you so much, Alex!
Same here
Are you saying that it's all you need to master to become efficient with lib or fw?
What about the fundamental JavaScript concepts eg. Call Stack and Event Loop?
Asynchronous Communication?
OOP and functional prgramming in JS?
Scope, closure?
Error handling?
I don't think that you will stop feeling confident until you started to understand these at least partially.
Usually, you start with ignorance about a topic, then you gain a sufficient superficial understanding to feel confident, then after some time you learn about the concepts you didn't know that you didn't know and your confidence is replaced by more understanding.
I can only say that this basic knowledge is a must for working with frameworks. I should add design patterns too. Sadly, none of this was mentioned in your article.
One should learn the underlying technology before using tools built with this technology. My takaway after 12 years in FE.
25 years of FE taught me that most people are using only about ½ of the underlying technology most of the time anyways – but depending on your use cases, these might be different parts.
Also, I wanted to keep the part intentionally short and encouraging, that's why I remarked on overcoming your initial confidence instead of mentioning a discouragingly long list explicit skills.
Lastly, a lot of people use their favorite patterns like a hammer, even if their task is to fix some screws. Yes, learning patterns can help, but every framework usually already comes with its own set of idiomatic patterns that are more important than learning about a factory pattern that you're never going to use with that framework.
That makes me even more sad. You're set for disaster if you don't know JavaScript being a FE dev.
Not using is not the same as not knowing about what is actually happening under the hood. We don't use frameworks because we need shortcuts.
Do you know 100% of JavaScript? You can answer every question of ydkjs-exercises.com/ correct without thinking twice? I can't do that, and I'm longer in that game than you. I'm still confident that I can solve every front-end problem even without a framework.
To start with a framework, you don't need 100%. Getting over your initial confidence means you are usually somewhere around 50-60% of the language and its concepts and the rest that is important to work with the framework, you can pick up on the go.
We don't need gatekeepers for frameworks. Our community should be inclusive, not exklusive. In due time, every front-end developer should master their tools, but I don't expect anybody from waiting to use a framework before they mastered JS.
And weren't you basically saying the same?
You're comparing apples and oranges.
Firstly, I am not talking about your knowledge and experience. I am talking about a mere fact that this article is not mentioning important JS fundamentals and encourages devs to jump on FW unprepared. It's a huge red flag for any developer.
*Facebook hires devs without React knowledge but with JS knowledge because they believe if you know JS, you will figure out React. But not the other way around. *
I only know that I know very little, but I do know JS fundamentals and this knowledge has helped me countless times with being efficient with any JS based tool.
There is no way to be proficient with a framework if you don't know the fundamentals of a language, be it JS or any other language.
You're still not getting the point. If you overcome your initial confidence, by then you will have learned, yet not mastered JS. That's how learning works: 1. You get an initial understanding and feel confident, 2. You actually learn and lose previous confidence and 3. You master it and become confident again.
By including a long checklist, I would have increased the length of this already long article and would have discouraged beginners. Do you really think that's worth it? You call yourself a mentor, don't you?
No need to include long lists - only include what really matters. Fundamentals do matter.
A beginner/junior with solid knowledge of fundamentals but without a framework knowledge is on his/her path to success.
Beginners are discouraged when they grab a framework and struggle with it all the time because they think they know it but they lack understanding of language fundamentals which are a prerequisite for using a framework.
Let me give you an example:
Hooks embrace JavaScript closures and avoid introducing React-specific APIs where JavaScript already provides a solution.
Source reactjs.org/docs/hooks-effect.html
It's a clear example where knowing JS closures helps with understanding how hooks work in React.
Notice "React-specific APIs"... All frameworks and libs have a lot of specific stuff that is not directly transferable from frameworks to framework. So imagine a beginner using hooks in React and then switching to another framework and using a similar solution that is abstracted away in a different way. Same stuff but named and approached differently. But a beginner will have no clue because of lack of understanding of JavaScript closures...
You get the idea.
Yes, I am a mentor. And I speak from experience.
And if you tell you've mentored hundreds of juniors successfully, I will not doubt it even for a second because I am 100% sure that you mentored them explaining what really matters, even if subconsciously.
The docs for react have been rewritten from scratch exactly for that reason: that they implied too much prior knowledge to be inclusive for beginners.
I'm not saying "fundamentals don't matter", I'm asserting that you should have learned most of them by the point you overcame your initial confidence.
The junior devs I have mentored learned about closures as a part of the way functions work before they lost their confidence in their initial knowledge. How do you teach functions (one of the basic data types I explicitly mentioned in the article) without explaining scope and closures?
Interesting read. Thanks.
I've been using React & React Native for some years now & I think it's a great tool. That being said, I have experienced the pain of things being re-rendered unexpectedly (usually down to using context or useEffect wrong) and have decided to try SolidJs recently.
It has a very familiar feel, I think that mostly comes from the React side of things, but I also spent years with Knockout too. I remember disliking the latter because it got a bit obscure what was causing a state change in a complex system.
Not sure why I'm sharing this, other than to say to someone new that they're pretty similar. Once you've learnt one, the skills are mostly transferrable to another & as long as you have several ideas, it becomes quicker each time to prototype with a new/different library/framework.
Go for the one that looks the most fun.
While react and Solid.js look superficially similar, under the hood, they are polar opposites.
React uses reconciliation of immutable state, effects, refs and memos opt out of its reactivity and it re-runs components to fill it's vDOM. Solid uses signals, effects, memos, variable props and JSX expressions opt into its reactivity and components are rendered once without a vDOM.
Don't be afraid of choosing a new framework. You might find new patterns that work well even in other frameworks.
I like how the one solid's compromise you decided to point out was that it "forbids destructuring". Point to voby I guess :D
That's the point we get most complaints about, I guess.
You should mentioned the understructure plugins :p that's our usual response to the complaints, heh.
This is a great article, and a good summary of some stuff I didn't know (will have to check out Mithril).
We avoid React because the build step and abstraction buy-in just isn't worth it. Instead, we use smaller modules (RequireJS-based, but migrating to ES6) with Handlebars-based templating. There's also a singular-CSS assertion. Event bindings map pretty well but the property listeners leave something to be desired.
Thank you for your feedback.
While I've included Mithril solely to show the opposite of the reactive spectrum, I'm sure it'll do its job – especially if most of your interaction is based on events anyways. I only ever played around with it, but it is actively used, so I guess it can't be too bad.
If no-compilation remains a hard requirement and you want to try something really reactive, Solid.js has you covered, too.
In any case, good luck!
Of course! Ymmv, and every project works under different constraints that lead to different choices of technology.
This is one of the most important and useful posts in 2022
I created a JavaScript framework that solved all the problems popular frameworks and libraries are unable to address,
I couldn't contribute to these popular frameworks due to the Codebase age and what I want to work on are really deep.
So I made my framework solved major problems.
Oh well I haven't published it, don't know how those part works, specifically setting up a community.
The site below is been built by a developer who loves the tool, do check out the site, observe the great performance and maybe help project cradova
amplesite.netlify.app/
Cradova is the best solution for pwa due to it exceptional speed and easy of use.
Here's the project public repo, it hasn't been updated for time, but it has been on active development on the private repository.
After my exams I will update the public repo.
github.com/FridayCandour/cradova
As I already remarked, no framework is a silver bullet. I'm pretty sure yours is no exception. There were others before you claiming to have found the ultimate solution (the last one I remember was the guy who wrote fre – not that it's bad, but it's no silver bullet either) and there will be more after you. Still, you may have chosen other great compromises that could benefit your users.
The first step to get this into everybody's hand is to finalize your repo, add sufficient documentation and learning materials and announce your framework everywhere, here, on Twitter, YouTube, whatever. The second step is listen to the community, but find a balance between accepting criticism and not changing features on a whim. The third step is a lot of patience.
Yeah that's true, cradova is fast and easy to use, that's it's whins, a few Compromise.
Hy Alex,
before mentioning any framework, we should ask for the task you need to solve. I suppose, it depends much on the kind and size of your application, if a framework plays well or not. For a large scale app with millions of users, the perfect tooling might be different than for a private homepage.
So, possibly we should first ask for the task before recommending something.
It gets even more interesting if you go another step back and ask which properties of the large-scale app or the private homepage are significant factors for the choice?
Then you find that the number of concurrent views, the complexity of interactions, the amount of changes at the same time and the performance of the clients you expect become very interesting.
For example, a shopping homepage will be much faster if it shuns MVC frameworks and instead start out as MPA with only the minimal required interactions. A conference app on the other hand wouldn't work as anything but an SPA.
But is there any real measure? How much performance do you really need?
Most people will not have so many friends that the number of concurrent views really matters. And if their hompage is boring slow, this will possibly not a result of the wrong framework but of the wrong provider.
Your initial question was: Many beginners ask "which framework should I learn?"
My first questions would be:
a) What do you want to do
b) How much time do you have to learn
I assume, there is also a big difference in the performance, how long it takes to get a "beginner" up and running. Maybe he or she can do the job in Svelte after 2 weeks, but doing the same in React will take 2 month, which is the better choice?
a) might not be a coherent answer like "I want to build my own homepage". I would expect it to be much more complex, for example "I want to build my own homepage that serves as example for my skills if I apply for a job that requires me to build much more complex, performant, scalable apps, since those pay better."
Also, if you need much longer to learn react than svelte, there's something wrong with your learning material. The way those frameworks handle their tasks are extremely different, but the tasks (receiving interactions, managing state, rendering view) are very much the same.
Awesome, thanks 👍 that’s what I always try to explain to dev folks but cannot find proper words for
Awesome in depth analysis! 👍
Thanks! 🙏
Very interesting article with a different focus compared to other articles of this topic.
Thanks for sharing.
Nice Article...good start for someone new to these frameworks to think in terms of the concepts that you have presented.
Love this article. Reading it made me feel like I’m getting a bird’s eye view of everything!
Great root-cause analysis followed by a great elaboration.
With that you lived up to the implicit promise of your introduction.
Thanks for sharing. I enjoyed it very much.
Love this article,its a great overview of the technical concepts of these modern frameworks.
Very useful thank you
Сongratulations 🥳! Your article hit the top posts for the week - dev.to/fruntend/top-10-posts-for-f...
Keep it up 👍
Thank you!
Good post
get fun and explore amazing possibilities --> Qwik
Or Astro. Or something else. Or go vanilla. The point here is not to promote a single framework, but to help understand them good enough to help distinguish marketing bullshit from verified claims.
very helpful
look at signal(action) in rx-angular please.
we can now build push-based and zoneless high performance angular application
Thanks for your comment. I meant the simplicity of simple signals, not that you can emulate it with RxJS, as is elaborated more in this post .
This is a really nice article... I enjoyed reading it
You probably mean Mitosis? An interesting project, but I haven't found the time to take a closer look. Maybe for the next article.
Great article, very enlightening.
In most business apps, none of the JS frameworks even matter. The interactions are simple and fast enough that all discussions of JS frameworks are moot. It would be much better to learn software engineering skills instead, to know when to use the right tool for the job for a specific project instead of over-engineering with cookie cutter techniques like JS frameworks (usually lower level developers who don’t question anything fall blindly for them).
Also, what you describe as “reactivity” is actually known since way before JS frameworks were created as the Observer Design Pattern (aka Listener), which is a fundamental part of the MVC (Model-View-Component) Architectural Pattern. JS frameworks didn’t invent these concepts. They’ve been part of the web (e.g. onclick) since the beginning and they’ve been around since the first GUI showed up in Smalltalk-MVC in the 80s. All what these JS frameworks (e.g. React) do is mimic MVC in JavaScript, that’s all. Components is an ancient concept too (aka Software Modules) that was always used to build desktop GUI apps.
Anyways, if you have to think in a low level way away from reality in terms of states, hooks, and effects, then your code is so over engineered and distanced from reality that you already lost half the battle in meeting business goals in a web app in a short amount of time with a lower budget.
And, if you have to worry about pointless restrictions like immutable values or static typing in TypeScript, then you’re also encumbering development by 50% at least. Most of the benefits of such techniques compared to not using, never really materialize, and only proper software engineers with good experience could easily navigate around them by focusing on what’s practical, not theoretical, thus developing much more productively. Many people who fall for such bad techniques do so because they’ve read about them in a blog article or heard of them in a lecture, but blindly accepted them without questioning anything or thinking for themselves. And, they didn’t try to compare using them to not using them and seeing if the latter resulted in better productivity. Again, proper software engineers who avoid immutability and static typing can deliver faster without any real problems assuming they design their JavaScript with proper object oriented design and design patterns.
Also, by dropping even lower to the level of math by using reducers when we’re building standard business apps that have little math except in the backend, you also end up with code that is very distanced from reality and is thus much more expensive to maintain. Math techniques must only be used for math domain problems. Otherwise, it is better to use patterns like MVC and object oriented abstractions that act like simple encapsulated real concepts without being forced to work with cumbersome low level things like states, hooks, and effects, which make code 4 times more complicated at least than necessary.
React code is garbage , but most of its brainwashed users are like frogs getting boiled gradually without realizing they are getting burned by all the extra unnecessary expensive code they’re writing (probably because they look at others around them who happen to be boiling frogs too, so they think everything is normal instead of thinking for themselves and realizing the truth). It’s sadly a BIFI culture, meaning By Idiots For Idiots. None of its users have the intelligence to question things outside the box, so they just worship the overlords of React at Facebook (a very unethical company) while getting owned by their own idiocy in very large numbers. In fact, some of them literally think that a more popular technology is a better technology and that if a technology comes from a giant like Facebook, then it has to be good (the Facebook web app obviously sucks though and everybody knows it). That’s how they choose technologies, not by thinking for themselves. It’s very sad. That’s because in fact, more often than not, more popular technologies are popular because the majority of mediocre developers could use them as opposed to the minority of excellent software engineers. So, mediocre work is produced by them that hurts deadlines, expenses, and quality for customers compared to excellent work produced without them by the minority of excellent software engineers out there.
But, that raises the value of true software engineers who could write 10% of the code or less and get the job done much more cheaply, on time, and with higher quality, without using any JS frameworks.
True software engineers are like those guys that build an entire house with just an hammer in a couple of days.
They are strong, fast, don't require fancy tools (apart from VIM), they never do mistakes and they are never wrong. Actuality they don't even need tests because they really don't create any type of bugs.
And if a true software engineer decides he can do a much better React in 10 days, with a single hand... 🦄
I'm doing frontend code for 20 years and I can tell you that you don't really know what you're talking about.
The amount of code you need to implement a complex SPA with or without a framework has no possible comparison... Not talking about maintenance and performance.
Regarding Typescript, I've done very big projects with and without it, and it's really hard to understand who thinks Typescript doesn't help in large projects.
I understand some of your frustrations, namely with React, but it looks like you're rejecting any type of innovation just because you're afraid of something and that's generally not good for your professional development.
Fortunately there are good frameworks out there, not perfect... yet... But very far away from the time we needed to update the DOM state manually, or just recreate all the elements on each update.
Thank you for your criticism. Let me address your points one by one.
Last time I checked, Jira, BitBucket, Slack, all business apps, are using JS frameworks to make their front-end development scalable. And since an increasing number of business apps are going the SaaS route into the cloud, they are going to matter even more.
Most of the interactions may look like simple events, but accessible solutions that work both on mobile and desktop are sometimes more of a challenge than a back-end engineer like yourself could even imagine.
You can do all of this with vanilla JS (I've done this before and even mentioned it as an option at the end), but it's much harder to do so in a reusable, composable way outside of a framework.
While some people needlessly jumped on the PWA-train where a MPA would have done a better job, I wouldn't say those were in the majority. Most of us have a background in full-stack. And there are certainly use cases that warrant the development of a web app with a JS framework. So I'd say this is a bit of a prejudice from you.
With JS frameworks, you almost always have a choice. Only Angular forces you to use TypeScript, everywhere else, it's an option. Immutability is only required in reconciler-based frameworks, because they need the reference comparison for their state-tree walkers.
In larger projects, the benefits of TS outweighs the overhead by far. So I have to assume you never saw a large-scale frontend project from the inside.
This is as true as it would be confusing to the beginners this post was aimed at to gain a basic understanding of the common principles of front-end frameworks.
Point taken on the over engineering in some cases (I'm looking at RxJS specifically), but isn't it strange that people still save time and effort by using frameworks and their ecosystems? Maybe there are other factors playing a major role in this case. Maybe your point of view is to one-dimensional.
You should definitely have a look at Solid.js. It avoids immutability in favor of fine-grained reactivity and static typing is supported yet optional. It's right there in my article. You might have missed it.
Though static types seems to become all the rage in proper systems development too, with Rust having an elegant and powerful type system.
You don't even need to use reducers in react, they are an option. I also see them as unnecessarily boilerplate, so no argument from me here.
Strange. If I look at efficient functional solutions, it becomes apparent that OOP abstractions are mostly unnecessary overhead, which easily make code 4 times more complicated at least than necessary. Perspective can be a powerful thing.
I've had to read though the code of react. There's certainly a lot of unused code in there, but it is not garbage, but more the reason that react hasn't been completely abysmal in terms of backwards compatibility. Yes, the react team has taken some questionable design decisions, but there are always reasons behind them – like having also to work with native and some internal legacy projects.
Granted, react is no work of art, but it's also not garbage It's a work of work. And yes, Meta is bad. So what? You can still switch to preact at any point.
Apart from the no true Scotsman fallacy here, that would work if you could hire those by the dozens. You can hire react devs much cheaper and scale up and down the whole development process using react/Vue/etc. developers instead and they're much cheaper and easier to work with, because few of them are opinionated as heck and too full of themselves than would allow to team them up at all.
I've worked in front-end with and without frameworks for over 25 years. At the end of the day, it's a business decision. Yes, most businesses will initially fall for the lie of synergy effects of reusable code, but will stay for the truth of scalable development.
As I remarked at the end, frameworks are no silver bullets – but they do have their merits. And if you understand the concepts behind them, it may help you to make better choices – even the one to forgo a framework and go vanilla instead. That's what this article is about, a point that seemed to have gone completely over your head.
That being said, it would be interesting to read how you as a "real" developer would think front-end development should work.