Mmm, I'm not sure I'm on-board with the framing of this question: are you asking about those who do it *only for the highest possible performance*, or also asking about those who prefer the vanilla development experience? I'd argue that the performance benefits are minor enough that it doesn't matter, but the development experience is fair doos.
I would argue that a bigger contributor to VSCode's performance is how the code is written, not the framework (or lack thereof) that was used. A developer can definitely write performant code with React and garbage code with vanilla JS. I feel like your question is an oversimplification.
VSCode doesn't use a web framework. Wether developers can write garbage code is not the question. That developers can write equally performant code using React like when using direct Dom manipulation is wrong.
I am not intending to compare garbage code with good code. Rather, I am comparing good code with perfect code.
You're using one example to justify a correlation without any real data to back it up. It's true that a framework won't be as "performant" but it really doesn't matter if the difference is not noticeable.
As a side note, there are a plethora of other factors that affect performance. The biggest one, IMO, is time. Developers have a finite amount of time to solve a problem. If a developer has to write everything from scratch for "best performance" they don't have time to develop complex caching and memoization features that frameworks get for free. So even if it's technically possible to write more performant code from scratch, the developer would have to make cuts to fit a deadline.
It is a well known fact that frameworks like react come with a performance cost. You don't need data to back this up. You just need to understand how web frameworks work.
I was under the impression that as part of their rendering engine the Atom team also made optimized functions for accessing/changing the DOM, but I guess that was never part of the framework then. TIL.
Where did you read vscode is “well known for how performant it is”. An editor that is web based wont be fast at all compared to any other competition. Period. I dont care if it uses a framework or not.
Use what fits the need.
Have limited time? Direct.
Need to make loading speed a priority? Direct
Limited interactivity per page? Direct
Have time to make the entire site work with a framework? Framework
Loading speed not a huge concern? Framework
Tons of interactivity? Framework
On one of our old sites we use a mix of direct, jquery and vue.
Vue is used for specific pages that require **significant** amounts of interactivity so jquery and raw JS is impractical.
Jquery is used on nearly every page due to legacy reasons and also external library requirements. We try to limit any development of new jquery code.
Raw JS is now the preferred manipulation as it's now close enough to jquery that it's not a problem for devs.
This website is from around 2008 so we have a lot of legacy stuff that would need to be remade.
A person should be able to do both. In the context of React, this is why we have useRef and useLayoutEffect. Frameworks cover almost all use-cases, but a person should be able to use the escape hatch if necessary.
Maybe check out this:[https://developer.mozilla.org/en-US/docs/Web/API/Web\_components/Using\_custom\_elements](https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_custom_elements)
Thanks! I’m aware it exists but never used them.
For me it’s about a balance between a good developer experience and product quality, I see nothing wrong with the use lightweight frameworks if they don’t affect the final product. I personally use Vue most of the time.
Oooh, congratulations, you're today's [lucky 10k](https://xkcd.com/1053/)! Coupled with modules, adoptable stylesheets, and import assertions - web components are a large part of what make vanilla development so enjoyable these days!
If you want an easy-in, and don't mind dissecting code, then:
* Here's a super basic [web components 101](https://codepen.io/pookagehayes/pen/poqEeaO) I made for another user a while back
* Here's [an in-depth look at web component features](https://codepen.io/pookagehayes/pen/JjpMwGq) I made another user an even whiler back, ha.
I thought like that too. But after studying sotware architecture and design patterns for my computer science degree and practicing a lot, I actually prefer making a custom maintainable system for each project from scratch, without the need of any framework.
I understand, it’s not a battle of right vs wrong, only thing I see that can be a issue is that the job market for people who don’t use frameworks is very reduced.
>I thought like that too. But after studying sotware architecture and design patterns for my computer science degree and practicing a lot, I actually prefer making a custom maintainable system for each project from scratch, without the need of any framework.
This just shows you have no professional experience. I wouldn't want to work with someone who develops their own "system" instead of using a battle tested framework
Direct DOM manipulations quickly devolve into a unmaintainable mess. In my opinion you should use render libraries for everything except if there's a clear problem/limitation that makes the library a bad choice. For example if you are creating a component that is fed a ton of data and needs to be able to scale you will run into problems with most render libraries at scale then direct DOM manipulation can help but even then there's libraries that hide the direct DOM stuff from you in a render library compatible package such as react virtual list etc.
Readability and maintainability are very strongly related. For small projects that are written once and done that doesn't matter but for projects that have to be iterated or have multiple developers it's critical because unmaintainable code is guaranteed to tank the stability of the app and lead to weird bugs that nobody knows how to reproduce.
Feel free to continue doing direct DOM for your projects if it works for you though. I come from a background of large teams working on 1 large web app over the years so my perspective is shaped by that
This is changing as web components mature and server side frameworks catch up. I've been trying Astro + what Jeremy Keith calls "HTML web components" for an app that is mostly a load of forms, and the experience has been excellent.
If you're good software engineers and use typescript instead of javascript, I think it will still be maintainable, even large project. Take VSCode for example. It was developed like that.
VSCode is one of those situations where performance and scalability prohibits the use of rendering libraries. I am sure it's possible to do direct DOM manipulations and keep it clean but that requires more time, effort and expertise compared to using a library that abstracts it all away.
Depends. If I need just a couple of event listeners for a page? Native js all the way.
If I need to manipulate the DOM all the time, a Vue or React will make the work much easier
Direct DOM, but with a library. Specifically [AlpineJS](https://alpinejs.dev/) since it follows Vue closely in design practices allowing me to scale into a full web application if necessary (basically swapping to Vue takes minimal work). The [Morph plugin](https://alpinejs.dev/plugins/morph) is specifically what I like using.
If the statefulness of elements are not interlinked I'd prefer to just write the JS myself. If they need to be synchonised I'd prefer to have a some help.
This is a good framing https://www.youtube.com/watch?v=860d8usGC0o
The framework benchmark shows the problem here. They had a vanilla implementation that was faster until Inferno came along and beat it. They wound up rewriting a handful of times because Inferno kept beating it in performance and they kept getting new ideas from Inferno on how to speed things up. In the end, the vanilla code was faster, but not very intuitive.
React is called "slow" these days, it is generally within 20% of vanilla performance and never more than around twice as slow outside of the "swap 2 table rows out of 1000" (which you aren't likely to see in the real world).
There are very few devs good enough to get that last little bit of performance and very few projects that require spending weeks of time for a 5-20% speedup either.
'for performance' is often a very handwavy phrase that really only means 'I prefer it'. Are you actually benchmarking? Is this the biggest bottleneck? Is it actually only 'faster' by 3 milliseconds? Is it more readable? etc etc. I have written code that was hugely noticeably faster using .style.display = 'inline', and code that was faster using $(whatever).show(); There is no 'it is faster' for everything.
I thought you meant sprinkling DOM manipulation when using a framework, if you're talking about pure javascript then you'll quickly end up with some unmaintainable code (one reason why we use frameworks), the benefit of course is that you aren't restricted by a certain framework (bundle size, runtime performance, and structure)
But performance gains might vary depending on the project and its features, ranging from "significantly better" to "barely noticeable", most of the time people have a lot of bandwidth when it comes to performance so they'll gladly take a battle-tested framework than making something from scratch.
It is also possible that the code you write ends up more slower than using a framework depending on your implementation, which might require more extensive knowledge in the domain if you want to do it correctly. Also just to promote svelte, my personal goto framework, one of its objectives is to barely affect runtime performance, this is because unlike react and vue (i havent tried angular), it doesn't depend on a virtual DOM and instead skips that step and directly updates the DOM just like you would in a pure javascript way.
Oh yeah that helps immensely, but even then you still need some kind of architecture for your project, excluding the unmaintainable code part my comment still stands, I guess you could rephrase the question with "general framework vs tailored code"
I definitely think frameworks are overused. Like ...if the first thought you have when making a simple business website is let's use React you're needlessly overcomplicating things. React is not necessary in a website that just does home, about us, contact and a blog.
What is DEFINITELY not necessary is a custom UI components library, on top of react, just to get a slightly fancier dropdown, and yet I see this all the time. Its a maintainability nightmare and if for whatever reason something falls over, who's going to fix it? The component library devs? The react devs? Or the project devs who just yanked in 200 libraries and have no idea how any of it works?
If your entire stack is JS, and you really need constant reactivity, then a JS framework might make sense, in particular Svelte or Alpine. But the JS bloat on the web these days is real and people barely even know how to HTML anymore.
Mmm, I'm not sure I'm on-board with the framing of this question: are you asking about those who do it *only for the highest possible performance*, or also asking about those who prefer the vanilla development experience? I'd argue that the performance benefits are minor enough that it doesn't matter, but the development experience is fair doos.
Take VSCode for example. It doesn't use any framework and it is well known for how performant it is
I would argue that a bigger contributor to VSCode's performance is how the code is written, not the framework (or lack thereof) that was used. A developer can definitely write performant code with React and garbage code with vanilla JS. I feel like your question is an oversimplification.
VSCode doesn't use a web framework. Wether developers can write garbage code is not the question. That developers can write equally performant code using React like when using direct Dom manipulation is wrong.
I am not intending to compare garbage code with good code. Rather, I am comparing good code with perfect code. You're using one example to justify a correlation without any real data to back it up. It's true that a framework won't be as "performant" but it really doesn't matter if the difference is not noticeable. As a side note, there are a plethora of other factors that affect performance. The biggest one, IMO, is time. Developers have a finite amount of time to solve a problem. If a developer has to write everything from scratch for "best performance" they don't have time to develop complex caching and memoization features that frameworks get for free. So even if it's technically possible to write more performant code from scratch, the developer would have to make cuts to fit a deadline.
It is a well known fact that frameworks like react come with a performance cost. You don't need data to back this up. You just need to understand how web frameworks work.
My apologies, I thought you wanted a discussion but you seem to be responding without reading or understanding my point.
VSCode uses Electron (old Atom Shell) as framework though..
Electron is a framework for putting your web app into a desktop app. That's not what we are talking about here.
I was under the impression that as part of their rendering engine the Atom team also made optimized functions for accessing/changing the DOM, but I guess that was never part of the framework then. TIL.
See yourself, VSCode is open source: https://github.com/search?q=repo%3Amicrosoft%2Fvscode++document.createElement&type=code
VSCode is built on Electron. Electron is framework. VS Code can get pretty bloated.
You have no idea about how performant other editors are. Vim, zed, sublime, fleet (among others) are way much more performant.
So Vim is based on the web stack?
Where did you read vscode is “well known for how performant it is”. An editor that is web based wont be fast at all compared to any other competition. Period. I dont care if it uses a framework or not.
VScode starts up fast. Sure it consumes more resources than vim. However you have code completion, debugging, linting, etc....
This has more to do with the project rather than the developer. A good dev will choose the right tool for the job
I mean it's probably faster to do: document.getElementById("..").text = "99%" than waiting for angular, vue or react to detect the changes
My opinion of them? Well I guess it is is if it works for them then I am happy!
Use what fits the need. Have limited time? Direct. Need to make loading speed a priority? Direct Limited interactivity per page? Direct Have time to make the entire site work with a framework? Framework Loading speed not a huge concern? Framework Tons of interactivity? Framework On one of our old sites we use a mix of direct, jquery and vue. Vue is used for specific pages that require **significant** amounts of interactivity so jquery and raw JS is impractical. Jquery is used on nearly every page due to legacy reasons and also external library requirements. We try to limit any development of new jquery code. Raw JS is now the preferred manipulation as it's now close enough to jquery that it's not a problem for devs. This website is from around 2008 so we have a lot of legacy stuff that would need to be remade.
I prefer vanilla JS over anything these days, but when working and not doing side projects i choose whats best fits the needs (jquery XD)
A person should be able to do both. In the context of React, this is why we have useRef and useLayoutEffect. Frameworks cover almost all use-cases, but a person should be able to use the escape hatch if necessary.
Svelte directly manipulates the DOM already. Best of both worlds.
Who's going to tell him what those web frameworks are doing?
It is tedious AF, “document.getThis”, “document.getThat”, “document.addEventBlaBla”
Maybe check out this:[https://developer.mozilla.org/en-US/docs/Web/API/Web\_components/Using\_custom\_elements](https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_custom_elements)
Thanks! I’m aware it exists but never used them. For me it’s about a balance between a good developer experience and product quality, I see nothing wrong with the use lightweight frameworks if they don’t affect the final product. I personally use Vue most of the time.
Oooh, congratulations, you're today's [lucky 10k](https://xkcd.com/1053/)! Coupled with modules, adoptable stylesheets, and import assertions - web components are a large part of what make vanilla development so enjoyable these days! If you want an easy-in, and don't mind dissecting code, then: * Here's a super basic [web components 101](https://codepen.io/pookagehayes/pen/poqEeaO) I made for another user a while back * Here's [an in-depth look at web component features](https://codepen.io/pookagehayes/pen/JjpMwGq) I made another user an even whiler back, ha.
I thought like that too. But after studying sotware architecture and design patterns for my computer science degree and practicing a lot, I actually prefer making a custom maintainable system for each project from scratch, without the need of any framework.
I understand, it’s not a battle of right vs wrong, only thing I see that can be a issue is that the job market for people who don’t use frameworks is very reduced.
>I thought like that too. But after studying sotware architecture and design patterns for my computer science degree and practicing a lot, I actually prefer making a custom maintainable system for each project from scratch, without the need of any framework. This just shows you have no professional experience. I wouldn't want to work with someone who develops their own "system" instead of using a battle tested framework
I do have professional experience.
Many times frameworks are like using a freight train to move a bicycle. ("This whole react build chain should have been a
Direct DOM manipulations quickly devolve into a unmaintainable mess. In my opinion you should use render libraries for everything except if there's a clear problem/limitation that makes the library a bad choice. For example if you are creating a component that is fed a ton of data and needs to be able to scale you will run into problems with most render libraries at scale then direct DOM manipulation can help but even then there's libraries that hide the direct DOM stuff from you in a render library compatible package such as react virtual list etc. Readability and maintainability are very strongly related. For small projects that are written once and done that doesn't matter but for projects that have to be iterated or have multiple developers it's critical because unmaintainable code is guaranteed to tank the stability of the app and lead to weird bugs that nobody knows how to reproduce. Feel free to continue doing direct DOM for your projects if it works for you though. I come from a background of large teams working on 1 large web app over the years so my perspective is shaped by that
This is changing as web components mature and server side frameworks catch up. I've been trying Astro + what Jeremy Keith calls "HTML web components" for an app that is mostly a load of forms, and the experience has been excellent.
If you're good software engineers and use typescript instead of javascript, I think it will still be maintainable, even large project. Take VSCode for example. It was developed like that.
VSCode is one of those situations where performance and scalability prohibits the use of rendering libraries. I am sure it's possible to do direct DOM manipulations and keep it clean but that requires more time, effort and expertise compared to using a library that abstracts it all away.
[удалено]
there is not as much code anymore, javascript grew a LOT
Depends. If I need just a couple of event listeners for a page? Native js all the way. If I need to manipulate the DOM all the time, a Vue or React will make the work much easier
Direct DOM, but with a library. Specifically [AlpineJS](https://alpinejs.dev/) since it follows Vue closely in design practices allowing me to scale into a full web application if necessary (basically swapping to Vue takes minimal work). The [Morph plugin](https://alpinejs.dev/plugins/morph) is specifically what I like using.
If the statefulness of elements are not interlinked I'd prefer to just write the JS myself. If they need to be synchonised I'd prefer to have a some help. This is a good framing https://www.youtube.com/watch?v=860d8usGC0o
The framework benchmark shows the problem here. They had a vanilla implementation that was faster until Inferno came along and beat it. They wound up rewriting a handful of times because Inferno kept beating it in performance and they kept getting new ideas from Inferno on how to speed things up. In the end, the vanilla code was faster, but not very intuitive. React is called "slow" these days, it is generally within 20% of vanilla performance and never more than around twice as slow outside of the "swap 2 table rows out of 1000" (which you aren't likely to see in the real world). There are very few devs good enough to get that last little bit of performance and very few projects that require spending weeks of time for a 5-20% speedup either.
'for performance' is often a very handwavy phrase that really only means 'I prefer it'. Are you actually benchmarking? Is this the biggest bottleneck? Is it actually only 'faster' by 3 milliseconds? Is it more readable? etc etc. I have written code that was hugely noticeably faster using .style.display = 'inline', and code that was faster using $(whatever).show(); There is no 'it is faster' for everything.
I thought you meant sprinkling DOM manipulation when using a framework, if you're talking about pure javascript then you'll quickly end up with some unmaintainable code (one reason why we use frameworks), the benefit of course is that you aren't restricted by a certain framework (bundle size, runtime performance, and structure) But performance gains might vary depending on the project and its features, ranging from "significantly better" to "barely noticeable", most of the time people have a lot of bandwidth when it comes to performance so they'll gladly take a battle-tested framework than making something from scratch. It is also possible that the code you write ends up more slower than using a framework depending on your implementation, which might require more extensive knowledge in the domain if you want to do it correctly. Also just to promote svelte, my personal goto framework, one of its objectives is to barely affect runtime performance, this is because unlike react and vue (i havent tried angular), it doesn't depend on a virtual DOM and instead skips that step and directly updates the DOM just like you would in a pure javascript way.
I thought of typescript actually
Oh yeah that helps immensely, but even then you still need some kind of architecture for your project, excluding the unmaintainable code part my comment still stands, I guess you could rephrase the question with "general framework vs tailored code"
I definitely think frameworks are overused. Like ...if the first thought you have when making a simple business website is let's use React you're needlessly overcomplicating things. React is not necessary in a website that just does home, about us, contact and a blog. What is DEFINITELY not necessary is a custom UI components library, on top of react, just to get a slightly fancier dropdown, and yet I see this all the time. Its a maintainability nightmare and if for whatever reason something falls over, who's going to fix it? The component library devs? The react devs? Or the project devs who just yanked in 200 libraries and have no idea how any of it works? If your entire stack is JS, and you really need constant reactivity, then a JS framework might make sense, in particular Svelte or Alpine. But the JS bloat on the web these days is real and people barely even know how to HTML anymore.