...but that's what Svelte is not. The techniques you adopt won't transfer over to vanilla HTML/CSS/JS without the magic Svelte compiler. These habits will become crutch when Svelte inevitably goes the way of every Javascript frontend framework.
> something complex like React
React is not that complex, certainly not more so than Svelte. It's hard to wrap your head around some behaviors, but at the end of the day, it is really just Javascript/Typescript. It is programming. As a programmer, I want to spend most of my time programming in a programming language, not so much of it configuring the Rube-Goldberg machine that is HTML/CSS. Your mileage may vary, of course.
> this silly side project made in Svelte over a weekend
> As a programmer, I want to spend most of my time programming in a programming language
If your work requires you to use a web stack, this attitude will not serve you well in the long run. If you make the effort to learn these technologies, you'll soon find them to be simple and predictable, but admittedly not without some historical baggage. You may even have an easier time with Svelte, since it has everything working out of the box, unlike React, which requires you to figure out a build toolchain and a separate solution for styling.
Not sure about this. Most JS frameworks only last a few years before the next shiny is mass adopted. The churn in JS land is insane.
React is definitely one of the long beards though, and thats’s because declarative programming is a win for UIs IMO. So much so it had a massive knock on effect in popularizing this approach (what’s old is new again… and again) across languages and problem sets.
IMO we're long past the churn era - Svelte itself is 8 years old. There are occasional bursts of new frameworks and tools, but only when there is a new niche - the last one I remember was a few years ago when suddenly everyone wanted to do a static website generator. And that didn't make existing frameworks obsolete.
In my post I was actually speaking about learning CSS and HTML alongside the "real programming language" that is JS/TS.
> If your work requires you to use a web stack, this attitude will not serve you well in the long run
I disagree. A "web stack" is outdated quickly, but the language remains mostly the same, as does my data. React lets me express most things naturally as forward data transformations, without entangling me too much to peculiar toolchain that will become obsolete and break absolutely everything.
> You may even have an easier time with Svelte, since it has everything working out of the box, unlike React, which requires you to figure out a build toolchain and a separate solution for styling.
Sure, you'll have an easier time making decisions if someone else makes them for you.
I swear every time I use React, every couple of years, I wind up thinking "okay fine, but... why?"
I love JSX. But the React API, for some areas, feels complex and boilerplatey. I dunno why you have to explicitly memoize some stuff. Svelte just magics that shit away.
> But the React API, for some areas, feels complex and boilerplatey
You may or may not have noticed this, but the React API is a bit counterintuitive to how JS or any other code you normally write would work because the component function gets invoked repeatedly so any code in the path of the functional component that's not externalized into a hook or memoized will be invoked again.
That's also why in local dev mode, you'll see the render cycle executed twice so that you can spot any undesired side effects due to this design choice.
So a lot of the complexity is to deal with this specific design choice to determine when code inside of the component function needs to be re-executed. In React, you need to explicitly opt-out of reactivity while in nearly every other framework, you are opting-in to reactivity.
For me, I've always seen this as the weirdest footgun because it's antithetical to the underlying language and runtime behavior so developers need to be explicitly aware of this behavior.
As someone who had to work around the bugs and limitations of IE6 for years in the enterprise, popularity is not a measurement of how good a technology is.
The reason React is "embraced" by the industry is that it is widely used, not because it's the best choice. This lowers the risk for companies that can replace its developers with another easily. I'm not saying it's as bad as beeing stuck with a stale IE (yet), but there are surely good alternatives out there.
"Nobody has been fired for choosing IBM", was a saying that applies to React today
It has reached the "IBM" point where it's so widely used, that it has become the most rational choice for enterprise.
We have to wait for a few years while smaller businesses who don't have (or care about) the same risks uses better alternatives until they reach the point where you are not blamed for choosing something outside the box
> The reason React is "embraced" by the industry is that it is widely used
That looks like tautology to me. What point are you trying to make with this?
Comparing IE6 and React is _hardly_ a fair comparison. One was a Trojan horse injected by corporate policies and ACLs, while React gets explicitly chosen by teams. And... Yes, there _is_ a reason why nobody gets fired for choosing React: it's not a bad choice! Is Svelte a better choice? Not universally. Unfortunately—like with many things in our field—it comes with trade offs and the answer boils down to "it depends" again.
React has its quirks, but "hating" on a library because it was part of a dumpster fire project doesn't mean the library is bad, just that people using it weren't competent with it (not necessarily incompetent in general).
Vue, Svelte, Leptos, Solid, Elm. I've seen all of them used as dumpster fire fuel, and it was hardly the library's fault.
I do not hate React and am not the person who made the dumpster fire argument. The original person complained about React, and another person used popularity as a counter argument. That was what I replied to.
> That looks like tautology to me. What point are you trying to make with this?
React is in a place now, where it is the "safe" default choice for Enterprises. It's not necessarily a bad choice, but I argue that risk management is often an important part of deciding which tech to use.
It got to this point by being backed by Meta and was a genuinely good alternative to other frameworks at the time. But it is my view that enterprises prefer React not because it is the best, but because it is good enough and easy to find workers with experience. This is a self reinforcing feedback loop.
I worked in a sales driven startup some years ago and got to shape the technology as the first hire and only developer for a few months. I chose React because it was easier to recruit for and time to market was important. If I had already a team of developers with experience with another framework, I would have chosen that one even if it had been a less popular framework due. Time to market was our main focus.
More established companies don't have the same time constraints and are often more concerned about scaling up with multiple teams. A less popular framework is a bigger risk. It is "easy" to hire 10 people for any framework, but what about 100?
Vue? Lol. I've been using Vue full-time in multiple large corporate code bases for the past 3½ years and I'd exchange it for React in a heartbeat. Its type checker and build toolchain are so abysmally bad and bug-riddled that I run into new bugs and limitations on the daily. …which is no surprise really if you introduce a new custom file format and make type checking an afterthought.
Meanwhile, React is basically pure TS and the only bugs I run into are the occasional limitations of TSC.
>Its type checker and build toolchain are so abysmally bad and bug-riddled that I run into new bugs and limitations on the daily.
This seems like a setup issue.
Mine catches everything just fine. Both in-editor (I use neovim) and with a make step (just calls vue-tsc) + a precommit hook as a sanity check.
>React is basically pure TS and the only bugs I run into are the occasional limitations of TSC.
React is obscene. It always seemed to me the Java of the FE world, made worse in recent years. By that I mean grotesquely verbose and full of ceremonious value passing through multiple functions just for the tiniest of things. I've had to work with React codebases and these days I outright refuse to do that/turn down jobs with that requirement. I'd rather use angular.
Svelte and Vue are ergonomic and straightforward and they sanely default to SFCs instead of that woeful chimera of languages called JSX/TSX - you can still use it if you so desire though.
> It's hard to wrap your head around some behaviors
I've got a React maintenance and development project coming up in a few weeks. I'd love if you'd expand a bit on these points and maybe point to some relevant docs. You could potentially save me days or more of tail chasing. Thanks.
The biggest thing most people don't understand is that React re-renders recursively by default, regardless of whether any particular child component's props actually changed or not. Most of its behavior patterns follow from that one.
I have an extensive post called "A (Mostly) Complete Guide to React Rendering Behavior) that covers the concepts and nuances in detail:
Primarily the rules of hooks and what does and does not trigger a render or a unmount. If your project still uses class instead of function components, that's a potential target for refactoring.
...but that's what Svelte is not. The techniques you adopt won't transfer over to vanilla HTML/CSS/JS without the magic Svelte compiler. These habits will become crutch when Svelte inevitably goes the way of every Javascript frontend framework.
> something complex like React
React is not that complex, certainly not more so than Svelte. It's hard to wrap your head around some behaviors, but at the end of the day, it is really just Javascript/Typescript. It is programming. As a programmer, I want to spend most of my time programming in a programming language, not so much of it configuring the Rube-Goldberg machine that is HTML/CSS. Your mileage may vary, of course.
> this silly side project made in Svelte over a weekend
I will admit, that's what Svelte excels at.