Svelte is so great... so were react, angular, ember, meteor, and vue. I'm sorry, but I've got trouble seeing how having one more framework to learn is going to help any thing.
There's a webcomic of some sort to which I can't find the link, which talks about this. Some one is sick of the bloat of x framework/tool/whatever, and decides to build it better. He works hard, and finally version 1.0 is released to dramatic music. But there's a problem - it hits the real world and starts running into edge cases, bugs, and other things that can't be predicted in design and testing, necessarily. Features creep, and over time, it becomes just as bad as that which it sought to replace. Then, some bright young soul gets the idea that he can do it better...
This is not to discourage innovation. It doesn't appear it's been battle-tested like other frameworks, and I don't see many major operations on the list of users. If it ends up better, great, but I can't say I'm optimistic.
It's just more options. Svelte is new in that it actually compiles the components and logic into plain low-level JS code instead of having a "runtime".
It's something most of these frameworks should have already done by now considering they need build steps but maybe it needed a new project to make it happen. It's a brand new release though so it'll take more time for uptake, and by people who think the opposite of what you typed.
You're right that it's more options, but it's also one more box a "competent JS dev" is expected to tick. One of the best and worst things about the JS ecosystem is the plethora of choices available.
On compilation, nope. Riot.js did it first, and this is literally the entire premise of typescript (I know typescript is a different language, but I see little difference here as it can mix with JS between writing only some stuff in TS).
You're right, they probably should have done it, and I'm excited to see it. But I also don't see why they couldn't have submitted a PR to react/angular/ember/meteor/vue.
> But I also don't see why they couldn't have submitted a PR to react/angular/ember/meteor/vue.
I see this sentiment a lot in open source. When I made Rollup — which is now used to build the most popular libraries in the JavaScript ecosystem, including some you just mentioned! — people asked why I didn't just submit a PR to webpack?
I understand why people ask that. But it just doesn't work like that. Very often, to take a step forward, you can't simply make incremental changes to an existing project — you need to create new foundations altogether. When Svelte 1 came out in 2016 I was already responsible for a different framework (Ractive), and it wasn't possible to make the changes I wanted there. If you can't do what you need to do by making a PR to your own project, then imagining that you can do it in a PR to someone else's is a fantasy.
It's a shame that the site's down. Until then, you can (and I heartily recommend doing so) watch the "Rethinking reactivity" video here: https://www.youtube.com/watch?v=AdNJ3fydeao
FWIW I did a project with Ractive before React became popular, and I liked it. I guess for many problems it would still be enough if only it were more popular.
> You're right that it's more options, but it's also one more box a "competent JS dev" is expected to tick.
Is that really true? React and/or Angular is something I would expect. If one uses anything more exotic then one should have a "they'll figure it out on the job" attitude.
> But I also don't see why they couldn't have submitted a PR to react/angular/ember/meteor/vue.
Do you honestly believe one can just leave a "here's a full static compiler for X" at the doorstep of these projects with some expectation of it actually being accepted?
That would basically be an entirely separate program to be maintained alongside the runtime and any design considerations on either side will affect the other side.
Oddly, it's a lot like Vue.js, except pre-compiled with a simpler syntax. Vue3 is about to make some syntax changes which will make Vue.js a lot like Svelte... :)
We should probably settle. Other platforms afford a new UI framework maybe once a decade.
The Web Frontend, already running on top of an apparently inadequate framework called "HTML5", somehow needs to be reinvented every year and it's a huge cost factor.
No it's not, no one is rewritting their front ends every year to change frameworks. React was released 6 years ago, Angular fully released about 3 years ago. Just because some person decided to build something that solved their problem and may help others doesn't mean you need to adopt it and change everything. This argument that everyone needs to slow down because some people don't like hearing about change is ridiculous.
No other platform is as widespread and accessible as the web. There's more developers able to target sites that fit a massive range of uses, more than any other platform ever. So ofcourse there are going to be different needs for different use cases.
> No it's not, no one is rewritting their front ends every year to change frameworks.
Maybe not quite every year, but the dominant frameworks have changed a lot in the past decade and if you're still running some of the "next big things" of yesteryear the developer pressure to switch is strong. The churn is real.
> React was released 6 years ago, Angular fully released about 3 years ago.
In my opinion, React being quite stable over that timeframe is a big factor in it becoming the dominant player. Angular being scrapped and rewritten is exactly what I'm talking about, lots of development effort wasted there.
> This argument that everyone needs to slow down because some people don't like hearing about change is ridiculous.
If the kids want to keep playing with the latest toys, that's fine. Just don't expect the people paying the bills to buy into them.
You have misunderstood the point. I'm not saying "stop creating new frameworks". Create anything you want, I don't care.
When I am talking about "settling down", I'm talking about the people that implement real systems for businesses to use. Those people have to make decisions on the technology they're pushing.
If those people can't settle on a stack and keep changing their minds on how to implement a user interface, somebody has to pay for that. This is akin to a "little fire" in a very real sense - it's burning money that could be used otherwise.
So telling me that "I don't have to use it" is besides the point. I don't run the whole show by myself. Developers need to be reasonably comfortable with their stack. If you are using <outdated stack X> but the whole industry is shifting towards <shiny new stack Y>, people will just quit on you.
Businesses pay to solve business problems, not change frameworks. The majority of software dev requires long-term decision making, commitment and support. Developers who can't solve problems because they're too busy chasing the latest framework aren't going to be getting much work.
People will experiment, and it's good for the industry to have new innovation, but there's really not that much danger of constantly shifting tech stacks unless your team and leadership don't know what they're doing - and if that's the case, you have bigger problems then the tech stack.
> Developers who can't solve problems because they're too busy chasing the latest framework aren't going to be getting much work.
That's not really how hiring works. Nobody is going to put "I failed to get anything done because we re-wrote everything in Svelte" on their resume.
> People will experiment, and it's good for the industry to have new innovation, but there's really not that much danger of constantly shifting tech stacks unless your team and leadership don't know what they're doing - and if that's the case, you have bigger problems then the tech stack.
If you're switching a tech stack, by definition, you don't really know what you're doing. You're treading in unknown territory. You're spending real money for the promise of hopefully increasing productivity in the future. You are speculating.
I'm not saying this is a risk you should never take, there's a downside to never switching stacks too. The idea that you just need the right team and everything will be fine is a fantasy.
I'm saying that people dont constantly switch. It's not that common at all, despite what you might hear in online discussions. And it's usually because most of these projects have real timelines and deliverables, along with a team of people who aren't interested in rewriting everything either.
Of course there are a few teams (even in praised companies) that chase the fad, but they're the sames ones that do things like use CQRS and Kafka for a basic CRUD app.
You're saying people don't constantly switch, but even if they did, it wouldn't be much of a problem unless they don't know what they're doing.
Well, fair enough. I never claimed that businesses switch stacks "constantly" anyway. Still, at the industry level, there is constant flux - much more so than on other platforms. Unless you use one of the big players like React, chances are your framework of choice won't last and become legacy software quite soon.
There's a webcomic of some sort to which I can't find the link, which talks about this. Some one is sick of the bloat of x framework/tool/whatever, and decides to build it better. He works hard, and finally version 1.0 is released to dramatic music. But there's a problem - it hits the real world and starts running into edge cases, bugs, and other things that can't be predicted in design and testing, necessarily. Features creep, and over time, it becomes just as bad as that which it sought to replace. Then, some bright young soul gets the idea that he can do it better...
This is not to discourage innovation. It doesn't appear it's been battle-tested like other frameworks, and I don't see many major operations on the list of users. If it ends up better, great, but I can't say I'm optimistic.