I built the same app 10 times // Which JS Framework is best?
VloĆŸit
- Äas pĆidĂĄn 15. 05. 2024
- I built a simple app with 10 different JavaScript frameworks... Learn the pros and cons of each JS framework before building your next app github.com/fireship-io/10-jav...
#javascript #webdev #top10
đ Resources
Full Courses fireship.io/courses/
Performance Benchmarks github.com/krausest/js-framew...
Source code github.com/fireship-io/10-jav...
đ Chapters
00:00 JavaScript Frameworks
00:53 1. Vanilla
04:21 2. React
07:48 3. Angular
10:15 4. Vue
12:18 5. Svelte
14:16 6. Lit
16:11 7. Stencil
17:18 8. Solid
18:35 9. Alpine
20:17 10. Mithril
đ€ Install the quiz app
iOS itunes.apple.com/us/app/fires...
Android play.google.com/store/apps/de...
đ„ Watch more with Fireship PRO
Upgrade to Fireship PRO at fireship.io/pro
Use code lORhwXd2 for 25% off your first payment.
đš My Editor Settings
- Atom One Dark
- vscode-icons
- Fira Code Font - VÄda a technologie
Thank you for making this video, I always felt overwhelmed by all of these frameworks and you helped me come to realization that all of them suck, so I am going to create my own Javascript framework tonight.
It might seem stupid, but it's pretty much the only sane thing to do
hahahahaha
I'm in the same boat, actually. The DOM has come a long way in the last 10 years.
Example of a few things we have now: querySelector, insertAdjacentHTML, data-xxxx, css variables
I think it's possible to have a small, lightweight "framework" where all the hoopla is just handled in the DOM and the documentation is MDN because it's just DOM.
I could be wrong.
"I need javascript"
It's already too late, man. At this rate, you're not gonna make it.
gonna file tons on issue for this
"You'll end up building your own shitty JS framework, and the last thing the world needs is another JS framework." -This is literally GOLD and I can't stop laughing.
I'm not entirely sure this is true. In 99% of cases yes, but it's the developers who cause the problems.
I've worked on a very complex app written in vanilla JS, and all we had was a "helpers" file that was ~2000 lines of code, which made common js problems (like creating a node with classes easier).
Everyone was taught to use containment modules that resolved promises, and you could chain these promises to do some really cool stuff without worrying about the timing of loading assets, database latency, user interaction ect...
The app had a heavy use of WebGL and Wasm, and the initial developers found most frameworks got in the way of dealing with these technologies, so I'd still argue vanilla JS has it's place. As long as you can create proper subsystems that don't explode into your own bloated mess of a framework.
This just motivates me further towards making another shitty JS framework
on point
Well, if you build you own framework, but don't share it .. it's called "tooling" and is what i do :)
@@herrbasan xD there is no such things. If you create a concept or structure or system whatever you call it, its a framework. keep it to yourself or share with other has nothing to do with it
The problem with JS frameworks is that most of them are plenty good enough to fill most needs, and it becomes really hard to decide which one to use until you reach and edge case situation much later down the line.
Then fourth dimensional traveling WEB3 microinteractable clusterfuck becomes a trendy idea amongst designers and then you have to create your own framework.
That's why you pick the most popular one that will most likely be maintained the longest so it's easier to find documentation on it and get support.
They all do the same thing.
C'est la vie.
Agreed
Have you run into any particular edge cases with React?
For me, a back-end developer with c#. this video is really overwhelming. Hats up for JavaScript folks for dealing with all that mess.
.NET?
@@afsstuff472 yeah
@@afsstuff472 Definitely, it's not. do your search and you will figure out that Microsoft is updating it yearly and it has become widely used at top notch companies as it became cross platform and doesn't run on windows only anymore.
I must study about it. I entered Software Engineering 6 months ago only. I don't have much knowledge.
@@afsstuff472
It's ok dude. Keep going, wish you the best of luck.
Interesting fact: 3 new JS frameworks were released while you watched this video
Interesting fact: this joke is old and overused.
I made a full fledged web app using phaser đ
đ
I read this comment while I was waiting for the ads to end. I hadnât yet watched the video, and youâre saying 3 JS frameworks were released? In literally no time flat!? Because that sounds accurate.
@@Angerfist1996 username checks out
Edit: oh I thought it was "AngerFirst"...like you're an angry reactionary. oh well. Still fits.
This was the best video on JS frameworks I've ever seen.
@@Drpanda533 react is good but I hate Facebook, so i don't use it
@@Drpanda533 vue has shortcomings and its community is not able to support it as well as react ? does it feel like this using vue ?
@@NotTheLastOne you're wrong. And yes I do.
Agreeee
Absolutely agree! Thanks so much for taking the time Fireship! Actually seeing the same app in action all these frameworks is an absolutely superb way to demonstrate strengths and weaknesses
This video will be extremely inimidating for beginners, so I hope to share my 2 cents.
1) Start by learning Vanilla JS. It will suck. It will be painful... but you will learn a ton about actually reading and understanding JS code, and will have a much easier time learning any framework that uses it.
2) DON'T try to learn all these frameworks. Pick one, and go with it.
Currently, React, Vue and Angular are by far the most popular. Pick ONE of those.
3) Become good at it. Stay updated on it. And commit to it to the death during your education phase.
4) Create a personal portfolio that uses your framework and provides anywhere from 5 - 10 demo projects. Try to incorporate some back end functionality on at least half of those.
5) Start applying to jobs hat use your framework. These are generally mentioned in the description. If the job description asks you to know other frameworks as well, apply to them anyway, and mention them on your resume because job filters will filter you out if you don't.
6) If you're selected, you will be asked for an interview. Make Sure to ask what frameworks would be on it.
If they ask you to know other frameworks for the interview, crash course study it then.
If not, ignore it until you get the job.
Only study the framework IF you ever find yourself needing it. Otherwise, you will spend your entire life studying frameworks, getting lost in the different methodologies and never becoming an expert at any.
I am at point 2 right now and want to step into web 3 development eventually. Would any of those frameworks suffice or is one better than another. I see more developers using react online and they've begun using next.js as well.. There's always new libraries popping up and its overwhelming.
â@@mona-xf5mr React, Angular and Vue have been around the longest and aren't going away any time soon by the looks of it.
Jumping on new ones as they pop up can be exciting, but it's not feasible for bigger companies. Changing a library means the entire staff has to have time off actually writing code, to learn new languages, unify their code and make it work across the entire app. Like Leon said, pick one of the three and go with it. Choose the one you feel is the easiest to work with. You can always change down the road when you master one, as it will be way easier hopping over to another at that point.
I'd also focus on one solid project, like a bug tracker vs making 5-10 smaller demos.
I started learning vanilla JS, building smaller apps and such. Leveled up React later and used extensivly, including NextJS. Did this for a few years, then applied for a job that used Angular. Never touched Angular before in my life but with all my previous background, it wasn't too hard. Had a solid understanding of JS and components, some new things to learn how Angular does its thing, but passed the interview and got hired. So now I'm an Angular developer.
So point is, if you have solid understanding of the basics, you can switch between these frameworks quite easily.
@@JamieRso after learning html css and js, go straight for react?
yea exactly. Because if you become really good in one framework, then you will know it's inner workings and will understand decisions why framework do things it does. And next time if you need other framework, it will be easier to pick up, because you already went in depth in one framework and understand why it's made it is.
And after all, HR only sees what you can build, and not that much what tech you used (ofc they look at that, but if they see that you managed to do something impressive with some framework, then they have no doubt you will be able to do same in that other framework as well.
Like, if you build spaceship, they will be impressed, even if they ask for React job, and you did it in Svelte. It's still hard work, and requires a lot of understanding and headache to work with framework, to understand everything to build it.
They will hire you, because you are talented, and you will be able to make same spaceship in their framework they use.
After watching this video I have decided to create my own JS Framework where you will only be allowed to use 1 giant JS file. Once you pick my new framework, you will be too busy trying to figure out which line does what and will have 0 time to research other JS libraries. 100% developer retention. STONKS đ
is your framework ready?
@@hankersoree yes but the world is not ready for my framework yet đđ
*slow clap*
My mind is blown on how someone actually decided to compare these tools in the shortest amount of time while showing all the important things along the way. Extremely well done and many thanks! đ
Even shorter with playback x1.5 :)
@@Pthphap I put it on 2x and slow it down to .5x when he's talking.
@@Pthphap cant watch in x1.5 :(
This video has convinced me to never become a frontend developper.
on the other hand - since no one knows how the framework you are using works and what job you are actually doing - it is easy to be a frontend developer as no one controls you and you can put any estimate you want :) that's not a joke. One PM friend of mine always complains about fronted devs - they take always a lot of time and he cannot control them :)
@@kostiatretyak A major problem of the tech industry in general....
why? you need to only know 1 and you are good to go for most companies. its often react or angular or vue and they will often look if you know any of these, not all or the one they need even at times.
What did u decide! Backend""-" ?
Shame on you! We are into that
Thanks for introducing me to Svelte. I sat down and played with it for fun, remaking an app I already made with React. I basically got as far as I did with days of React work in a few hours in Svelte without even having any experience with it at all.
Hello world?
@@tranceyy A little more involved than that đ
@@broomybroomybroomy it might be because you have already built that path in your head. Remaking seems like it's always faster, than building from scratch...
@@tranceyy That would mean Hello Worlds take days in React
@@oscarpetersson5324 But the penalties of not knowing the new framework should largely overcome that
On Vanilla JS never ever set the innerHTML of an element based on user input. This could cause xss vulnerabilities. Instead use textContent or innerText.
I was just going to submit the same comment
Canât they just edit the DOM with the dev tools anyway?
@@daniel_tenner yeah but when they do that it only changes for that instance of their browser, but if you edit the innerHTML someone could inject malicious javascript code that is persistent throghout the site and it affects other people's browsers
@@cvcvka588 Umm, no, I don't think so. Editing the innerHTML in your browser won't change the HTML rendering on the server. Unless you've specifically written code that takes the DOM in a specific browser and saves it on the server to be sent to other people. It won't "persist throughout the site" unless you write code to do that. Every web page should always be designed with the awareness that a user can change any part of the html AND the javascript at any time and the application should still be secure, which is why single page applications can't just do all the validation/etc themselves and the server still needs to handle all that stuff. Anything in the browser can always be changed by the user.
To the OP point, nothing stopping me from opening my dev tools, finding an element with JS and setting the innerHTML to whatever I want. If the site is insecure because of that that's a poorly designed site.
So yeah, OP is factually wrong. Setting innerHTML based on user input poses no security or XSS vulnerability.
my favorite is svelte since it just feels very well optimized for ease of development and I like that its very forward-thinking. I think we will see much more work done in the build step going forward.
Really hope it goes viral ! Not just for hobby projects but in serious stuff too
Just need more people to start using it so there's more material online / better docs / more bug fixes.
my heart says svelte but my wallet says react :(
@@andrewcathcart I think the docs are great and the tutorial is even better though it never used it haha
@@lored6811 I feel that. I never really got into react but I'm tempted to build stuff with it just for the resume and potential job. I feel it's most likely id go for Vue though since the syntax is a little nicer in my opinion
I started using Svelte the other night and was blown away with how lightweight and easy it was. I've always loved Vue and Svelte feels like an even more lightweight version of Vue.
i think it suit backend engineer also right?
@@davidchandra8722 No it's for frontend only
@@sumitpurohit8849 what i mean is, its easier to be used by backend engineer since it focus more on basic html and the svelte itself. No need to learn new workflow/beviour like React for example
introduced in Vue 3.2 looks kinda similar to svelte
Depends really. Svelte is ultimately a compiler with associated syntax which is different from both Vue and React. I like that fact because we have enough virtual DOM frameworks out there and for less complex projects having a virtual DOM with an associated engine is so overkill in complexity itâs not even funny. Personally I go React where I actually need actually need complex front ends or a really broad ecosystem like electron or react native. Everything else I go to svelte.
TLDR for that reason I think if youâre from the backend world you might be best off starting with svelte because thereâs a lot less complexity to manage. But something like react is good to know eventually because as fragmented as the JS world is itâs about as close to a lingua Franca weâve had since jQuery
This is an amazing simple way to give an overview of all these libraries/frameworks out there
You save a lot of my time for trying and figuring it out all those JS frameworks. I think I will love react and svelte, also I don't really into web component after watching this video. Thanks. Great content as always!
It would be nice if you apply this idea on mobile frameworks as well, like trying making a todo app in react native, flutter, ionic, native, etc.
Flutter all the way..
KMM soon
Actually i like react native because java is big scary idiotic slowpoke shit
@@Gameplayer55055 3 billion devices says otherwise
This comment needs more likes
Dude, I've come to love this channel on how it just gives you every tool you might need, and THEN teaches you how to pick one based on pros and cons
A very concise and extensive guide for JS!
Excellent info I was looking for so many months because of lack of clarity what exactly JS does and especially WHY in that way. This video explains it all. Thanks.
I like Svelte and understand why it would be considered the most loved framework based off of this overview. It looks like the best in regards to user friendly design for Javascript developers in general. Their compiler style design makes it so they can continuously improve performance under the hood which is pretty sweet.
I'd recommend avoiding Svelte at all costs personally. It's very enticing because it easily has the best syntax and format for defining components, but after using it for a while in a real app I was so frustrated I nearly gave up on frontend frameworks altogether. It has two major problems. First, while the syntax is the simplest to grasp, all the stuff it's doing under the hood with the compiler makes it very finicky, easy to break, difficult to debug, extremely complex, etc. Everything I did created an often nondescript error - not in my code but in engine code - and I could never get my IDE to reliably stop at a breakpoint and step through the code. I ended up spending half my time just fighting with the platform to get it to compile. Second, and even more serious, they have a fundamental design decision that makes it take longer to develop in than normal js code. The components themselves are just invisible wrappers removed at compile time (so you can't target them in CSS) and they purposely make it very difficult to style anything inside the component from outside it. They want you to write a property and expose it for anything you want to change inside the component - which just isn't realistic to work with. Want to position your component in the UI? Wrap it in a div and target the div and hope the children don't require any special positioning styles. Want to target the children inside your component's slot with a few styles? Wrap it in a div and target the children of the div. Worst of all, want to create a component that's a button with a little extra functionality but still want to be able to style it? Have fun rewriting every single style property a button has one by one in a long list - and even then you can't apply a class to style them. They're just properties on the component.
@@dillydadally wow, i now understand why most people search something they can crush with their hands instead to break apart the machine to know why the automatic proccess did not do it good.
I've used Svelte for 2.5 years now with the Routify library for routing. I found both Svelte and Routify very easy to get into and use. In that time, I've only encountered one bug with Svelte and it turned out that they had already found and fixed the issue and I just needed to update to the latest version.
I haven't experienced the issues with styles that the guy above mentioned, because I tend not to have inline styles in the component. Instead,
1) I used css from a template I found or bought online - so basically I already had all styles I needed in a global css file and just needed to use the right elements and classes in the html, exactly the same way you would if you were building a webpage with regular HTML/javascript. I did this on my first 3-4 projects.
2) Since then I've started using Tailwindcss which gives you loads of helper classes to style anything the way you want (and is also customizable if you need more), and follows the same compiler mindset that Svelte does, where your css file is compiled using only css classes from Tailwind that you're actually using in your project, rather than having a giant css file of everything from a template like I was using before. Been using that for 9 months now and I haven't looked back.
There is also the new SvelteKit, which is an official library that has routing etc. I haven't used it yet so can't comment, and haven't really had a reason to switch since I'm happy with what's offered by Routify.
The downside is as per the video, Svelte has a smaller community, so sometimes when looking for a library to do something you want, there isn't one available for Svelte. However, since your code is compiled to vanilla JS anyway, you can simply find a library for vanilla JS that doesn't have dependencies on say JQuery, then without much effort just make your own component that uses that library to have the html elements/inputs and javascript to do the init/destroy/etc using that library, as well as the props that you want for configuration and binding, then you use that component wherever you want it in your application.
Also, I guess this applies to all the frameworks, but once you've made a component, you can just copy and paste the file into another project and use it. So the more I use the framework the quicker it is to get new projects going.
@@reikooters Honestly I need to follow up on my original comment a little. I've used Svelte daily at work since I made that comment. I realized a couple things.
First, I learned Svelte and Sveltekit together and didn't really separate the two in my mind. Now that I have, I realized most of the issues I've had related to debugging, engine complexity, and finicky behavior is mostly Svelte-kit and not Svelte. A lot of it has to do with the poorly written load function and strange behavior around the soup of static, SSR, and SPA rendering. Svelte-kit at this point is still not even version 1.0, so some rough edges are expected, and they just announced a big rewrite before 1.0 that is going to address some of the issues I had, (such as the aforementioned load function). Still, the official browser tools are abandoned and don't work and I can't get debugging to work properly in my IntelliJ IDE. There's a debugger keyword that lets you pause execution, but it's not ideal. Again, these issues might change as Svelte-Kit matures.
Second, I stand by my original claim that the component structure of Svelte is monumentally stupid when it comes to targeting and styling components in the same way you would a normal element, as well as having to expose properties of underlying elements one by one rather than just extending one of the elements. Judging by the complaints and thumbs down on comments by the devs about it and the massive amounts of issues opened about it, I'm not the only one. There's a proposal that is being considered that might make this better.
Having said that, if you just use Svelte and not Svelte-Kit (or wait for it to further develop), and you find ways to work around the component styling issues (i.e. use Tailwind and never target the components or add classes to them), then Svelte is very good and probably the best thing out there.
â@@dillydadally I spent over a year working with Svelte and agree with the first issue but not the remaining issues. The first problem with learning Svelte is that you have to learn the good and bad ways of doing things. For example, don't create components having state that varies by page, instead embed a new component per page with page-specific state. I found state management pretty easy for the post part, but every once in a while the magic under the hood gave me a huge headache trying to figure out why things were misbehaving. Sometimes I wasn't sure of the right way to arrange state and ended up duct-taping a solution that passed the tests despite my not understanding why. On the issue of styles, it took me a while to learn that the sharing named CSS classes across pages was not suitable for Svelte or any component framework. Rather, in component frameworks, style should be local to the component. In fact, the way you establish consistent style is by defining components and using those components consistently. What style would you like buttons? Figure it out and make a button component, rather than define it in CSS for reuse across different button renderings. This is a best practice across all component frameworks, not just Svelte. The popular tailwind CSS library takes advantage of this way of developing components and can only be used this way. I used Bootstrap for that project but swore I'd use tailwind for subsequent component frameworks to make my life easier.
Great content as always. You have an ability to break topics down to the essentials in a way few other channels featuring JS/TS content do. The best part there obviously being the information density you manage to convey.
This video is freaking incredible! Anytime someone asks "what framework should I use", I can just point them to this. Thank you for taking the time to learn and explain so many frameworks, It makes it really easy to make the decision and is just really interesting to see too. One thing to note though, is that if you're looking for a software engineering job rather than just building a hobby project, react might be the way to go because many companies use it and will look for candidates with react experience.
Myself spent a month creating a TODO list app using Angular Material, and I gotta say yes... The learning curve is kinda big but once I got used to it I can say it has an awesome and really organized way to do stuff!
I love the ammount of control + z that had to be done for this video!
why it can't be 2 screen mirroring and , he might be copying everything from the other one.
Svelte is amongst my favourite, mainly because of how native it feels when developing, and also very performant.
@given I use vitejs for building svelte and never have problems with building
@given sveltekit
Happily a Vue developer, but spending some free time with Svelte in hopes that it catches on! Thanks for the great overview!
Me too now :(
How do you use libs for the ui like material ui?
Now I think Vue us better than Svelte
No offence but, your statement is the epitome of why frameworks suck! Stagnation because something "new and shiny" comes along that DOES the same bloody thing lol!
@@encoder6717 I donât believe in the scarcity mindset. If svelte is good it should grow, but just because it grows doesnât mean other frameworks die. All the good stuff should catch on IMO. Established frameworks arenât going anywhere unless they stop being useful for solving problems.
Finally! I needed this so much. This comparison helps a lot to relate to those js frameworks.
Thank you for this video! As a newbie to webdev, this content helped me decide which framework to start with.
I just admire how talented you are. What a great and fun video to watch! I'm personally a React guy but I've never enjoyed learning about other framework that much, thank you!
The audacity with which this guy says that this video might be outdated is the truth of JavaScript world đ. Love your videos. Don't think we would've been even 5% of the developer we are today without content creators like you. Hats off đ
đŻđŻđŻ
Absolutely wonderful. Thank you for putting together this comparison.
What a STUNNINGLY good video! When you consider everything that could have been said about 10 different Javascript frameworks, it is borderline miraculous that you could make this video so short and helpful. VERY well done!
As a backend dev with litte js framework experience, the concept of alpine looks really nice
Yup
Iâm with you
Why would having lightweight JS in HTML be interesting / relevant for a backend dev?
Multiple front end components in one place?
@@senmingwu It's because we're often already very used to dealing with raw HTML, so just "adding on" a few things isn't so foreign as switching how we think about how the page is shown/delivered---i.e. messing with components/client side routes/virtual DOM/etc.
@@ruhnet Ohh, thank you!
This has been fantastic for me. As an OPS person generally, this was a great overview to catch me up to work with our front end team. Thank you!
This video is pure fire. Such a useful comparison and presented in a very compact efficient video.
Really cool video, thank you, at last I can get first look at all the frameworks I had no chance to use
Awesome video but for anyone wondering about Vue...he's using the older syntax for components. In Vue 3, you have a "hooks-like" API called the composition API which people more familiar with React may enjoy more. It's also very inspired by Svelte.
You also do not need to write directives like v-on:submit. You can simply write @submit. And, you do not need to bind with v-bind:key="todo", you can simply do :key="todo" and omit the v-bind entirely. Just some little nice bits I thought I'd make people aware of.
Different design philosophy, these simplifications may be a mental burden for novices
Noticed that as well, vue 3 is better but its a bit fragmented and confusing with the multiple APIs
as someone who finds dealing frontend an absolute chore angular gets my vote, because at the end of the day all i have to deal with is angular, which is at least consistent
Maybe you find frontend a chore because you're using Angular đ
Coming from React, I find Angular to be such a chore, especially when you wrap Ionic on top of it đ
I completely agree. I used to work with Java, but decided to learn angular simply out of interest. Coming from the Backend, it's really amazing. TypeScript is the best thing to happen to JS in my opinion, and I really like the strict and logical way Angular apps are structured. Also, the fact that it comes with so many things like routing is nice, because I can just use what was intended and therefore works instead of having to make decisions at every point about what third party library to use. Yes, it's less freedom than with other frameworks, but more freedom of choice always comes with more freedom to fuck up as well, so that's something I can live with.
Awesome video. Lot of work put in for sure. Thanks!
every video from fireship is top notch. Something in the narration, presentation, make every topic captivating and useful.
I'm an old school developer and after years of polishing my own set of javascript tools, I find very difficult to adopt something game changing like React, but this Alpine looks great, easy to adopt. Thank you.
I personally love vue, but excited to hear your opinion!
you havent even watched it..
@@ccost yeah thats why i say "excited to hear your opinion" and not "i agree with you" :)
@@ccost đđ true
Thank you so much for this. Now off to finishing with the development of my programming language.
Some work you put in here my Dude! Thank you!
That was AWESOME! On a side note - are you planning a merch line for your channel? Would gladly buy a T-shirt to support you :) Thank you so much for everything you do for the community!
That "so this video will probably be outdated by the time you finish watching" actually made me lol
Alpine looks so neat!! Thank you for making this video, as a beginner it helped me a lot!! I love it!
Just one clarification, in the Vanilla Js code, you should not call "addTodos" for every item of todoData. Because in that case, whenever you refresh it, the localstorage will get populated with twice of the current data. Instead just call a function to display the data every time we refresh.
Something like, this
function displayTodo(todo) {
const li = document.createElement('li');
li.innerHTML = todo;
todoList.appendChild(li);
}
Rest everything is Awesome!!! đŻđŻđŻ
That little "Use protection" easter egg was freaking priceless. We definitely don't need any more unwanted frameworks. Wrap it up boys and girls.
I am really excited to learn Svelte, it will be my next thing to learn.
Love the video! Great comparison!
I only have one different thing to say about the Vanilla approach. You could use a element and get the from there. Is still a shitty way but easier (I think) to understand. Still, I think I get why you took that approach
Keep up the good work!
I've used angular professionally since angularjs to develop and maintain multiple apps at multiple companies. Its opinionated structure is a lifesaver. It's easily my favorite framework.
Lit works alongside other frameworks, which means it can integrate into an existing app and access a data store / cache. It's also great as a standalone framework. However, Stencil combines the compile and bundle steps together, which makes it only suitable for stand-alone elements. For a dedicated web app, there's no reason to consider Stencil over Lit. Custom elements also work great on their own for things that don't need data binding, like svg icons, and allows re-use between different applications regardless of framework.
100% agreement with this. Since their rebranding earlier this year, Lit has shown even more how capable it is of handling more complex applications on its own. Iâd encourage every UI/UX developer to try it out.
How is Stencil and Lit different from React when it comes to creating custom elements? Why not just do it with react?
@@emonymph6911 It comes down to native support for me. Web Components, Shadow DOM APIs and are meant to be a native way for your browser to handle your own fit-for purpose functionality, and native is generally harder to break long-term (even if it's not initially easier to build). I only have Lit experience, and the way the tagged template literals work is very intuitive.
First 5 minutes about VanillaJS are a MUST; I finally got the perfect answer when somebody says that modern front-end web development is easy and uselessly sophisticated. Thank you Jeff.
React guy anyway. I love it.
Regarding the Vanilla JS, you can call the function to submit the form within the HTML tag, so you can see easily the functionality ( which you said cant be done ).
Instead of form.submit, etc. You create a function that will be called in the html tag, so the code goes like this:
function onSubmit(event) {
event.preventDefault();
addTodo(input.value);
input.value = '';
}
Then in the form tag you simply put
So, that means you can see clearly by looking at the html that form is doing something when submitted also, you dont have to querySelect the form anymore since you dont use it in the script, that saves you a few extra lines of code.
When I was watching the video and heard "There is no way to see if this form has an event listener attached to it...", your comment was my immediate reaction.
Edit: Just so you guys know, I left a comment explaining what a lot of people seem to agree about his JavaScript presentation, not being fair while I explained my choice using my helper libraries with RxJS in the most maintainable way possible, without creating my own framework. Guess what, he deleted the comment! So I guess this channel is misrepresenting JavaScript or being a sellout for some frameworks. Was going to subscribe, but if he deletes people's opinion, then I'm just gonna select to not recommend this channel for me.
Doing it this way means you're adding your functions to the global scope which is not a good idea
Lol I told him to use a web component but this blows my answer out of the water nice dude
How about using onclick to call a function?
@@mosesnandi inawezekana but iko considered a bad practice
I admire your wit and editing skills, I will hire you specifically for that. đđ
In vue 3, the code would have been more or less identical with svelte (except for the html). I guess they're doing something right since less code usually means less bugs đ
Composition API
This is exactly what I was thinking, I just finished converting all my components over to script setup syntax and it's so easy to prototype new components and work on old ones. I have to wonder though...did Evan You take inspiration from Svelte or was it a happy coincidence? lol
@@Aedaeum He did. He always makes his inspirations clear. When Vue 3 Composition API was announced, the RFC included a comparison to Svelte. *After* that he came up with and it was clearly an answer to Svelte
true 0 code = no bugs
I still believe that for a beginner, it is more beneficial to be able to build an app completely from scratch in vanilla JS, that way when it comes to the JS frameworks, it'll be much easier to wrap your head around what the framework does and how to use it effectively. Just my 2 cents...
As a complete noob: yes.
Agree
Agreed. A lot of concepts in other frameworks would become clear if you start from vanilla JS.
No, the state driven & declerative approach of e.g. react is a completely different way of thinking & probably superior
@@johannes.schaffer True that! React is really different than vanilla JS but if you had some experience with functional programming then it comes easier,
It's so hard to choose a framework when you know so little about them. This video helps by laying the groundwork for further research. I'm a person who has just started to build my first single page web application and so I started out with no framework, thinking my application would be simple enough to do without one. But as time went on I realized I had underestimated the amount of code involved. Now I'm having to modularize the code because it's too big to live in one file. I looked at React but decided it would take too much work to port at this point, so I ended up creating my own simple framework using Javascript classes. Next time I will definitely use an established framework from the start.
Notably, Angular didn't really stand out here, and I want to explain why. It is not geared towards simplicity for singular developers. It is engineered to be maintainable in large and complex projects, and to optimize the hell out of the app. When it's all said and done, Angular is a great framework for large apps with multiple developers working on it due to it's structured layout and intentionally opinionated setup.
Iâm not trying to argue here & I donât use ng, but I find it baffling that it is always pitched as being for large projects/teams.
Is that because even a hello world has 100 files & you can therefore have 100 developers working on them? ..
..maybe a slight exaggeration there, but the structure just makes it too overwhelming for many, even though there are seemingly some good features (especially the cli, that was good even when I tried it years ago).
@@everyhandletaken The people pitching it for large projects/teams are speaking from experience. I built my team a couple of Angular libraries that make refactoring our complicated legacy system into single page apps a breeze. You don't have to worry about the file structure when your building blocks are encapsulated behind an npm package. The libraries themselves are modular enough that they are pretty flat and easy to step through and have about 80% test coverage. React is better as a pure UI framework, but it does not scale as well the way it manages state, lacks dependency injection and test-driven design, etc.
@@everyhandletaken automating linting, formatting, and testing with CI/CD pipelines only takes you so far. No need for 100 devs on a single project for it to become a PITA. Even 5 devs could cause merging issues in SC given that SC isn't being used by many companies as intended, especially ones where there are over ten long-term branches. Add in a backend like Django and/or Flask, things get even more interesting. Opinionated structure is a GOOD thing. Think of it like a standard operating procedure. The military has SOPs for a reason. This allows a plug and play with anyone replacing anyone. Ever try to work behind another free-form developer? Or try to fix something someone already had their hands in? Mechanics generally don't work on the same car behind another mechanic. One starts the repair, the same one finishes it. For good reason.
@@wilkes-barrescrantonsentin7401 ok
Angular is of course the best frontend framework currently available. These "Hello-World" comparisons have no significance whatsoever. I have never experienced a customer ordering a "Hello World" app :D. Basically, for simple apps, the physics of simplicity prevails, thus technology or processes plays a minor role. The main problem that I have experienced over the last 14 years especially with frontend developers, is that they have little understanding of principles of software engineering, and rather prefer chaos code that does not apply to any intelligent design rules. What you'll find in Angular are fundamental concepts of software engineering, nothing more! Hence, I recommend to learn software engineering first, and then Angular!
Great work in this video! I've used Vue quite extensively, and now I'm mixing Stimulus (mostly backend developer here). Would love to see Stimulus compared to these. What impressed me about it is that is very useful to migrate legacy apps and you can "mix" it with other JS frameworks
Hehe - just say you still love Ruby on Rails (still awesome for back-end) and developer happiness.
Svelte and Solid looks like the bests.
Adam, you use React right ? đ
I think so too, it feels like an evolution
Vue -> Svelte
React -> Solid
Pardon me, but I love your photo profile đ
@@mrsurver1890 beluga?
@@butterfly7562 My thoughts exactly. When I was taking a quick course on Svelte my first impression was "wow, a Vue that works". Also, Solid looks amazing. These 2 guys should get more attention from the dev community, they are really amazing takes on their predecessors.
Great video. Appreciate the đ thrown in for Ionic!
I'm only 50 seconds in and I'm stupendously impressed with the quality and sheer magnitude of how helpful this will be. Choosing what framework to use completely froze me from making a choice in the beginning - Analysis paralysis. Whish I'd seen this sooner.
I am only 5 words into your comment and really impressed with the way you use the language.
Final size? Great comparison. Despite tiny app, it would be good to compare the final size, to see just how heavy some of the frameworks are.
Absolutely love your vids! Keep it going you're đ„
I really like this - thanks - I think I will remake this over the weekend - or weekends upcoming and then add other frameworks I want to try in a similar way so I can have an easy way to try them, but then also so I have an easy way later to show a boss or co-worker -> hey here is a framework -> and what I like or don't like about this or that one. - well done.
Great way presenting the gist of different frameworks in a pinch but choosing one takes a lot more than a simple todo list implementation. When you make bigger projects with complex pages and have the requirement of supporting the client for at least 10 years while still updating and adding to the solution one doesn't just jump the next new framework. I know from experience picking anything outside React or Angular would be close to suicide or extremely risky for anything but some pet project. Vue is a runner up and could find a spot in the sun for one and done type of projects. All others I would give them another look in after 3-5 years no less.
Great one as always Jeff!!! I used to be a big Vue fan but I got turned off by Vue 3's composition API. I went back to react for large apps but I definitely think svelte is the best. Vue 3's script setup just became stable and I'm looking forward to see it improve even more. You rock!!!
Folks out there finding it difficult to develop in a single framework. This guy out of somewhere built it in 10 frameworks. đđđđ. Dude seriously how much time did this video take. Absolutely loved it. â€ïžâ€ïžâ€ïžâ€ïž
well this is very basic stuff
I don't want to sound uuh... But this was like the readme page of each of those githubs. Maybe second page of google level
@@goeland4585 It is not that hard on paper, but honestly doing it 10 times while explaining everything is nerve cracking.
Most of us don't have the time to learn 10 frameworks, basic or not..
Thank a lot for this large overview !
Thank you! This is really helpful.
I'd love to learn and try VUE or angular, probably my next ones to learn by myself!
By the way, your videos are amaizing, i'm not an english speaker but I still understand everything you say and as an ex-editor I can tell your videos have a looot of work behind them. Keep the work on! You're an inspiration
Considering he is one of the few people who speaks as quickly as he does on rather complicated subjects and you understand everything he says, I would say that you are an English speaker (even if English is not your mother language)
I've been too scared to touch any of the frameworks, but now that you've shown the pros and cons of all the big ones, I'm swayed to go for Vue. Thanks!
Another thing to consider is what companies in your area are using, which may help you if you are developing to get a job.
I've been using React for awhile and it is great but I have been playing with Svelte recently and I have to say it is absolutely fantastic.
It's so needed for beginner who has been overwhelmed by so many choices of frontend frameworks. I wish I had seen this video earlier.
Fantastic summary! Really impressive you were able to go through that many frameworks! One BIG difference I've felt between Lit and Vue (which I use regularly), which is indicative of a bigger paradigm between all these frameworks, is that Vue supports full reactivity whereas Lit only support reactive rendering. More specifically, this means that there's no way in Lit to create a reactive variable that depends on other reactive variables. You have to manually create hooks that update other variables when one changes. In Vue, you can with the "computed" field; it detects reactive variable dependencies and keeps things up-to-date. Svelte is the same as Vue, and React is the same as Lit. Extending your sample app to include a count of the total number of todo items would showcase this difference. When I was mainly working in Vue, I thought all these frameworks were likely very similar, but in reality this difference is actually kind of important to me. Vue behaves like one giant spreadsheet (which I love), and the code is much less brittle when I don't have to manually define the dependency graph in the code.
Just as a tip for solid, you shouldn't use `todos.map(...)` as it remaps the whole array when anything changes, if you use the component from solid it will actually only render items which update and leave the rest alone - stuff like that is what makes it so performant!
link please?
problem with web languages is how vague their data are. when you need to loop through something, an array is always faster than map. If you need to search for something, a map is always faster. If you need to loop through but add and remove elements on the whim, you want a list. but to web languages whenever you define an array, its a map.
@@System0Error0Message this comment is not referring to maps/hashtables as a data type, this is about the map function that applies an operation to every element of an array
I find react, very flexible to work with, especially with the hooks, JSX and styled components, you can pretty much do anything you already knew in JavaScript.
This is what exactly I am thinking of. Good Work @Fireship .
I really liked Angular for having everything out of the box, as well as the "forced" project structure since I'm bad at architectural decisions.
I really have an eye on Svelte and Solid tho! I'm obsessed with performances, and I love that these frameworks have compilers and no runtime
yes svelte is a lot of fun to work with
I like Angular structure but I hate the insane amount of files it generates for one component, so that's why I prefer Vue instead.
Working with Angular daily, and Vue for my alt projects.
I have to say I prefer Vue, the footprint for Angular is massive, and although fine for an app, itâs just not a catch all for web projects.
Vue is flexible and has a good sized community, itâs also independent so no corporate overlord behind it. Itâs also way easier to get going with it, as the learning curve is way lower.
@@OzzyTheGiant I agree, that's also a reason why Svelte catches my eye. You put everything in one file while separating html, css and js like angular
Angular is for real work, others are for fun.
A big and long project using react or others will be impossible to manage on medium/long term.
Angular was built for that, ive been working on enterprise projects with Angular for about 4 years and will keep doing so until the framework dies.
Wonderful video that no doubt _did_ take a ton of effort: thank you! My current favourite is Angular. I like opinionated frameworks and the reactive aspect (with RxJS) is incredibly powerful. That said, I have only dabbled with some other frameworks (e.g. React, Svelte).
Mithril, when running it through a build tool such as parcel as opposed to just including the script tag is severely underrated. Especially when you set it up to use jsx rather than hyperscript. I definitely prefer it over React.
Thanks for this excellent rundown. I'm a fan of SvelteKit.
Congrats, 2021! You've splintered the market into many different pieces. It's so crazy that every couple of months some new framework/tech comes along that wants to reinvent the wheel and 99% of the projects that are being built with it simply do not require it / do nothing that could not have been done before. Often new frameworks also start with a promise ("smaller", "faster", "less clutter") but end up exactly like the previous frameworks since down the road people realize how much is actually missing in the initial stage. My projects use modern but vanilla JS on a traditional stack and I run websites with many millions of pages + users that load usually quicker than many of those websites (usually nothing more than basic playgrounds) built on React, Vue etc. Oh and I don't need new need developers that dabble in yet another new framework all the time.
Thanks for another great video. As a veteran developer your content really helps me keep up to date on the newest concepts without spending hours doing tutorials. I really appreciate it!
Wow, that's a lot of effort. Thank you !
I understand you were going for the simplest approach for each framework, but I feel Vue couldâve benefited from at least a mention of the shorthand syntax (most experienced Vue developers will write :value vs v-bind:value and @submit vs v-on:submit) and , which brings it much closer to Svelte, by declaring state and methods as top-level variables and functions.
Otherwise, great comparison!
Composition API is also nicer imo
As soon as I discovered Svelte I dropped everything else for all new projects (where I have a choice)
Same
Same
Same
Same
Same
You don't have to add an event listener to the form in that way when working in Vanilla.
You can just use the onSubmit attribute and then you don't have to search for the event listener.
The idea is to simulate what js frameworks do, and state management is one of them, so thatâs why he made it like that
You also just add an id to the form which is descriptive. Personally, the vanilla javascript is the best in this video.
@@marc_joan Maybe, but IMO the main idea is to build the app that does the assigned task in the best way available in given environment. And ignoring convenient features of the environment and doing things roundabout way just to simulate other environments does a disservice to presenting that environment. If you have a wide collection of hammers and nails, smacking a screw with the handle of a screwdriver will sure prove the screw is a lousy nail and the screwdriver is a lousy hammer...
â@@marc_joan Why simulate how frameworks do when showing how to do with JS directly? Doesn't make sense. He's comparing how to achieve with different means. He's not explaining how frameworks execute the work.
You can even notice that he doesn't really solve most of his complaints. Sometimes even, he says a framework is OK, even though they have the exact same problem that he complaints about vanilla JS:
1:56: If it's so, then just use the on* attributes
2:54: Why is he doing it like that?!?! There's so easy ways for the li tag. If he doesn't like createElement, he can use tags
3:05: He never shown a way to keep it coupled. As in: the HTML is the source of truth
etc...
Even though it's usually called "Vanilla js" it doesn't mean "no libraries allowed". It just means the syntax and such is by using javascript and then DOM. With or without a library to assist with the process.
@@flipsnap I think his vanilla one is done in a way that shows he's either being deceptive or he just doesn't know (potentially out of practice) how to leverage the HTML and the DOM framework.
Trying to grow the skills form PHP + jQuery to something more 2023, this video really helped cast a net and see what's the approach that most "Clicks" for that next step. Personally it'll be Alpine. And thanks for the video!
This video makes me subscribe. Such hard work.
I'm an Angular guy, I love it, and although I'll pick up and learn one of these other frameworks in the near future, Angular will be my first choice for my personal projects
@@aviral1841 I learnt react as well, both the class based and the latest function based component and its just so complicated to use all the different hooks. Angular has a lot of stuff built in so it takes less time deciding basic stuff.
@@aviral1841 I don't feel comfortable with writing Jsx for my views(html). It feels like I don't have control over the app. In angular or any other framework, they give us a way to integrate Js in HTML, which feels comfortable. Maybe it's because I have worked with vanilla HTML CSS JavaScript too much and hence am habitual of seeing an HTML file as a control hub.
For serious things, use Angular. For playing a bit with JS, use Vue or React xD
It was a steep learning curve but now everything makes sense.
@@ProjectExMachina Exactly. Whenever you finish learn Angular, the other frameworks seem to be incomplete.
Svelte is definitely my favourite framework to use, but i still often en up going with React because the libraries that I need don't have Svelte-compatible versions or don't work very well with Svelte
Great video! The only thing is that when the app first load, if you put a todo inside a localStorage without checking if it's already there, you'll be re-adding stuff to your localStorage, duplicating things in every reload. Or maybe you should just delete the todos that were there after getting them so you don't need to re-check every time (at cost of performance, but not the focus here).That little thing distracted me the whole video.
Other than that, really great stuff. Thank you for sharing it!
Thank you, that's exactly what I'm looking for !
For my current goals, Alpine is the winner
Angular is my go to because I can incorporate firebase, threeJS, and testing nicely. The project structure makes it easy to maintain and organise tests for big apps. Also itâs just better to be god mode at one than mediocre at 3.
Aay three.js is awesome
How do you incorporate nicely threeJS to Angular ?
@@thommetsacha4462 just import it and use it in your components and services?
No need for Angular to use firebase and threeJS
This was awesome! I would have loved to see Ember included as well - I know it's not 'cool' anymore but its still got a lot of die-hard users out there!
I am one of them. Ember is the best! Ignoring Ember in a JS framework comparison is like ignoring Rails in a Ruby framework comparison. Ember is the most productive front-end framework IMHO.
đALL THE GOOD IDEAS HERE WILL END UP IN EMBER. ITS JUST A MATTER OF TIME.
czcams.com/video/Cvz-9ccflKQ/video.html
@@DhakshinDooliv no !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Die hard users? You mean hipsters.
@@carldrogo9492 lmao good jest.
Note that in Vue 3 with the composition API, you can declare methods, reactive data without the export default ... Way more simple
Yeah, Vue 3 is awesome. :D
oh didn't know that, thank you
Wow, I just ditched Angular and jumped to Vue for this reason. NOT!
@@muhammadhassankiyani8953 no one asked
Having gotten accustomed to JS libraries, I find myself writing my vanilla javascript with JS-library strategies, i.e. in your example I would only create the UI from the todo data array and not handle the UI separately. (Albeit, you have to clear out the UL each time then build it back up.) Once you get used to a JS library doing this, it makes more sense especially with Update and Delete operations which are easier to do by altering an array compared to altering the DOM directly and altering the data array. Last thoughts: I love Svelte!!!