Web Development Simplified with Svelte(objectcomputing.com)
objectcomputing.com
Web Development Simplified with Svelte
https://objectcomputing.com/resources/publications/sett/july-2019-web-dev-simplified-with-svelte
161 comments
There is something close, even better, when overall API design/architecture is considered, that is ember.js. Check ember-cli/embroider which angular-cli initially forked from. I give it 1.5 years for ember to pretty much dominate SPA development, In the last two years some people were laughing at me, now Im laughing at them.
Our company trialed Ember this year alongside React, Angular, and Vue for a new SPA. Ember was the worst of the bunch:
- It is stringly typed. All over the place you're globally registering names as strings (or worse, using strings that implicitly resolve to filenames). You'll write `store.createRecord('mymodel')` instead of just importing things using standard ECMAScript imports.[1] This means static analysis is out the window, which makes it labor-intensive to find usages or do even simple refactors like renames.
- It leans on global state and object mutation way too much, instead of using functional state updating. This was the way older frameworks like Backbone, YUI, etc worked. Web development is moving away from this paradigm, and for good reason.
- Static typing support is non-negotiable in 2019 (and 2015 for that matter, but I digress). Support in Ember is just not there, and I don't see much promise for the future either. React and Angular have had good support for Typescript and/or Flow for a good 5 years now.
- One high point for Ember: the in-browser testing beat the pants off any of the other frameworks. We ended up going with React/Jest/Puppeteer, but this meant we (meaning, I) had to write 150 lines of boilerplate that Ember gives you for free.
Overall working in Ember honestly felt like being transported back in time by 10 years. I guess if you're a solo dev it's easy to whip up a quick demo that seems fine, but you'll hit the wall very quickly where the project becomes write-only. I think it's unlikely a brand new build system, no matter how fancy, can make up for these architectural problems.
[1]: https://guides.emberjs.com/release/getting-started/creating-...
EDIT: I regret taking the time to write this. Should have checked submission history first…
- It is stringly typed. All over the place you're globally registering names as strings (or worse, using strings that implicitly resolve to filenames). You'll write `store.createRecord('mymodel')` instead of just importing things using standard ECMAScript imports.[1] This means static analysis is out the window, which makes it labor-intensive to find usages or do even simple refactors like renames.
- It leans on global state and object mutation way too much, instead of using functional state updating. This was the way older frameworks like Backbone, YUI, etc worked. Web development is moving away from this paradigm, and for good reason.
- Static typing support is non-negotiable in 2019 (and 2015 for that matter, but I digress). Support in Ember is just not there, and I don't see much promise for the future either. React and Angular have had good support for Typescript and/or Flow for a good 5 years now.
- One high point for Ember: the in-browser testing beat the pants off any of the other frameworks. We ended up going with React/Jest/Puppeteer, but this meant we (meaning, I) had to write 150 lines of boilerplate that Ember gives you for free.
Overall working in Ember honestly felt like being transported back in time by 10 years. I guess if you're a solo dev it's easy to whip up a quick demo that seems fine, but you'll hit the wall very quickly where the project becomes write-only. I think it's unlikely a brand new build system, no matter how fancy, can make up for these architectural problems.
[1]: https://guides.emberjs.com/release/getting-started/creating-...
EDIT: I regret taking the time to write this. Should have checked submission history first…
> It is stringly typed.
This is a big issue.
> - It leans on global state and object mutation
I dont see this as a problem, it's an implementation details. If the software works well (fast enough) and provides a nice API, I dont care much about the internals.
> - Static typing support is non-negotiable in 2019
Agreed, but I'd like to combine this point with the first.
EDIT: thanks for typing your reply. :)
This is a big issue.
> - It leans on global state and object mutation
I dont see this as a problem, it's an implementation details. If the software works well (fast enough) and provides a nice API, I dont care much about the internals.
> - Static typing support is non-negotiable in 2019
Agreed, but I'd like to combine this point with the first.
EDIT: thanks for typing your reply. :)
There are 3 places where one can say ember is stringly typed:
1- controller/service dependency injection(no more with octane).
2- ember data API(store.createRecord(modelNameString) and serializerFor(modelNameString)). I don't mind it results in less imports and API might change in the future.
3- this.owner.lookup('$abstractionName:$fileName') => I like this one. It removes the need for an extra line of import code and import path could have been very verbose for something far away in dependency tree.
Therefore, I don't think it is a serious issue anymore.
Majority of the ember source code and internal packages are in typescript and there is a good typescript support for app development via addons. As a person who wrote an ember-cli alternative, I can say with confidence that you can build ember apps in typescript. Despite all that, the type analysis performance overhead/cost of typescript compiler today isn't worth the type benefits for really big SPAs yet in my opinion. I think instead those frontend teams should optimize their hiring and mentoring practices until we have a very fast typescript compiler.
Addon/package authors can write their code in typescript and make it work with JS or TS ember application code today.
TLDR for the ones who made weak typescript arguments here against ember.js: Don't be a hypester and claim certain things without making a good research.
1- controller/service dependency injection(no more with octane).
2- ember data API(store.createRecord(modelNameString) and serializerFor(modelNameString)). I don't mind it results in less imports and API might change in the future.
3- this.owner.lookup('$abstractionName:$fileName') => I like this one. It removes the need for an extra line of import code and import path could have been very verbose for something far away in dependency tree.
Therefore, I don't think it is a serious issue anymore.
Majority of the ember source code and internal packages are in typescript and there is a good typescript support for app development via addons. As a person who wrote an ember-cli alternative, I can say with confidence that you can build ember apps in typescript. Despite all that, the type analysis performance overhead/cost of typescript compiler today isn't worth the type benefits for really big SPAs yet in my opinion. I think instead those frontend teams should optimize their hiring and mentoring practices until we have a very fast typescript compiler.
Addon/package authors can write their code in typescript and make it work with JS or TS ember application code today.
TLDR for the ones who made weak typescript arguments here against ember.js: Don't be a hypester and claim certain things without making a good research.
Thanks for this breakdown, very helpful.
That appears unlikely:
https://trends.google.com/trends/explore?date=today%205-y&q=...
https://trends.google.com/trends/explore?date=today%205-y&q=...
I dont care about fashion too much, I care about code, maintenance and community quality more. It is in my opinion the only way to build good and sustainable development teams in the current environment. Contrarian opinion I know..
> > > I give it 1.5 years for ember to pretty much dominate SPA development
> > That appears unlikely: https://trends.google.com/trends/explore?date=today%205-y&q=....
> I dont care about fashion too much
Do you see the problem here?
> > That appears unlikely: https://trends.google.com/trends/explore?date=today%205-y&q=....
> I dont care about fashion too much
Do you see the problem here?
I don’t, what’s the relationship between having an opinion in the minority and not caring for fashion (chasing hype)
For something to dominate it needs some hype but having hype doesn’t lead to dominating the market
Someone who "give[s] it 1.5 years for ember to completely dominate SPA development" and is laughing at people who doubted it clearly cares about fashion.
The fact that ember doesn't integrate natively with typescript means that probably won't happen...
> Angular [...] You can really focus on the application
I don't know about the newest versions but I have to disagree for Angular 1, the framework was so badly designed and overengineered that my team and I had to constantly check the doc to remember how to write x or y or what were the best practices to do z.
React does less than Angular but it's way more intuitive and straightforward. The doc is a one-time read.
> forget tooling [...] The webpack build that the Angular CLI uses internally is completely transparent [...] nothing else comes even close
React has create-react-app. Vue probably has something similar. Same for Ember. Last time I had to setup a build pipeline myself was like 3 years ago.
I don't know about the newest versions but I have to disagree for Angular 1, the framework was so badly designed and overengineered that my team and I had to constantly check the doc to remember how to write x or y or what were the best practices to do z.
React does less than Angular but it's way more intuitive and straightforward. The doc is a one-time read.
> forget tooling [...] The webpack build that the Angular CLI uses internally is completely transparent [...] nothing else comes even close
React has create-react-app. Vue probably has something similar. Same for Ember. Last time I had to setup a build pipeline myself was like 3 years ago.
When folks say Angular they aren't including v1. That is called AngularJS.
Also, you still configure webpack for your React app right?
Also, you still configure webpack for your React app right?
The problem I am running into with Angular is there is no middle ground.
On one hand, you can yarn install and ng create and you've got a project.
On the other hand, the largest software company on earth uses it.
In the middle is a wasteland. I've worked with it for years and have been waiting for Google to document to the angular compiler (angular/angular not the angular/angular-cli with a million webpack presets). To this day there remains zero documentation other than source code. https://github.com/angular/angular/issues/29623
On one hand, you can yarn install and ng create and you've got a project.
On the other hand, the largest software company on earth uses it.
In the middle is a wasteland. I've worked with it for years and have been waiting for Google to document to the angular compiler (angular/angular not the angular/angular-cli with a million webpack presets). To this day there remains zero documentation other than source code. https://github.com/angular/angular/issues/29623
The fact you can easily make yet another To Do list app isn't very useful. If you can't easily make a very simple app then something is seriously wrong with the framework.
A much more useful question is whether or not a framework makes it easier (or faster, or better, or something) to write a complex app. In the case of Svelte, all the hard stuff (eg state management, sync'ing data from APIs, etc) is outside of the scope framework. That make Svelte much smaller and simpler, but it makes writing a complex app harder (because you need to glue some other libraries together yourself; the framework isn't doing it for you).
A much more useful question is whether or not a framework makes it easier (or faster, or better, or something) to write a complex app. In the case of Svelte, all the hard stuff (eg state management, sync'ing data from APIs, etc) is outside of the scope framework. That make Svelte much smaller and simpler, but it makes writing a complex app harder (because you need to glue some other libraries together yourself; the framework isn't doing it for you).
State Management is a first-class part of svelte, check out their `Store` implementation.
https://svelte.dev/tutorial/writable-stores
It only took me a few hours to fully appreciate what a tidy solution Svelte's store implementation was.
As far as syncing data from APIs: I am pretty sure that it should be out of scope for _any_ view layer. APIs vary widely, and it wouldn't be appropriate for a view tool (Svelte, React, Vue, etc) to have an opinion. It's really up to the developer, and for the most part (and I may have a controversial opinion here?) should be a pretty simple set of wrappers around `fetch`). Where's Vue or React's API consumption tooling?
https://svelte.dev/tutorial/writable-stores
It only took me a few hours to fully appreciate what a tidy solution Svelte's store implementation was.
As far as syncing data from APIs: I am pretty sure that it should be out of scope for _any_ view layer. APIs vary widely, and it wouldn't be appropriate for a view tool (Svelte, React, Vue, etc) to have an opinion. It's really up to the developer, and for the most part (and I may have a controversial opinion here?) should be a pretty simple set of wrappers around `fetch`). Where's Vue or React's API consumption tooling?
From experience building more complex apps in Svelte, I can say that this has not been my experience, & doesn't accurately depict React in practice. Three aspects that make it really killer – a really great story for handling app & component state cleanly regardless of complexity, a great style scoping story, and powerful transition / animation primitives that fit neatly into the idiom – has made it easier to build large data apps than I've found with React (which I also use).
Another aspect I have really appreciated is that I have substantially fewer dependencies, since there is more included in Svelte than in React. I tend to only use d3 utility functions (format, scales, etc.) & immer (which I pair with svelte stores to get something kind of Redux-y, which is great for other devs jumping into Svelte from React-land). Fewer dependencies means I'm less likely to encounter awful dependency hell.
Generally, I feel like every time I see a Svelte thread here, there's a lot of random noise, but it's good to listen to the folks who actually use it. There are situations where it makes sense, and situations where it probably doesn't. The main reason why I might not use it is ecosystem friction – a lot of devs I know would prefer to just use what they know, even if it is painful relative to Svelte & friends.
Another aspect I have really appreciated is that I have substantially fewer dependencies, since there is more included in Svelte than in React. I tend to only use d3 utility functions (format, scales, etc.) & immer (which I pair with svelte stores to get something kind of Redux-y, which is great for other devs jumping into Svelte from React-land). Fewer dependencies means I'm less likely to encounter awful dependency hell.
Generally, I feel like every time I see a Svelte thread here, there's a lot of random noise, but it's good to listen to the folks who actually use it. There are situations where it makes sense, and situations where it probably doesn't. The main reason why I might not use it is ecosystem friction – a lot of devs I know would prefer to just use what they know, even if it is painful relative to Svelte & friends.
>There are situations where it makes sense, and situations where it probably doesn't.
I have been working with svelte for quite some time now, and honestly I can not think of a time where it did not make sense to use it. At its most basic form, its compiles down to vanilla javascript with a small footprint and offers a tidy workspace when working with html/css/es6.
I have been working with svelte for quite some time now, and honestly I can not think of a time where it did not make sense to use it. At its most basic form, its compiles down to vanilla javascript with a small footprint and offers a tidy workspace when working with html/css/es6.
This is not different from React, which is just a view library.
Except it isn't, it's a compiler rather than just a view library.
The point is it ain't just a view library, and once you have your own compiler you can get more done.
The point is it ain't just a view library, and once you have your own compiler you can get more done.
My point was more about the problem it solves not the nature of the tool, i.e. that it does not concern itself with data store or routing.
I've been distanced from web development for a year and you now have a cool new framework, ReactJS is surpassed by VueJS and probably some other packaging tools did something interesting and new opinions about how the same old things should be built are on the rise.
But I have a serious question: Why the web dev is still a relevant thing? Don't get me wrong, I won't argue that the web is dead and all should move into AI or VR or something but I am under the impression that most of the problems that can be solved through a Web UI are mostly solved. Sure people come up with interesting business ideas all the time but they usually don't require innovative Web UI tech and can be built just fine with 10-year-old frameworks.
How is the web world doing? Why would anyone keep creating cool new frameworks?
But I have a serious question: Why the web dev is still a relevant thing? Don't get me wrong, I won't argue that the web is dead and all should move into AI or VR or something but I am under the impression that most of the problems that can be solved through a Web UI are mostly solved. Sure people come up with interesting business ideas all the time but they usually don't require innovative Web UI tech and can be built just fine with 10-year-old frameworks.
How is the web world doing? Why would anyone keep creating cool new frameworks?
A lot of devs tend to feel that UI is something trivial and “solved”. The unfortunate reality is that UI related code gravitates towards being extremely messy, convoluted and harder to change over time. It changes more than other types of code, is really hard to test properly and has to handle coordinating events firing from all over the place. Add to this JavaScript’s lack of types and past testing culture and you can see how creating a framework that fits your needs can become an appealing option.
Writing accessible web interfaces have visually parity across a handful of browsers over a matrix of many devices, is so much more challenging than writing a scalable REST backend service.
Yeah, if there's a solved problem, it's CRUD microservices.
As long as we've thought enough about the design (db schema, service responsibility boundaries, etc etc) we can get a working microservice up in hours to a few days.
As long as we've thought enough about the design (db schema, service responsibility boundaries, etc etc) we can get a working microservice up in hours to a few days.
My personal view is that the 'what' in frontend development generally isn't super interesting and most web frontends are very similar; if you do not focus on new tooling, you will just do the same thing over and over which is unsatisfying.
If you're a very smart dev at one of the biggest tech companies in the world, getting paid a quarter of a million dollars per year working on a niche team that handles a small section of a single product, you will probably get bored pretty quickly and start focusing on the how. It's a shame really; some of the greatest minds of our generation are being put into rooms to work on animations for buttons on virtual DVD cases and Photo Books.
The silver lining is all these tools are given away for free. The tools so great and their corporate creators so cool that you can just have them! A cynical reading is that they are only given away because the competition can derive no value from them... In fact, forcing your competitors to retrain every 6 months when you release another major version that breaks all existing projects will only slow them down and fill your coffers! The new whatsapp will never get off the ground, because the devs were too busy rewriting babel files and the money ran out... you just saved a cool $18bn.
If these frameworks were really the key to anyone's successful business you would not know that they exist.
If you're a very smart dev at one of the biggest tech companies in the world, getting paid a quarter of a million dollars per year working on a niche team that handles a small section of a single product, you will probably get bored pretty quickly and start focusing on the how. It's a shame really; some of the greatest minds of our generation are being put into rooms to work on animations for buttons on virtual DVD cases and Photo Books.
The silver lining is all these tools are given away for free. The tools so great and their corporate creators so cool that you can just have them! A cynical reading is that they are only given away because the competition can derive no value from them... In fact, forcing your competitors to retrain every 6 months when you release another major version that breaks all existing projects will only slow them down and fill your coffers! The new whatsapp will never get off the ground, because the devs were too busy rewriting babel files and the money ran out... you just saved a cool $18bn.
If these frameworks were really the key to anyone's successful business you would not know that they exist.
You said "My personal view is that the 'what' in frontend development generally isn't super interesting and most web frontends are very similar." I think if you take a serious look at Svelte you will see that it is much simpler than the current popular web frameworks.
> A cynical reading is that they are only given away because the competition can derive no value from them... In fact, forcing your competitors to retrain every 6 months when you release another major version that breaks all existing projects will only slow them down and fill your coffers!
https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
As a sort of side note, amusingly, Microsoft is rarely included in the FANG-style acronyms. There's a reason for that, Microsoft is the granddaddy of FANGs, from a strategy perspective :-)
https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
As a sort of side note, amusingly, Microsoft is rarely included in the FANG-style acronyms. There's a reason for that, Microsoft is the granddaddy of FANGs, from a strategy perspective :-)
Or perhaps that the granddaddy of FANG-style acronyms, NOISE, was coined specifically to refer to Microsoft competitors; Netscape, Oracle, IBM, Sun and Everyone else.
> amusingly, Microsoft is rarely included in the FANG-style acronyms. There's a reason for that, Microsoft is the granddaddy of FANGs, from a strategy perspective
I propose a new law: "Every technical discussion in Hacker News is exhausted when stock market or cryptocurrencies are mentioned".
I propose a new law: "Every technical discussion in Hacker News is exhausted when stock market or cryptocurrencies are mentioned".
> if you do not focus on new tooling, you will just do the same thing over and over which is unsatisfying.
I have no idea how you go from "knowing what you're doing" to "unsatisfying"
I have no idea how you go from "knowing what you're doing" to "unsatisfying"
> some of the greatest minds of our generation are being put into rooms to work on animations for buttons on virtual DVD cases and Photo Books.
why thank you sir!
why thank you sir!
I encounter this impression a lot and find it a bit confusing. I suppose this is what it looks like at a distance, because at a distance you see news and headlines, not practical realities. In point of fact, I think the VueJS boomlet is over, and I doubt its uptake got anywhere near ReactJS. The community has by and large settled on Webpack for building and bundling, and Webpack itself is quite stable after a few years of finding the right API and its proper place in the stack. Finally, the community seems to be converging on TypeScript, an eminently sane compile-to-JS language, and an increasing share of the ecosystem has increasingly robust TypeScript support
Your vision isn't based in reality.
Have you seen the growth of vetur and vue browser extension weekly active users?
https://youtu.be/zB3HOejXqwk?t=302
https://youtu.be/zB3HOejXqwk?t=302
Do you see a slide there that compares them to React?
The person you responded to didn't say "Vue isn't marginally popular", they said
> I doubt its uptake got anywhere near ReactJS...
and it didn't. You can read about that here -
https://hackernoon.com/angular-vs-react-vs-vue-which-is-the-...
Don't stop reading at the stack overflow opinion poll graph though because Google Trends and NPM trends tell a significantly different story.
The person you responded to didn't say "Vue isn't marginally popular", they said
> I doubt its uptake got anywhere near ReactJS...
and it didn't. You can read about that here -
https://hackernoon.com/angular-vs-react-vs-vue-which-is-the-...
Don't stop reading at the stack overflow opinion poll graph though because Google Trends and NPM trends tell a significantly different story.
Real stable right? Like MJS files for module loading? Real stability there. It's the inmates running the asylum. We use to have to deal with IE holding things back, now it's the JS/Node community.
No vuejs did not surpass reactjs.
In fact reactjs found an even simpler programming model and is leading with this new approach ... it is called hooks.
Vuejs is copying the same concept and in fact wanted to dump it’s old way to fully embrace react hooks style programming but that angered the vuejs community.
In fact reactjs found an even simpler programming model and is leading with this new approach ... it is called hooks.
Vuejs is copying the same concept and in fact wanted to dump it’s old way to fully embrace react hooks style programming but that angered the vuejs community.
Don't get me wrong, I love hooks because I know how to use them, but there's so many easy pitfalls with them, and I constantly have to pester people about them in code reviews, if so many people in my company (and wider) misuse them by accident, it makes me me doubt how well thought out they are.
I know some people have a thing for arcane programming (for a lack of better word), but in my opinion it just makes code harder to write, understand, and even statically analyse.
Not to mention, the official lining for hooks leaves a lot to be desired for, especially because some internal React return values are treated magically by the linter (useState, useReducer to name a few) when it comes to hook dependency management.
I know some people have a thing for arcane programming (for a lack of better word), but in my opinion it just makes code harder to write, understand, and even statically analyse.
Not to mention, the official lining for hooks leaves a lot to be desired for, especially because some internal React return values are treated magically by the linter (useState, useReducer to name a few) when it comes to hook dependency management.
I came across this problem the other day:
https://stackoverflow.com/questions/53332321/react-hook-warn...
I love React and my first experience with hooks has been mostly positive, but how is it that something as simple as data fetching is not completely sorted out by now?
It sounds abhorrent!
https://stackoverflow.com/questions/53332321/react-hook-warn...
I love React and my first experience with hooks has been mostly positive, but how is it that something as simple as data fetching is not completely sorted out by now?
It sounds abhorrent!
For a deep dive:
https://dev.to/n1ru4l/homebrew-react-hooks-useasynceffect-or...
I think the current best answer is https://github.com/n1ru4l/use-async-effect
But as noted by your SO question, Suspense for data fetching is what we're waiting for. It was originally scheduled to be released the middle of this year but was delayed. https://reactjs.org/blog/2019/08/08/react-v16.9.0.html#an-up...
I think the current best answer is https://github.com/n1ru4l/use-async-effect
But as noted by your SO question, Suspense for data fetching is what we're waiting for. It was originally scheduled to be released the middle of this year but was delayed. https://reactjs.org/blog/2019/08/08/react-v16.9.0.html#an-up...
I'd say for 95% of data fetches https://github.com/slorber/react-async-hook works really well without needing generator syntax or explicit promise cancellation boilerplate. I'm not the author but a satisfied user.
I don't think React is really competing with Vue as much anymore. Solving the problems of a virtual DOM in a better way is a minor improvement compared to not having a virtual DOM at all. The older virtual DOM frameworks are competing with Svelte.
I wouldn't argue that hooks is a simpler programming model, except perhaps under the hood. The Hooks API is not intuitive. I'm sure once you get a hang of it it's not hard, but as a Vue developer reading Hooks code it's not very clear.
While there was some backlash to the initial Hooks-inspired style in Vue, they went back to the drawing board and came up with a better way to explain it to the community that has gotten a much better response. I also find Vue's API for "hooks" much more intuitive/readable than React hooks, because it maps pretty well to the old style of writing code.
While there was some backlash to the initial Hooks-inspired style in Vue, they went back to the drawing board and came up with a better way to explain it to the community that has gotten a much better response. I also find Vue's API for "hooks" much more intuitive/readable than React hooks, because it maps pretty well to the old style of writing code.
I have trained a dozen or so developers on React and for less experienced developers, hooks are much more intuitive because they don't rely on an abstract understanding of arbitrary lifecycle identifiers, instead, hooks are explicitly executed in application code that is logically accessible to the programmer.
I have a hard time seeing how lifecycle identifiers could be called "arbitrary" except perhaps (again) from an "under the hood" viewpoint. From an API standpoint they are explicit and extremely simple.
I don't have anything against hooks except the API. There is no way for someone who isn't intimate with the ecosystem to understand the difference between these:
I don't have anything against hooks except the API. There is no way for someone who isn't intimate with the ecosystem to understand the difference between these:
useEffect(() => {
document.title = foo;
}, [foo]);
useEffect(() => {
document.title = foo;
});
useEffect(() => {
document.title = foo;
}, []);
>> Why would anyone keep creating cool new frameworks?
That’s a weird question because the answer is so obvious. There’s massive innovation in front end development because billlions of users are using ever more sophisticated applications created by millions of programmers backed by virtually infinite money. Of course people keep looking for and finding better ways to do things. Do you think that process has come to an end?
You must be trolling.
That’s a weird question because the answer is so obvious. There’s massive innovation in front end development because billlions of users are using ever more sophisticated applications created by millions of programmers backed by virtually infinite money. Of course people keep looking for and finding better ways to do things. Do you think that process has come to an end?
You must be trolling.
See, all the innovations are about code management and tracking. There has been nothing new for users for many years. In 2004 Gmail made AJAX popular and updating pages without reloading was a big deal. Later we had rounded corners, video without the Adobe Flash player, then came the websites that fit the screen size(the responsive web stuff) and later, we got some WebSocket stuff making possible real-time communications even snappier than AJAX.
That said, this is 15 years of time and the innovations came as browsers got better, IE died off but all these JS frameworks were always about making the codebase nicer.
Is there anything new for the users here? If not, why keep spawning new frameworks? Do these frameworks make anything better for the developers? In my experience, the JS world is a giant mess mostly because of the excess of frameworks that do the same things essentially.
That's why I felt burned out of web dev. I found out that all these frameworks that are supposed to make something easier to do are only making problems infinitely complex.
There's nothing new that you couldn't have done with 10 years old frameworks but now you need specialized knowledge on tons of tools.
That said, this is 15 years of time and the innovations came as browsers got better, IE died off but all these JS frameworks were always about making the codebase nicer.
Is there anything new for the users here? If not, why keep spawning new frameworks? Do these frameworks make anything better for the developers? In my experience, the JS world is a giant mess mostly because of the excess of frameworks that do the same things essentially.
That's why I felt burned out of web dev. I found out that all these frameworks that are supposed to make something easier to do are only making problems infinitely complex.
There's nothing new that you couldn't have done with 10 years old frameworks but now you need specialized knowledge on tons of tools.
The reason there are so many frameworks for UI out there is probably due to the same response you are having.
People doing a lot of web development wanted to make their lives easier but found the way other frameworks are doing it to be really convoluted. So they created their own framework which makes perfect sense to them.
As a developer getting into this, just pick any well-maintained framework and you should be able to get your job done.
People doing a lot of web development wanted to make their lives easier but found the way other frameworks are doing it to be really convoluted. So they created their own framework which makes perfect sense to them.
As a developer getting into this, just pick any well-maintained framework and you should be able to get your job done.
> There’s massive innovation in front end development because billions of users are using ever more sophisticated applications created by millions of programmers backed by virtually infinite money.
There's no real innovation on the web. As another commenter pointed out, all the "innovation" is around tools. And even those innovations are meh at best.
Web has been busy reinventing things that desktop programming has had probably for decades, and what mobile development has had for years. And that's when we consider tools only.
On the app/client side the situation is even more bleak and dire. We get a 100th store implementation. A 1000th drag and drop implementation. A 10000th file upload manager. A 100000th state manager. A...
The "ever more sophisticated" applications can barely scratch the surface of native apps. And the actual more sophisticated apps like Figma are busy re-inventing and re-building the past 20 years of desktop UIs from scratch [1].
It's not innovation. It's a hamster wheel race.
[1] https://www.figma.com/blog/building-a-professional-design-to...
--- quote ---
Pulling this off was really hard; we’ve basically ended up building a browser inside a browser.
The reason this is hard is because the web wasn’t designed as a general-purpose computing platform.
--- end quote ---
There's no real innovation on the web. As another commenter pointed out, all the "innovation" is around tools. And even those innovations are meh at best.
Web has been busy reinventing things that desktop programming has had probably for decades, and what mobile development has had for years. And that's when we consider tools only.
On the app/client side the situation is even more bleak and dire. We get a 100th store implementation. A 1000th drag and drop implementation. A 10000th file upload manager. A 100000th state manager. A...
The "ever more sophisticated" applications can barely scratch the surface of native apps. And the actual more sophisticated apps like Figma are busy re-inventing and re-building the past 20 years of desktop UIs from scratch [1].
It's not innovation. It's a hamster wheel race.
[1] https://www.figma.com/blog/building-a-professional-design-to...
--- quote ---
Pulling this off was really hard; we’ve basically ended up building a browser inside a browser.
The reason this is hard is because the web wasn’t designed as a general-purpose computing platform.
--- end quote ---
I thought it was a fair question.
For people not expert or completely current in web development - especially in the context of a field not unknown for jumping on every shiny new magic bullet - it's quite reasonable to ask what major problems are arising that need a new framework learning every week.
For people not expert or completely current in web development - especially in the context of a field not unknown for jumping on every shiny new magic bullet - it's quite reasonable to ask what major problems are arising that need a new framework learning every week.
> it's quite reasonable to ask what major problems are arising that need a new framework learning every week
The answer is simple: someone read a new chapter in the Gang of Four's book.
The answer is simple: someone read a new chapter in the Gang of Four's book.
Sure people come up with interesting business ideas all the time but they usually don't require innovative Web UI tech and can be built just fine with 10-year-old frameworks.
That depends on your definition of 'just fine'. I can develop a lot faster with fewer bugs today using React than I did using jQuery a decade ago. That means the apps I build cost less (or more commonly my clients get more functionality for their money). They seem think that's a really big improvement.
That depends on your definition of 'just fine'. I can develop a lot faster with fewer bugs today using React than I did using jQuery a decade ago. That means the apps I build cost less (or more commonly my clients get more functionality for their money). They seem think that's a really big improvement.
Of all the things I've heard over the years no one has ever said jquery created more bugs than react that's why I switched. Or that it was faster to develop.
Slower, bundling sizes, hard to maintain, doesn't manage state, complexity is messy but never few bugs or slower to work with or different to understand.
Slower, bundling sizes, hard to maintain, doesn't manage state, complexity is messy but never few bugs or slower to work with or different to understand.
Of all the things I've heard over the years no one has ever said jquery created more bugs than react that's why I switched. Or that it was faster to develop.
I didn't say jQuery created more bugs. I said I write jQuery code that has more bugs. It's not jQuery's fault at all. What it means is that the way I work is better suited to writing things with React because React is closer to the way I think.
I didn't say jQuery created more bugs. I said I write jQuery code that has more bugs. It's not jQuery's fault at all. What it means is that the way I work is better suited to writing things with React because React is closer to the way I think.
All of those things are intimately connected.
If jQuery were just as fast to work with and had the same bug count, it wouldn't be harder to maintain. It takes time to work out what jQuery code is doing which means it takes longer to modify the code. That difference in readability also leads to a higher chance of bugs due to misunderstanding something.
The one case where this does not hold true is when your site only needs a few click handlers or something else that is simple (and in those cases, you should probably be using jQuery -- or just the normal DOM now that compatibility is less of an issue). But that is not what modern JS app devs deal with.
The entire reason for using Handlebars on top of jQuery was to move toward declarative programming in order to reduce bugs and speed up development time. React was more declarative, functional, and native (use JS builtins instead of embedding a turing-complete DSL) along with also being massively faster. React was marketed more on performance than anything else at first, but that was mostly because Handlebars and backbone had already solved the worst parts of jQuery in large codebases -- procedural UI and holding state in the DOM.
If jQuery were just as fast to work with and had the same bug count, it wouldn't be harder to maintain. It takes time to work out what jQuery code is doing which means it takes longer to modify the code. That difference in readability also leads to a higher chance of bugs due to misunderstanding something.
The one case where this does not hold true is when your site only needs a few click handlers or something else that is simple (and in those cases, you should probably be using jQuery -- or just the normal DOM now that compatibility is less of an issue). But that is not what modern JS app devs deal with.
The entire reason for using Handlebars on top of jQuery was to move toward declarative programming in order to reduce bugs and speed up development time. React was more declarative, functional, and native (use JS builtins instead of embedding a turing-complete DSL) along with also being massively faster. React was marketed more on performance than anything else at first, but that was mostly because Handlebars and backbone had already solved the worst parts of jQuery in large codebases -- procedural UI and holding state in the DOM.
> is surpassed by VueJS
The web world is the wild west (and I kinda like it) but I don't think we're even close to React being surpassed by Vue.
There was a lot of talk about stars on github for Vue but I'm not sure people star what they work with every day, or at least that it means much relative to other projects.
The web world is the wild west (and I kinda like it) but I don't think we're even close to React being surpassed by Vue.
There was a lot of talk about stars on github for Vue but I'm not sure people star what they work with every day, or at least that it means much relative to other projects.
For performance and to improve the development workflow.
WebAssembly looks amazing. Much faster web applications. Then you have stuff like Hudini which will let you create custom DOM elements and allow open source web frameworks to provide really sane DOM element offerings.
WebAssembly has the largest potential. Just look at Microsofts Blazor project. If you do any .NET Blazor looks even more amazing! Then Microsoft also has React Native for Windows.
WebAssembly looks amazing. Much faster web applications. Then you have stuff like Hudini which will let you create custom DOM elements and allow open source web frameworks to provide really sane DOM element offerings.
WebAssembly has the largest potential. Just look at Microsofts Blazor project. If you do any .NET Blazor looks even more amazing! Then Microsoft also has React Native for Windows.
> For performance and to improve the development workflow.
If it's for performance, the community as a whole seems to have failed entirely. Svelte looks like an exception, sure, but websites generally use more CPU time, more RAM, more bandwidth than they did 10 years ago even when they don't do anything significantly different, functionally.
If it's for performance, the community as a whole seems to have failed entirely. Svelte looks like an exception, sure, but websites generally use more CPU time, more RAM, more bandwidth than they did 10 years ago even when they don't do anything significantly different, functionally.
I was looking for a multiselect autocomplete component the other day. The only useful I found was from SemanticUI, and it's not quite configurable enough. I'll have to roll out my own...
Because we want to achieve the same thing while writing less code. Because browsers advance and new APIs become available everyday. Because we now write web apps in places where there were no browsers before, like smart TVs, smart watches, etc.
> ReactJS is surpassed by VueJS
Is it though?
- react weekly downloads 5,672,972
- vue weekly downloads 1,090,292
Is it though?
- react weekly downloads 5,672,972
- vue weekly downloads 1,090,292
I recently started a project using svelte and the difference from React and Vue is so drastic for me that it isn't even funny!
Now, I know how opinionated we all are and how the best thing is what we already know, but after working with Vue and React extensively (the company I currently work for uses Vue/TS for a huge app, think over 1000+ .vue files) the particularity about svelte is that you hardly notice that you are using it!
Vue has the Vue way and React has prophet Abramov to light the way, but svelte is completely out of your way. You wanna follow MVC? go ahead, DDD? why not?
I have learned more HTML5 and CSS3 using svelte than any of the other frameworks because it encourages you to use it, because the wheel has been invented already.
Again, everybody has their opinion but for me svelte is the framework that has the least magic of all, the you can set it up without a incredibly complicated webpack config or obscure 'create-react-app' that makes it very easy to start a project but you don't really know what's happening underneath.
And it just HTML and probably 5 or 6 extra JS things like $: and a different use for export in a component.
If you are already religious about your framework, good for you, but if you are open to ideas, take a look a svelte!
Now, I know how opinionated we all are and how the best thing is what we already know, but after working with Vue and React extensively (the company I currently work for uses Vue/TS for a huge app, think over 1000+ .vue files) the particularity about svelte is that you hardly notice that you are using it!
Vue has the Vue way and React has prophet Abramov to light the way, but svelte is completely out of your way. You wanna follow MVC? go ahead, DDD? why not?
I have learned more HTML5 and CSS3 using svelte than any of the other frameworks because it encourages you to use it, because the wheel has been invented already.
Again, everybody has their opinion but for me svelte is the framework that has the least magic of all, the you can set it up without a incredibly complicated webpack config or obscure 'create-react-app' that makes it very easy to start a project but you don't really know what's happening underneath.
And it just HTML and probably 5 or 6 extra JS things like $: and a different use for export in a component.
If you are already religious about your framework, good for you, but if you are open to ideas, take a look a svelte!
How does svelte get "completely out of your way" when you have to learn its non-standard, framework-specific idioms? bind:value, #each, :catch, #await, x as y, $ prefix, slots, use: ... these all seem like reimplementations of plain JavaScript.
If you're going to go this far, why not use Marko.js and get SSR streaming built in?
If you're going to go this far, why not use Marko.js and get SSR streaming built in?
You make good points but your comment doesnt appeal to me that much. I dont really care about React adding hidden boilerplate for me, as long as it is efficient enough and enables me to work on more productive things. Svelte sounds good, dont get me wrong but the abstractions are there for a reason. We as humans want to minimize complexity and mental overhead having to figure every best practise on our own. Enabling developers to do whatever they want with a framework sounds frankly like a bad idea.
But if svelte can do both, eliminate the boilerplate and at the same time minimize the cognitive burden of having to work with DOM, then im interested. But i rarely have noticed that React makes me angry the way it used to. So do i want to switch, like the stereotypical frontend hipster, to another hype framework and code the next customer app with it? I'll need a lot more convincing first
But if svelte can do both, eliminate the boilerplate and at the same time minimize the cognitive burden of having to work with DOM, then im interested. But i rarely have noticed that React makes me angry the way it used to. So do i want to switch, like the stereotypical frontend hipster, to another hype framework and code the next customer app with it? I'll need a lot more convincing first
"I have learned more HTML5 and CSS3 using svelte than any of the other frameworks because it encourages you to use it, because the wheel has been invented already."
This really doesn't make any sense. Not learning how to effectively use HTML and CSS doesn't have anything to do with what frontend framework you're using.
This really doesn't make any sense. Not learning how to effectively use HTML and CSS doesn't have anything to do with what frontend framework you're using.
The svelte examples kept me interested until I reached the logic section [0]. Coming from JSX/TSX svelte's template language is a huge downer for me.
https://svelte.dev/examples#if-blocks
https://svelte.dev/examples#if-blocks
If you really want something that will get of your way, use Web Components. They're a web standard, after all.
I read an article about them recently. I love the idea of an standard but it feels so "committee design" with a lot of good ideas but completely throwing out the window simplicity.
The older I get as a developer the more I realize that simple is not easy to accomplish. That's probably why I like svelte :)
The older I get as a developer the more I realize that simple is not easy to accomplish. That's probably why I like svelte :)
Svelte has an option to output Web Components, so it might be a good option if you want to use them while still writing your code in a React-y "declarative UI" style.
Did not know this. That's a game changer for me in considering Svelte, thanks.
React, Vue and Svelte solve 2 big problems.
1. components (creating re-usable UI parts (i.e. components) that combine data and their rendering)
2. reactivity - re-rendering UI when data changes.
Web Components only solve one of those problems. And arguably not as well.
1. components (creating re-usable UI parts (i.e. components) that combine data and their rendering)
2. reactivity - re-rendering UI when data changes.
Web Components only solve one of those problems. And arguably not as well.
Web components are a great idea, but the current implementation sucks and is a pain to use though. Web components should look like what Svelte did!
> Svelte has not yet received the attention it deserves. When it is mentioned, the focus is typically on its ability to produce bundled code that is significantly smaller than the alternatives. However, Svelte makes many tasks easier, including defining components, managing component state, managing application state, and adding animation.
Under the "Why Consider Svelte?" it only mentions bundle size and performance.
Under the "Why Consider Svelte?" it only mentions bundle size and performance.
The way I see Svelte is as a one-stop-shop type of framework (similar to Angular and Ember in philosophy), but exclusively for client-side concerns, and aggressively geared towards leveraging standard web idioms (HTML that looks like HTML, CSS that looks like CSS, JS that looks like JS), whereas most competing frameworks extend grammars in various non-standard ways (Angular's "HTML" isn't parseable via a standard HTML parser, and React's "JS" requires a parser that supports JSX - and then there's the whole CSS-in-JS thing where people get tripped up by double quoting and camel casing rules). Said frameworks typically also have steeper learning curves due to framework-specific APIs.
Where I think Svelte falls a bit short (given its flavor of comprehensiveness) is that while it concerns itself with strictly client-side things like in-memory state and animations, it offers nothing for sorta-server-related things like data fetching or routing, and you're left to find libraries to fill the gaps (similar to how you would in React). I feel like the bigger frameworks are up to something DX-wise, with providing more integrated/idiomatic ways of interfacing between subsystems (e.g. getting a data fetching API to talk to a state store, or making routing aware of them). Gluing subsystems from different libraries adds weight to application space code (see e.g. react-redux vs Vue) and at some point this starts mattering (usually during maintenance phase). Maybe Svelte's middle ground is your cup of tea, but obviously YMMV a lot.
Where I think Svelte falls a bit short (given its flavor of comprehensiveness) is that while it concerns itself with strictly client-side things like in-memory state and animations, it offers nothing for sorta-server-related things like data fetching or routing, and you're left to find libraries to fill the gaps (similar to how you would in React). I feel like the bigger frameworks are up to something DX-wise, with providing more integrated/idiomatic ways of interfacing between subsystems (e.g. getting a data fetching API to talk to a state store, or making routing aware of them). Gluing subsystems from different libraries adds weight to application space code (see e.g. react-redux vs Vue) and at some point this starts mattering (usually during maintenance phase). Maybe Svelte's middle ground is your cup of tea, but obviously YMMV a lot.
> it offers nothing for sorta-server-related things like data fetching
The obvious advantage of not including these kinds of things in the library is that it makes less assumptions about the data and communication model. Maybe my data source is a Websocket, a REST API, a GraphQL API, or some Electron IPC messages. Ideally, in my view, the rendering library doesn't care. It shouldn't have to understand all these things to render my view, and it definitely shouldn't assume any single one or two of them.
The obvious advantage of not including these kinds of things in the library is that it makes less assumptions about the data and communication model. Maybe my data source is a Websocket, a REST API, a GraphQL API, or some Electron IPC messages. Ideally, in my view, the rendering library doesn't care. It shouldn't have to understand all these things to render my view, and it definitely shouldn't assume any single one or two of them.
You’re the guy who came up with mithril.js? If I recognize the username anyway.
Do you think mithril will solve these issues or is a good alternative?
Do you think mithril will solve these issues or is a good alternative?
Yes, I created Mithril. I also co-authored Fusion.js[1], which - in contrast - is about as "big boy" as a framework gets (and mostly works w/ the React ecosystem, if you're curious). We use the latter at over 100 projects at Uber.
Mithril fits in a similar camp as Svelte, and it does offer APIs for HTTP requests and routing out of the box. I've worked on projects before where I literally only had Mithril as a sole dependency (and this was with supporting IE10).
Fusion.js solves a lot of complexity-at-scale problems but it does so at a trade-off of not being nearly as geared towards standards tracking as systems like Svelte and Mithril.
[1] https://fusionjs.com/
Mithril fits in a similar camp as Svelte, and it does offer APIs for HTTP requests and routing out of the box. I've worked on projects before where I literally only had Mithril as a sole dependency (and this was with supporting IE10).
Fusion.js solves a lot of complexity-at-scale problems but it does so at a trade-off of not being nearly as geared towards standards tracking as systems like Svelte and Mithril.
[1] https://fusionjs.com/
I'm not Leo, but I'll give my own opinion.
Mithril solves all those issues well except animations, where it's just OK.
Interestingly, even though the Mithril community seems to be a home to people who dislike JSX, Mithril supports it better than React does. You can copy and paste HTML into JSX with Mithril; all the attributes line up. Also Mithril doesn't try to improve elements like <select> and <textarea>; it's all standard.
In personal projects I use Mithril. For medium to large organizations I recommend React. That's because Mithril does everything better than React except for maintaining backward compatibility and attracting large numbers of job candidates.
Mithril solves all those issues well except animations, where it's just OK.
Interestingly, even though the Mithril community seems to be a home to people who dislike JSX, Mithril supports it better than React does. You can copy and paste HTML into JSX with Mithril; all the attributes line up. Also Mithril doesn't try to improve elements like <select> and <textarea>; it's all standard.
In personal projects I use Mithril. For medium to large organizations I recommend React. That's because Mithril does everything better than React except for maintaining backward compatibility and attracting large numbers of job candidates.
Have you looked at the Sapper project? I think it adds a lot of what you are looking for. It’s basically a next.js equivalent.
Superficially. It does feel very much like Next.js, but I feel that direction sort of misses the mark, especially coming from a try-to-be-as-transparent-as-possible angle. There's still no opinionated way of doing data fetching (meaning one is free to shoot themselves in the foot trying to chase trends) and for doing non-trivial server-side things, you're basically dealing w/ raw req/res, which tends to devolve into an unstructured mess if the framework doesn't provide guidance (which neither Next nor Sapper do IMO).
For me personally, it has one other showstopper (its file naming convention is not compatible w/ Bazel)
For me personally, it has one other showstopper (its file naming convention is not compatible w/ Bazel)
Do you need a framework to handle data fetching? We have `fetch()` after all so I'm honestly curious why you wouldn't just use it
"Needing" is relative. I could make an app making nothing but raw XMLHttpRequest calls, but that only speaks to the capability of talking to a server. In that sense, sure `fetch` is "enough". But from a perspective of a complex application or a complex org, you may want specific properties to be true: for example, you may want that a request to a certain endpoint follows a predetermined schema, or that one can control the granularity of the response data, or maybe you want to abstract over things like streaming, retries or caching to name a few things.
Something that most frameworks struggle with, IMHO, is that they don't consider how coupled network is to the system and when you need to do something like bundle-specific translations in an SSR context, it's very hard to do it in a generic way without touching half a dozen unrelated parts of an app (meaning librarizing concerns that cross-cut across network boundaries is difficult).
Something that most frameworks struggle with, IMHO, is that they don't consider how coupled network is to the system and when you need to do something like bundle-specific translations in an SSR context, it's very hard to do it in a generic way without touching half a dozen unrelated parts of an app (meaning librarizing concerns that cross-cut across network boundaries is difficult).
Not true. That section mentions several other "Whys" including this: "Svelte dramatically simplifies component and application state management. Contributing features include context, stores, and module context, each of which is covered in detail later."
Which is perfectly fine
It is not, I can already do that directly with the DOM. It's a huge asset, but not enough. Ease of use, development velocity or something along these lines should be mentioned.
For me, that's icing on the cake. Why I truly like and recommend Svelte is its ergonomics. Paired with Sapper, building a fast website is a breeze and feels like you're just writing plain HTML and (supercharged) JS.
Cool, but how does it help me reason about my code and maintain large projects? It doesn't even support typescript.
Sure, the components look okay in isolation, but what about the big picture?
It doesn't and it won't. Advocates for Svelte seem to prefer it over the complicated (I do not agree) React patterns. Those patterns are there for a reason and help the code stay maintainable and predictable. Not supporting TypeScript is also a big blow.
Small projects / websites = use the DOM
SPAs = use React
Why would you use Svelte for small websites when it requires JS?
All of my "websites" are made w/ pure HTML/CSS/JS and the JS is optional.
All of my "apps" are made w/ React (Web, Electron) & React Native (Windows, iOS, Android)
I'm working on a stack that sets all this up for you so you can get started on deploying for every platform. I already use it in production.
Don't cheat yourself, use React and take advantage of the progress and ecosystem. If you don't need that, then use vanilla.
Small projects / websites = use the DOM
SPAs = use React
Why would you use Svelte for small websites when it requires JS?
All of my "websites" are made w/ pure HTML/CSS/JS and the JS is optional.
All of my "apps" are made w/ React (Web, Electron) & React Native (Windows, iOS, Android)
I'm working on a stack that sets all this up for you so you can get started on deploying for every platform. I already use it in production.
Don't cheat yourself, use React and take advantage of the progress and ecosystem. If you don't need that, then use vanilla.
What patterns are you talking about? Nothing specific to React, as far as I know, helps with maintaining a large codebase.
Though, perhaps you mean the larger React ecosystem. But still, what patterns are you talking about? TEA/Redux? There's no reason why you can't use the same patterns with Svelte.
Though, perhaps you mean the larger React ecosystem. But still, what patterns are you talking about? TEA/Redux? There's no reason why you can't use the same patterns with Svelte.
React doesn't have some intricate patterns. It mostly advocates for a functional-style UI, where you do computation in the render cycle and keep state localized to a component.
Svelte gives you the exact same tools. I've been building React-based applications for years now and have been using Svelte for some projects on the side and in my opinion both are decent tools. Some of the Svelte "sugar" is easily replicated in React, it's just that React doesn't provide those out of the box; on the other hand, Svelte has some "gotchas" that don't appear in React.
Svelte gives you the exact same tools. I've been building React-based applications for years now and have been using Svelte for some projects on the side and in my opinion both are decent tools. Some of the Svelte "sugar" is easily replicated in React, it's just that React doesn't provide those out of the box; on the other hand, Svelte has some "gotchas" that don't appear in React.
> typescript
I hear that this is something they are looking into adding support for
I hear that this is something they are looking into adding support for
Here is the issue that describes what the Svelte team is doing to add support for TypeScript: https://github.com/sveltejs/svelte/issues/1639
It's perfectly fine if your most pressing issue with large bundle sizes/slow performance.
If your most pressing issue is removing bugs from managing state, you will pass it by.
If your most pressing issue is removing bugs from managing state, you will pass it by.
If your most pressing issue is making managing state easier, you should run to Svelte! Take a look at how Svelte supports "stores", "context", and state within a component. Those are so good that I predict nobody will ever feel the need to write a state management library for Svelte. It's already very easy!
Right, and if your pressing issue is large bundle sizes/slow performance, you'd probably be using Preact.
I'm a primarily React-based developer, but have taken to using Svelte on side projects. Don't get me wrong, I still like React, but Svelte is phenomenally easy to get started and wrap your head around. I've started suggesting it instead of React to people looking to learn front-end JS.
I read the main article which took some time to reach the conclusion a small footprint was the main point.
So I googled, found the Svelte homepage, and I'm still none the wiser as to why it might be an easy intro to web development.
Honestly, if Svelte is as easy as you suggest to get your head around, somebody needs to work on the presentation of that.
So I googled, found the Svelte homepage, and I'm still none the wiser as to why it might be an easy intro to web development.
Honestly, if Svelte is as easy as you suggest to get your head around, somebody needs to work on the presentation of that.
I feel like like saying svelte is an "easy intro to web development" is misleading. The svelte compiler "abuses" (I don't mean it in a bad way) existing technology so it doesn't have to create special tooling and works with existing tools. I think that's okay _only if_ you're aware of this as a developer.
If I was hiring a JS dev, and someone _only_ had svelte on their CV, I'd be a bit reluctant to hire them, only because the svelte compiler hides a lot of JS warts (which I think people should be aware of).
If I was hiring a JS dev, and someone _only_ had svelte on their CV, I'd be a bit reluctant to hire them, only because the svelte compiler hides a lot of JS warts (which I think people should be aware of).
Genuine question: where does the svelte complier hide JS warts? I've used Svelte for some production tools and personally in a few projects.
My experience thus far is that if you don't have at least a base-level understanding of JS you really can't use Svelte to its fullest. I can back up that intuition by having observed the svelte support channel on discord, where many of the questions really wind up being questions about javascript rather than Svelte.
My experience thus far is that if you don't have at least a base-level understanding of JS you really can't use Svelte to its fullest. I can back up that intuition by having observed the svelte support channel on discord, where many of the questions really wind up being questions about javascript rather than Svelte.
I've been working with Vue for front end, but always keeping my eyes open to the future.
What do you feel Svelte is doing that hides "warts"?
Hacky stuff tends to turn me off from a tech. (I consider all my Vue work to be instant tech debt, because I know I will be replacing it down the road...)
What do you feel Svelte is doing that hides "warts"?
Hacky stuff tends to turn me off from a tech. (I consider all my Vue work to be instant tech debt, because I know I will be replacing it down the road...)
If you are referring to my article, "small footprint" is not the main point for me. The main point is ease development due to features like easier component state management, app state management with stores and sharing data between components with context.
To be fair to you I clicked on the article expecting a summary review rather than a technical run through and got as far as Why Consider Svelte on my small phone screen before googling. I can see on a revisit on my tablet it is rather more comprehensive.
Did you walk through the tutorial? It's _easy_. And the tutorial is kept almost 100% up to date with svelte version changes.
No, tbh by the time I got there I had lost interest. I'm not commenting on the value of Svelte, just saying I felt the benefits of investing time in investigating it in the context of a myriad of established tools and frameworks needed to be more clearly sold.
Agreed. Lots of praise, no explanation.
Svelte is:
- smaller (it compiles your app, and doesn't include itself in the results)
- faster (no virtual DOM, the data to elements are mapped at compile time)
- simpler - `age = 30` no boring state management.
You're right about the web page - I wanted them to drop 'Cybernetically enhanced web apps' for 'smaller faster simpler' - there was a GitHub issue for it: https://github.com/sveltejs/svelte/issues/3269
- smaller (it compiles your app, and doesn't include itself in the results)
- faster (no virtual DOM, the data to elements are mapped at compile time)
- simpler - `age = 30` no boring state management.
You're right about the web page - I wanted them to drop 'Cybernetically enhanced web apps' for 'smaller faster simpler' - there was a GitHub issue for it: https://github.com/sveltejs/svelte/issues/3269
How long did it take to get semi comfy with Svelte (from recent React background)?
For me, it didn't take long. I was initially confused by some "repurposed" syntax in svelte, and kinda felt negatively about it, but I grew to accept it, and even appreciate it (it's a hack, but on the elegant side). There's quite a bit of "repurposing" going on (probably so svelte can work with existing linters and other tooling), but you get used to it.
Svelte has more often "magic" stuff, but the good thing is the magic is simple, and it easy to understand (especially since you can easily look at the compiled output, if you want to double check)
Svelte has more often "magic" stuff, but the good thing is the magic is simple, and it easy to understand (especially since you can easily look at the compiled output, if you want to double check)
I _left_ Svelte because it was headed in a direction I didn't believe in (all the repurposed syntax). But I gave it a try and had to apologize for disappearing. It is extremely well executed.
One of the primary directives in Svelte is that it all has to be valid HTML so that the tooling can simply treat Svelte like HTML for syntax highlighting. Some of the repurposing is explicitly because of that directive.
One of the primary directives in Svelte is that it all has to be valid HTML so that the tooling can simply treat Svelte like HTML for syntax highlighting. Some of the repurposing is explicitly because of that directive.
I felt the same way when I discovered Vue after a long time using React.
How is it different and what’s so good about it?
The main draw is that Svelte apps have no dependencies at runtime, instead it compiles a pure vanilla js bundle that relies on existing web APIs to do updates. This is attractive to a lot of people, me included, but imo Svelte isn’t quite production ready yet (at least for complex apps). It’s great for small projects though and I highly recommend checking it out
From what I know it's a compiler, so it check all the things at compile time and not waste time at run time.
That's partially true. The other benefit is that there's no vDOM, the way things change is reactive (kinda like in react), but there's no such thing as a no-op change. if you set something to what it was, it would trigger a partial rerender so you have to check before setting. With react you get those checks for free (provided you comply to certain restrictions).
Are you using Svelte for SPAs? If so, what are you using for routing?
I use Svelte with Sapper, which takes care of routing for me. From the FAQ:
> Is there a router?
> You can use any router lib you want. A lot of people use page.js. There's also navaid, which is very similar. If you prefer a declarative HTML approach, there's svero and svelte-routing.
> If you need hash-based routing on the client side, check out svelte-spa-router, or abstract-state-router, a mature router for business software.
> For an official solution, there's nothing that's simply a routing library. There is, however, the official Sapper framework, a Next.js-style application framework built on Svelte, which includes its own filesystem-based routing.
> Is there a router?
> You can use any router lib you want. A lot of people use page.js. There's also navaid, which is very similar. If you prefer a declarative HTML approach, there's svero and svelte-routing.
> If you need hash-based routing on the client side, check out svelte-spa-router, or abstract-state-router, a mature router for business software.
> For an official solution, there's nothing that's simply a routing library. There is, however, the official Sapper framework, a Next.js-style application framework built on Svelte, which includes its own filesystem-based routing.
I use Svero. Sapper is alpha and still in flux - I'll check out Sapper again once it's stable though.
I'm migrating one of my sites from jQuery (+ server-generated HTML) to Svelte. I like how Svelte+rollup make it easy to replace just a part of a website (take HTML from a file, put it into Foo.svelte, back in the original file insert <script>new App.Foo({target: document.body, props: { /* data */ }})</script> [0]). Instead of generating HTML, server-side scripts now generate JSON, which could be used later to make a proper API.
I don't like handling of "undefined" and "null" values in properties[1]. It would also be nice to have optional properties so that warnings wouldn't get emitted to JS console. Also, someone should investigate iOS bugs[2]. It would be bad if someone made complex site in Svelte+Sapper and only later discovered it lags on iOS.
Overall performance is okay, but it's visible to a naked eye that Svelte parts render later than the rest of the website.
All in all, I would recommend giving Svelte devs few more months before moving to it. But definitely keep an eye on it, it has great ergonomics (maybe except for styling subcomponents, but some say it's a code smell anyway).
[0] assuming you set output { format: "iife", name: "App" } in rollup.config.js, imported bundle.js in the original file, and put export { Foo } in main.js
[1] https://svelte.dev/repl/f1f2bf4c50cf4a75ba6ea38c3390af5b?ver...
[2] https://github.com/sveltejs/svelte/issues/3581
I don't like handling of "undefined" and "null" values in properties[1]. It would also be nice to have optional properties so that warnings wouldn't get emitted to JS console. Also, someone should investigate iOS bugs[2]. It would be bad if someone made complex site in Svelte+Sapper and only later discovered it lags on iOS.
Overall performance is okay, but it's visible to a naked eye that Svelte parts render later than the rest of the website.
All in all, I would recommend giving Svelte devs few more months before moving to it. But definitely keep an eye on it, it has great ergonomics (maybe except for styling subcomponents, but some say it's a code smell anyway).
[0] assuming you set output { format: "iife", name: "App" } in rollup.config.js, imported bundle.js in the original file, and put export { Foo } in main.js
[1] https://svelte.dev/repl/f1f2bf4c50cf4a75ba6ea38c3390af5b?ver...
[2] https://github.com/sveltejs/svelte/issues/3581
I couldn't actually figure out what you were trying to do here, but there are a few points I do understand, and can answer:
1. If you want to bind a property it needs to be declared. This is the method of least surprise.
2. I've been running three Svelte sites in production for more than a year now, and 80% of our traffic is iOS. The sites work fine, it's the tutorials specifically, probably because of the embedded REPLs which have an iOS issue.
3. You claim that the Svelte code runs later than the server-generated HTML. This makes sense, since the DOM from Svelte components is built using Javascript. If you wanted to generate Svelte code on the server-side so that it renders at the same time, you would use { ssr: true } in your rollup config and generate code for both server and client side.
4. Not sure what the notion of lag is or where it comes from, Svelte outperforms everything else (when I last checked benchmarks), and is likely to, since it has the immediate advantage of not requiring a client-side runtime to download before it starts execution.
1. If you want to bind a property it needs to be declared. This is the method of least surprise.
2. I've been running three Svelte sites in production for more than a year now, and 80% of our traffic is iOS. The sites work fine, it's the tutorials specifically, probably because of the embedded REPLs which have an iOS issue.
3. You claim that the Svelte code runs later than the server-generated HTML. This makes sense, since the DOM from Svelte components is built using Javascript. If you wanted to generate Svelte code on the server-side so that it renders at the same time, you would use { ssr: true } in your rollup config and generate code for both server and client side.
4. Not sure what the notion of lag is or where it comes from, Svelte outperforms everything else (when I last checked benchmarks), and is likely to, since it has the immediate advantage of not requiring a client-side runtime to download before it starts execution.
Thanks for replying. In my previous post, I just wanted to share my experience as someone who has used Svelte (for few days, though, nowhere close to how much you have).
1. I just missed the part of documentation that talks about optional properties. And with undefined and null issue, it's a bit surprising that two-way bindings behave differently that 1-way. Passing null or undefined is convenient when an API gives you such values and they represent empty there.
2. Ok. What I feared is that the tutorial would turn out not to be bugged, and Svelte would be a bad choice for CPU-intensive SPAs. Thanks for reassuring me that's not the case. I'd still love to see the fix for the tutorial bug (because at the first glance, there isn't anything that screams "wrong!" in its code).
3. Yup. I just wanted to point out it's noticeable if you look for it. I will look into SSR later.
4. Same as in point 2.
BTW I just wasted 2 hours fighting with bind:group[0][1]. This issue is an example of what I meant by saying that people may want to wait before jumping on Svelte.
[0] https://github.com/sveltejs/svelte/issues/2308
[1] https://svelte.dev/repl/efbe52272558468397b66e46fa906561?ver...
1. I just missed the part of documentation that talks about optional properties. And with undefined and null issue, it's a bit surprising that two-way bindings behave differently that 1-way. Passing null or undefined is convenient when an API gives you such values and they represent empty there.
2. Ok. What I feared is that the tutorial would turn out not to be bugged, and Svelte would be a bad choice for CPU-intensive SPAs. Thanks for reassuring me that's not the case. I'd still love to see the fix for the tutorial bug (because at the first glance, there isn't anything that screams "wrong!" in its code).
3. Yup. I just wanted to point out it's noticeable if you look for it. I will look into SSR later.
4. Same as in point 2.
BTW I just wasted 2 hours fighting with bind:group[0][1]. This issue is an example of what I meant by saying that people may want to wait before jumping on Svelte.
[0] https://github.com/sveltejs/svelte/issues/2308
[1] https://svelte.dev/repl/efbe52272558468397b66e46fa906561?ver...
Update: I take back my words about optional parameters - I didn't notice docs saying "To squelch this warning, ensure that a default is specified, even if it is undefined"[0]
[0] https://svelte.dev/docs#1_export_creates_a_component_prop
[0] https://svelte.dev/docs#1_export_creates_a_component_prop
Does anyone know what's the status of Typescript support in Svelte is? This thread is understandably locked:
https://github.com/sveltejs/svelte/issues/1639
Still I'm curious.
Typescript and RxJS (or MobX) with Svelte as the afterthought (https://michel.codes/blogs/ui-as-an-afterthought) would be a nice combo.
https://github.com/sveltejs/svelte/issues/1639
Still I'm curious.
Typescript and RxJS (or MobX) with Svelte as the afterthought (https://michel.codes/blogs/ui-as-an-afterthought) would be a nice combo.
I'm afraid Svelte with typescript will loose some of its charm. Typescript is a little more verbose and explicit, also it cannot be directly executed by the browser (so you need to compile it, yet it is intermingled with HTML at times — there's JSX for that but Svelte kinda wants to NOT go the JSX/ShadowDOM route)
Internally Svelte uses TS though, the author claims to love TS also! It just does not mix very well with Svelte.
Stencil.js and lit-element are better picks in this regard IIRC.
Internally Svelte uses TS though, the author claims to love TS also! It just does not mix very well with Svelte.
Stencil.js and lit-element are better picks in this regard IIRC.
Pretty much as you can see. A lot of people want it. It's not done yet.
Obviously Svelte is a JS to JS transformative compiler - you need to make a TS to JS transformative compiler.
I'm hacking on my next app using TypeScript on the backend (particularly around the data layer) and JS/Svelte on the frontend. I would like TS on Svelte, but the rest of Svelte is compelling enough I'd still use it over older tech like React.
Obviously Svelte is a JS to JS transformative compiler - you need to make a TS to JS transformative compiler.
I'm hacking on my next app using TypeScript on the backend (particularly around the data layer) and JS/Svelte on the frontend. I would like TS on Svelte, but the rest of Svelte is compelling enough I'd still use it over older tech like React.
Yeah, I love the concepts, philosophy and the simplicity of Svelte, but sadly I can't consider using it until it has proper TS support.
I've been writing React professionally for 5 years straight and I'm absolutely sick of it. I haven't spent enough time with Svelte but I'm sick of React and all the noobs who swear by it. I'm sick of it spinning around in circles and nobody getting anywhere. I'm sick of terrible SPA's consisting of a pile of bandaids stacked on top of one another. I'm sick of testing it with tools like Enzyme. If React were so great, I'd expect to see better things coming out of Facebook. They do one thing well, steal and sell users data. Everything else was bought. Honestly, just sick of Facebook. I was more productive writing stateful apps using C# and ASP.NET with jQuery. In fact, 9/10 we don't need stateful UI's nor React.
GraphQL sucks too. Good luck setting up caching. For instance, hey we forgot caching is important, now that the architecture doesn't allow for it since it uses a single api endpoint... the talked about solution is to use localStorage or sessionStorage. JS is a huge noobfest and those that think React is the answer to everything, probably haven't been in this game long enough.
GraphQL sucks too. Good luck setting up caching. For instance, hey we forgot caching is important, now that the architecture doesn't allow for it since it uses a single api endpoint... the talked about solution is to use localStorage or sessionStorage. JS is a huge noobfest and those that think React is the answer to everything, probably haven't been in this game long enough.
I too have been using react professionally for the last 5 years and I have the opposite take on it - I still love it as much as when I started using it. I'm a solo dev so I get to control quality end-to-end, perhaps this is where our difference in opinion stems from.
I have no doubt there is tons of awful react code out there written by noobs but the same can be said for practically any software engineering endeavor.
I'll concede that it takes time + effort to understand how to best use react but it's merely a tool and you need experience and insight to understand how best to use your tools. I try to use as little state as possible and use functional components everywhere I can. Hooks have been a big help.
I agree about having reservations with GraphQL, it doesn't seem ready for primetime to me although I'm keeping a close eye on it because I like the underlying concept.
JS is a "huge noobfest" imo because webdev is so accessible and prevalent. But today's noobs are tomorrow's professionals ;) Typescript has been a very welcome development to encourage better dev practices.
I have no doubt there is tons of awful react code out there written by noobs but the same can be said for practically any software engineering endeavor.
I'll concede that it takes time + effort to understand how to best use react but it's merely a tool and you need experience and insight to understand how best to use your tools. I try to use as little state as possible and use functional components everywhere I can. Hooks have been a big help.
I agree about having reservations with GraphQL, it doesn't seem ready for primetime to me although I'm keeping a close eye on it because I like the underlying concept.
JS is a "huge noobfest" imo because webdev is so accessible and prevalent. But today's noobs are tomorrow's professionals ;) Typescript has been a very welcome development to encourage better dev practices.
> I too have been using react professionally for the last 5 years and I have the opposite take on it...
I'm with you mostly. When I started React close to 5 years ago it was PAINFUL. Coming from mostly jQuery (single library and I'm on my way) to trying to figure out gulp, bower, webpack, babel, etc. The tooling has much improved with the release of `create-react-app`. I can't exactly say the tooling has become better as much as it has been hidden away and the defaults are mostly ideal. Yesterday I had a huge headache trying to figure out why my treeshaking wasn't working (it was bundling 1.5mb of icons into my app). Turns out I was using an old version of `react-scripts` and with it an older webpack which I may have noticed sooner had I hand-built the tooling like the old days of React.
It has become impressively complex with all of the moving parts that are required for a React app these days. Webpack alone is not for the faint of heart with all of the configuration and babel-hell that code (and other files) has to flow through. Without `create-react-app`, I would probably have left React long ago, which would be disappointing because I enjoy the syntax, hooks, readability. I've tried Angular and absolutely hated it, perhaps Svelte would be interesting to me.
I'm with you mostly. When I started React close to 5 years ago it was PAINFUL. Coming from mostly jQuery (single library and I'm on my way) to trying to figure out gulp, bower, webpack, babel, etc. The tooling has much improved with the release of `create-react-app`. I can't exactly say the tooling has become better as much as it has been hidden away and the defaults are mostly ideal. Yesterday I had a huge headache trying to figure out why my treeshaking wasn't working (it was bundling 1.5mb of icons into my app). Turns out I was using an old version of `react-scripts` and with it an older webpack which I may have noticed sooner had I hand-built the tooling like the old days of React.
It has become impressively complex with all of the moving parts that are required for a React app these days. Webpack alone is not for the faint of heart with all of the configuration and babel-hell that code (and other files) has to flow through. Without `create-react-app`, I would probably have left React long ago, which would be disappointing because I enjoy the syntax, hooks, readability. I've tried Angular and absolutely hated it, perhaps Svelte would be interesting to me.
I definitely agree the tooling for modern JS can be a huge PITA. Once it's all setup life is great and productivity soars but I completely sympathize with beginners feeling lost and even experienced devs turned off from the opaque complexity.
Whoa. Sounds interesting and promising. If anyone from Svelte is here listening I'd like to point out that this isn't quite correct. WCAG actually specifies that __decorative__ images have no alt= or use alt=''. But yeah, a warning can't hurt. Kudos!
Svelte provides runtime warnings for accessibility issues. For example, <img> elements that have no alt attribute are flagged.
Svelte provides runtime warnings for accessibility issues. For example, <img> elements that have no alt attribute are flagged.
Having no alt and having alt="" do not produce the same results to the audiences relying on those attributes to perceive images. The W3C's tutorial on decorative images (found at https://www.w3.org/WAI/tutorials/images/decorative/) says to use alt="" to mark an image decorative, as some (prominent) screen readers will read the image's file name when no alt attribute is set.
But hey, that Svelte is providing these warning is great for accessibility!
But hey, that Svelte is providing these warning is great for accessibility!
Yeah. Thanks. Maybe you'll know this? Is it kosher to user aria-hidden=true for decorative images?
I'm asking because it's not easy convincing a client that alt="" is ok. They've read so many times "also have a value for alt-=. This is especially true of clients who are SEO-centric. It seems to me there should be an easy and obvious way have a decorative image with a non-blank alt=.
I'm asking because it's not easy convincing a client that alt="" is ok. They've read so many times "also have a value for alt-=. This is especially true of clients who are SEO-centric. It seems to me there should be an easy and obvious way have a decorative image with a non-blank alt=.
In my experience, aria-hidden will effectively accomplish the same ends for accessibility purposes. That article mentions using role="presentation" but with the caveat that not all screen readers and such understand that well enough to then not try to start reading the filename.
I guess the question is if SEO crawlers still read alt text for images marked as aria-hidden="true" or not. I have no idea on this one, but I'm very curious about it.
I've been pushing the folks I work with to consider SEO as a second-class citizen within alt text. If you can reasonably use a keyword in a natural, useful way, definitely use it. Otherwise, from what I can tell, an image's alt text doesn't seem to have any greater SEO value than the rest of the content on the page. Write better on-page content with better keyword use, with alt text being informative extra content.
And clarification on when alt text is needed: 1) if the image contains informative content that adds to the surrounding content, but also 2) a linked image where the image is the ONLY thing within the link, in which case the alt text should describe the destination of the link, not the contents of the image. I just recently learned this, but it makes sense when you think about it.
I guess the question is if SEO crawlers still read alt text for images marked as aria-hidden="true" or not. I have no idea on this one, but I'm very curious about it.
I've been pushing the folks I work with to consider SEO as a second-class citizen within alt text. If you can reasonably use a keyword in a natural, useful way, definitely use it. Otherwise, from what I can tell, an image's alt text doesn't seem to have any greater SEO value than the rest of the content on the page. Write better on-page content with better keyword use, with alt text being informative extra content.
And clarification on when alt text is needed: 1) if the image contains informative content that adds to the surrounding content, but also 2) a linked image where the image is the ONLY thing within the link, in which case the alt text should describe the destination of the link, not the contents of the image. I just recently learned this, but it makes sense when you think about it.
"2) a linked image where the image is the ONLY thing within the link, in which case the alt text should describe the destination of the link, not the contents of the image. I just recently learned this, but it makes sense when you think about it. "
Yeah. Good stuff. Thx.
p.s. Best I can tell most images are decorative. That is, they are there for the visual appeal, to create "white space", etc. It's fairly rarely they actually contain content. Of course, there are exceptions, but in general.
Yeah. Good stuff. Thx.
p.s. Best I can tell most images are decorative. That is, they are there for the visual appeal, to create "white space", etc. It's fairly rarely they actually contain content. Of course, there are exceptions, but in general.
I agree! I work on a marketing team and it’s interesting to hear the conversations about what is and isn’t decorative. Are brand elements decorative? Generally yes, but on a marketing site, aren’t those half the point? At which point does that make them informative?
It can be frustrating to sit in meetings where people go back and forth about this stuff. But at the end of it all, any meeting where people are constructively discussing accessibility is a win for me.
It can be frustrating to sit in meetings where people go back and forth about this stuff. But at the end of it all, any meeting where people are constructively discussing accessibility is a win for me.
You want simple? Try HTML, CSS, and JavaScript.
Svelte really resonates with me - as a previous AngularJS dev, tried to get into React and VueJS several times, but I did not want to learn a build system (grunt, gulp, webpack) and always have to stay up the date with the "best" ways to build. And I don't have the time to invest in learning another tool.
The nice thing about Svelte isn't necessarily the syntax. It's the fact that out of the box it builds without me having to learn how to build it. That and the small bundle sizes and single file components sealed the deal for me.
The nice thing about Svelte isn't necessarily the syntax. It's the fact that out of the box it builds without me having to learn how to build it. That and the small bundle sizes and single file components sealed the deal for me.
This is a framework I've been interested in for while. Need to find an excuse to use it
[deleted]
Does Svelte have a prebuilt set of components like ant.design?
Svelte is great, but I will probably use the new Blazor framework from Microsoft that compiles to WebAssembly. The benefit is that I can use C# instead of JavaScript.
Unfortunately with the downside that your bundle will be quite large. Hopefully that'll get better, but most likely, due to fundamental reasons (you need to pass along a C# runtime), I doubt it'll be even remotely close to something like Svelte.
Looks interesting. Is there a list of libraries that are productions ready that can be used with it? I'm looking for Formik and ReactRouter equivalents at least.
So for small apps, the final bundle size is significantly smaller since there's no framework "runtime" code included. What about large apps though?
Svelte is great. It's a shame we need a framework to do that and that the standard HTML/CSS/JS platform can't do that natively.
One of the more popular Mastodon frontends uses Svelte.
https://pinafore.social/
https://pinafore.social/
The template syntax is a bit weird. Not sure what would have been better but thats just a gut feeling.
Svelte is a real good shot vs the angularjs (v1) I used in 2015, but still, I will stick to imba ;)
I've never been so excited about a library since the React itself.
Looks like early Vue to me
[deleted]
The webpack build that the Angular CLI uses internally is completely transparent, you don't have to know Webpack at all. Just do ng build --prod and you have your optimized bundles will all the bell and whistles.
Webpack is even going to be replaced by Bazel but we won't even notice it, all we have to do is ng update and live goes on the next day after the release.
The Angular ecosystem with the Angular CLI is just so stable and complete, with hardly any API changes in years, it's just a joy to work with. The CLI even integrates with Sass and other CSS processors.
You can really focus on the application, and forget tooling. I think the take of Angular on batteries-included tooling & their take on incremental upgrades are such a huge advantage over other ecosystems, AFIK nothing else comes even close.