DEV Community

Cover image for Svelte for Sites, React for Apps

Svelte for Sites, React for Apps

swyx on October 18, 2020

Translations: 中文版 In 2020, my personal recommendation to web developers is to use Svelte for Sites, and React for Apps. This is, remarkably, a n...
Collapse
 
mvolkmann profile image
Mark Volkmann

You keep pushing this point and I keep not getting it. I think I won’t be convinced until you can provide a list of things that are easier to do or better implemented in React than in Svelte. I can’t think of anything off the top of my head that works better or is easier to implement in React than in Svelte. On another note, I think it was bad timing to publish this the night before Svelte Summit.

Collapse
 
swyx profile image
swyx • Edited

i dont agree with the premise of the question, but fwiw my list is in the blogpost. here is a summary.

  • hiring
  • 3rd party ecosystem (eg react-aria, material-ui, react-testing-library, redux, apollo, framer/framer motion, styled-components etc). Most companies, like AWS or Stripe, offer React SDKs before supporting any other framework.
  • react native
  • (in future) suspense/react flight
  • governance

first two points are sufficient for people to make tech choices already. yes i understand that these are not central to the framework. doesnt matter. early-to-late-majority adopters don't care. they care about ecosystem.

what matters is where does svelte have an indisputably clear advantage TODAY. i wrote the final P.S. with this message in mind. "Svelte for Sites" is as much a convenient lie as an adoption tactic as it is an inconvenient truth because of the abovementioned factors.

blogpost timing also doesnt matter. we both write with a more evergreen perspective and honest discussion is always a plus. but acknowledged that you disagree.

Collapse
 
mvolkmann profile image
Mark Volkmann

I agree with you on the React Native advantage. We’ll see if Svelte Native continues to mature.
I don’t yet understand the significance of Suspense and Flight, so I can’t comment on those.
It’s just a matter of time for the Svelte ecosystem to sufficiently catch up.
The hiring issue is minimized by the fact that Svelte has a low learning curve.
I think what triggers me most is the implication that Svelte should only be considered for sites. I’ve successfully used it for many apps. I don’t want developers to get the idea that Svelte is somehow lacking for real app development.

Thread Thread
 
lepinekong profile image
lepinekong • Edited

Personally I would choose Svelte but for big project of xx millions like in big corps I won't because actually hiring issue cannot be minimized : most already-heavily-invested-in-a-framework developers will just refuse to learn another (new) framework ;)

There are other reasons, I just pick the one argument you advance.

Thread Thread
 
swyx profile image
swyx • Edited

don't worry, I'm with you on the core capabilities of the framework. but ecosystem matters when building apps. plain and simple. part of what I'm doing here and with svelte society is laying the groundwork to address these issues, but it will take years. in the mean time, market to the usecase svelte wins hands down.

we agree more than we disagree.

Collapse
 
ascotto profile image
Andrea Scotto Di Minico • Edited

Can totally agree on the first two points: for me transitioning from jQuery/javascript to React engineer made the biggest impact on my pay-check, and a better engineer overall. Knowing and increasing the expertise in React gave the power to negotiate better salaries/contracts, work at better companies and overall made a huge positive change in my life. Beside all this, I am also able to start my micro company with my girlfriend about frontend consulting (website needs to be finished hehe..)
Developers sometimes should shift mentality non just thinking how to do something with a "framework" but also how will this impact my life outside of my career.

Ecosystem is big, with lot of resources, and the are tons of open source project where you can find a lot of useful code and patterns.

Before trying React I wanted to learn Vue, I learnt some this was soon after release of version 1.0 of Vue, and at the time could not include in any final production project.

With Svelte, I made a little dynamic form on a WordPress site to test it out, was pretty happy with the outcome, the issue I had there was: if the site has already jQuery should you add Svelte for just a component?

As the final judgment: from my standpoint I would switch to using Svelte for website only if I cannot achieve the desired performance with React/Preact, and if there is not already jQuery.

Thread Thread
 
swyx profile image
swyx

JQuery is still a lot heavier than svelte. I'm not sure if WordPress websites ship with JQuery by default or something, but if you can remove it then I'd explore replacing it with svelte. components are just much nicer to write with, tho that is a subjective opinion

Thread Thread
 
ascotto profile image
Andrea Scotto Di Minico

Worpdress websites all ships with jQuery, and all the frontend depends on it, specially if there are using a template. Replacing jQuery on a Worpdress website will be a big headache because you need to replace everything of every additional plugin. Also if the client is using Woocommerce is something is not worth doing, in my opinion.

The only way to use Wordpress effectively with React/Svelte would be as an API endpoint or, let’s call it as a headless CMS.

The new Wordpress builder block is also made with React, so there is better tooling with React around Wordpress, at least at the moment.

At the end of the day what is important is regardless of what you use:

  • are you happy with the DX of the the tools you are using
  • is the client happy
  • are the clients users happy
  • clients and end users does not care what is working behind, they just care if it works well or not
Collapse
 
btakita profile image
Brian Takita • Edited

My experience is the hiring & 3rd party ecosystem is unreasonably effective at convincing people who do not want to look deeper into the workflow & architectural distinctions when making a decision. They want to make a quick decision based on numbers & will ignore any other reasons for considering a decision.

In reality, hiring & 3rd party ecosystem don't have much of an impact, and may even have a negative impact, on the success of a project. Being able to hire any Tom, Dick, or Harry who just graduated the most popular Programmer Bootcamp floods the talent pool with formulaic, inexperienced, & unimaginative developers. I'm not saying new developers are necessarily low quality, just that low quality developers tend to leave the software development profession when they realize it's not their calling within a few years. Sadly, many of these low quality developers move into technical management and have an even bigger influence over tech decisions.

Better talent tends to self-congregate toward better tools to augment their talent. I would prefer to work with a smaller talent pool with better talent than a larger talent pool with diluted talent.

3rd party ecosystem means more dependencies of varying quality & maintenance burden.

Collapse
 
ajcwebdev profile image
ajcwebdev

React also has significantly more developed meta-frameworks.

Thread Thread
 
swyx profile image
swyx

yeah I count that as part of 3rd party ecosystem advantage

Collapse
 
trashandfire profile image
trash-and-fire • Edited

Better implemented in React:

  1. Error boundaries (not implemented in Svelte).
  2. Whitespace skipping. Svelte is a superset of HTML with meaningfull whitespaces between inline-block elements.
  3. Typescript support. Try to write and publish any Svelte module in Typescript.

Also Svelte lacks of good tools, templates, IDE support and etc. For example: svelte-loader restarts css pipelines for ALL files in project instead of changed one. The svelte library template uses Rollup by default to bundle library in single file, all dependencies will be inlined into module and can't be deduped and shared between multiple npm modules.

Collapse
 
spacedawwwg profile image
Paul Welsh

These are "developer experience" related opinions, nothing to do with the output for the end user.

Collapse
 
danawoodman profile image
Dana Woodman

Coming to this way late, but for #3, that isn't so much of an issue anymore with pretty decent TS support (though not perfect)

Collapse
 
codechips profile image
Ilia Mikhailov

Performance and size are two factors that often can be optimized, but what about DX? Ever had to add forms to your React app? Spent time deciding on which forms library is best, finally went with Formik, and then spent half a day trying to find the optimal integration way for just your app. Ever got lost in hook hell? Are you sure you understand how useEffect works and where you should use it? My point is, React is overly-complicated and React fatigue is real.

I think that you should use technology/framework that makes you most productive while reducing your cognitive load at the same time. Newbies often jump on the React bandwagon because it comes from a big company and "everyone is using it".

I don't blame them. After all, it's where the money and jobs are. But do I feel sorry for them, because React is not easy to learn and IMO not a good first introduction to web development.

Also, JSX should be a low assembly language instead of something you write your apps in. Change my mind.

Collapse
 
aleksandrhovhannisyan profile image
Aleksandr Hovhannisyan

Also, JSX should be a low assembly language instead of something you write your apps in. Change my mind.

Not sure I know what this means. JSX is just another way to write HTML, except it's in JavaScript and gets compiled to HTML. I'm not sure how it's even comparable to assembly...

Collapse
 
peerreynders profile image
peerreynders

JSX is just another way to write HTML, except it's in JavaScript and gets compiled to HTML.

It compiles down to JavaScript React.createElement calls - not HTML.

JSX sees itself as an XML-like syntax extension to ECMAScript (i.e. not HTML).

So the common complaint is "what is this XML doing in my JavaScript code".

"I still maintain that JSX is pretty horrible."

Thread Thread
 
aleksandrhovhannisyan profile image
Aleksandr Hovhannisyan

Yup, you're right, JSX compiles down to React.createElement calls, which create elements (JSON blobs really) that describe UIs. But at the end of the day, these just translate into native DOM render calls. "Compile" was a poor choice of wording on my part :)

Having worked with React for about two years now, I honestly don't see the problem with JSX. It's an excellent, declarative syntax for creating UIs.

Thread Thread
 
peerreynders profile image
peerreynders • Edited

(JSON blobs really)

Naahh... React Elements ... which if I understand correctly are more generally vnodes.

"Compile" was a poor choice of wording on my part :)

It was the "HTML" that prompted me - "compile" is often used where "transpile" is appropriate - the issue is when people see JSX as markup rather than function calls; HTML only gets generated for SSR, not for client side rendering.

I honestly don't see the problem with JSX. It's an excellent, declarative syntax for creating UIs.

JSX as part of a sequence of JavaScript statements can be quite imperative; e.g. Marko's components are more declarative - the imperative behaviour of the component is clearly separated from its rendered representation; no "context switching" while reading JavaScript code.

But clearly there are people on both sides of the fence.

Collapse
 
codechips profile image
Ilia Mikhailov

So is it JS or HTML? Just kidding, of course. To me personally JSX always felt low level, something that is better suited to be generated by a machine from some higher templating language and then compiled to HTML. svelte-check tool does this to validate Svelte's templates for example. But the good thing is that we all have freedom of choice. Use whatever makes your heart beat.

Collapse
 
patarapolw profile image
Pacharapol Withayasakpunt • Edited

If you are talking about compiled Javascript (e.g. es5, minified), I think it is always Hyperscript, not JSX.

Collapse
 
seanmclem profile image
Seanmclem

Everybody is different.

Collapse
 
swyx profile image
swyx

deep

Collapse
 
khrome83 profile image
Zane Milakovic

I am less concerned with the tech. I even think Svelte is overkill for marketing sites. Yes, it’s smaller by a lot than react. But it’s also still worse than a jQuery site, a Alpine, or better yet, a vanilla JS site.

But it really comes down to balance. How much do you invest in getting the smaller site, vs a faster development life cycle.

Collapse
 
swyx profile image
swyx

what? a svelte site is almost certainly going to be smaller than jquery.

and the easy styling, animation, state mgmt, etc offer a faster dev life cycle to me.

but you do you man. just sharing my own thoughts.

Collapse
 
khrome83 profile image
Zane Milakovic

So it really depends on what you need. My gripe is not what you are writing but the fact you are turning everything into a component that does not have interactivity that needs rerendering, like header, footer, etc.

We spend so much time worried about the developer lifecycle. But we never let HTML and CSS be those things. We keep wrapping them in JS.

Svelte is better than React, and you can bail out with CSS by using custom or tailwind. But most people are doing CSS in JS. It’s just overkill for the user.

JS parse time of bundles on the most popular phones is shit. Once again I am talking about true marketing sites. Not apps.

But if you went vanilla JS, the bundle for sure would be smaller. Even jQuery could be smaller than converting all static HTML into Svelte components.

I am ignoring that you can sprinkle Svelte in, since most sites adopt it for everything.

Thread Thread
 
swyx profile image
swyx

hence my point about Islands Architecture and Elder.js. We agree!

Collapse
 
ryansolid profile image
Ryan Carniato

Yeah I wonder how light these straight from the CDN solutions are. Modern JavaScript tooling does amazing things. I was growing especially suspicious of these lightweight JavaScript solutions, both from size and perf perspective. So I added Alpine to everyone's favourite JS benchmark: krausest.github.io/js-framework-be.... It's neck and neck with Microsoft Blazor on perf and is by no means small. What are we really trading.

Collapse
 
swyx profile image
swyx

can you TLDR the alpine results? I find this table hard to read

Thread Thread
 
ryansolid profile image
Ryan Carniato • Edited

Alpine isn't large by any means but any size conscious modern library is going to via treeshaking going to produce smaller bundles than something that isn't prebundled. Alpine isn't treeshakeable currently (2.7.0).

Memory overhead is similarly middle of the pack. It's decent but again optimized libraries are still more performant.

Performance is not a motivation to the point Alpine is one of the slowest JS libraries I have ever seen. Orders of magnitude slower even for simple update operations like updating or selecting a row. If you use it sparingly as intended you will probably not notice but scale up that usage even a little and you will.

Basically, a library like Svelte is better by every performance metric if you can get over having to run npm i.


Explanation (for those who do want to take a minute to read):

The tests are basically a giant list management example like a TodoMVC where we are doing simple create, append, update, select, swap row, remove row, etc.. with enough rows and under CPU throttling from chrome browser to see differences between most common UI libraries. This is not the Realworld demo by any means only using the amount of features one might see in a simple admin management app. Styles are bootstrap etc...

One test measures the kilobyte weight of all assets sent over the wire. Nothing in the test is gzipped just minified. The smallest implementations come in around 143kb. Some notable results:

  • hyperapp 144.4kb
  • svelte 145.9kb
  • solid 149.5kb
  • preact 154.8kb
  • lit-html 156.5kb
  • inferno 162.9kb
  • alpine 167.9kb
  • mithril 175.2kb
  • vue 3 196.1kb
  • knockout 207.8kb
  • react 260.0kb
  • angular 295.3kb

Performance is not nearly as favourable. I respect that Alpine isn't really made to render 1000 components on a page. But how about selecting a row in a large list:

  • solid 24.8ms
  • svelte 37.1ms
  • hyperapp 45.3ms
  • inferno 49.6ms
  • preact 65.0ms
  • angular 78.3ms
  • lit-html 85.4ms
  • react 87.9ms
  • knockout 137.3ms
  • vue 3 164.7ms
  • mithril 270.5ms
  • alpine 1377.7ms

Or updating every 10th row with some additional text:

  • solid 143.9ms
  • inferno 149.3ms
  • knockout 160.0ms
  • hyperapp 160.1ms
  • preact 160.7ms
  • lit-html 168.0ms
  • angular 170.8ms
  • svelte 171.8ms
  • vue 3 183.9ms
  • react 188.6ms
  • mithril 242.1ms
  • alpine 1395.1ms

Finally looking at runtime memory with all list items on the page Alpine is middle of the pack again:

  • solid 2.2mb
  • lit-html 2.5mb
  • inferno 2.5mb
  • hyperapp 2.7mb
  • svelte 2.7mb
  • alpine 2.9mb
  • mithril 3.5mb
  • vue 3 3.5mb
  • preact 3.9mb
  • react 4.0mb
  • angular 4.2mb
  • knockout 11.6mb

*** obligatory disclaimer: this is a single benchmark scenario and not representative of all realworld apps... yada yada...

Thread Thread
 
khrome83 profile image
Zane Milakovic

So, I appreciate all your stats but your really missing the point.

Svelte is not smaller than Alpine. Take a standard marketing site where the header is just links. Nothing dynamic. These are still svelte components that have Javascript. But it should just be HTML.

I have a Sapper/Svelte site in production that is 126 components, but the number of those components that actually need to be dynamic on the client is less than a dozen.

And none of them have realistic performance concerns that I could not swap it out to Alpine and have the same experience for the user.

BTW Svelte and Alpine both modify the DOM and not a shadow DOM. So performance characteristics would be similar, which the exception of startup, where alpine has the parse live instead of having a JS bundle.

Tree shaking argument is mute, since Alpine is a actual library. Your not tree shaking your code. Your code is in HTML in most cases. You get too complex, use a library for a App. My argument was just simple marketing sites.

Thread Thread
 
ryansolid profile image
Ryan Carniato

Yeah you are right it's deeper than that. If we aren't doing the same work they arent going to be close. Which makes Elderjs interesting since it potentially could. But that also suggests JS on the server. So it isn't a swap in. But it is interesting such an approach could ship less JS. If Svelte itself is smaller and us only hydrating the necessary components.

Thread Thread
 
khrome83 profile image
Zane Milakovic

That would be my happy place, if we could declare what should actually be convert to a live component, vs what should be static html and is just using the life cycle to render, with a dapper framework or something similar.

Thread Thread
 
ryansolid profile image
Ryan Carniato

I'm fairly confident this direction is viable given Marko has been doing this at eBay since 2013. Who it is viable for is a different question. It will be interesting to see more libraries take this approach.

Collapse
 
ryansolid profile image
Ryan Carniato

Oh man this is heating up. Elder.js is interesting. MarkoJS has been doing this high performance partial hydration thing for years but I hadn't seen many other libraries make much progress here. Some had succeeded at skipping processing overhead but few the same sophistication of shipping less JS in completely automatic isomorphic way. That's very exciting.

I don't think the lines are that cut and dry. I mean I get from personal experience the small bundles and high performance attracting marketing and eCommerce. But Svelte's techniques don't preclude you from the application space. Conversely, there are sites that operate at massive scale that benefit from constructs beyond someones blog site. React might be structured better for applications and their orchestration features are designed to scale. However, look at how Svelte scales with feature use.

I get the right tool for the job thing, but Svelte's approach changes the rules. Modern bundlers are amazing. The right architecture could scale on features like Svelte with the philosophy of React. A bundler like Rollup can literally rewrite the code to the degree a feature as deeply invasive like Concurrent mode can be tree shaken right of the core of a library. How long before we see a bundler be able to code split a single module? What if you could opt in to pieces of the framework in different chunks?

Now I'm not going to say everyone picks up a library like that. People like Vue or Svelte for this simple entry point and Vue is very proud of it's progressive learning curve. So presenting things the way React does out the door might not suit everyone and that might be sufficient to give libraries specializations.

But I'd argue if anything Svelte has shown us there is very little stopping us from having it all. There is so much that hasn't been explored here. This doesn't have to be so versus. Both sides with time can learn from the other. But maybe that's something for the next generation of libraries to worry about.

Collapse
 
swyx profile image
swyx

indeed. maybe in a few years I'll be writing "Svelte for everything". but per my final section, I really doubt anything scales well from the smallest sizes to the biggest sizes.

Collapse
 
ivan_jrmc profile image
Ivan Jeremic • Edited

All UI libs that use wired template syntax for conditionals and so on like Vue and Svelte are garbage React nailed it with JSX nothing new they used what the JavaScript language anyway has and this is creating elements, all they did is changed the syntax of the createElement function to look like an element no matter how hard this JSX haters try with overcomplicated magic to beat react there is no chance React is king!

Collapse
 
devimposter1 profile image
devimposter

JSX is an ugly mess, using both Vue and Svelte very happily but sure ;)

Collapse
 
ivan_jrmc profile image
Ivan Jeremic

Most designers prefer Vue nothing new here.

Thread Thread
 
devimposter1 profile image
devimposter

Not sure what you mean by this but, I have been doing full stack dev for 20 years.

Thread Thread
 
ivan_jrmc profile image
Ivan Jeremic

And 15 of them with Vue.

Thread Thread
 
devimposter1 profile image
devimposter

This doesn't even make sense... oh well

Collapse
 
swyx profile image
swyx

k

Collapse
 
elpheno profile image
Pheno • Edited

Very strange in 2020 as statement!

With svelte you can do everything you want as you can use Vue too!
Angular still in use in big companies as React as well!
What if someone throw you “Blazor” is the future???
By this I mean your preference is not an universal truth!

You limit the svelte usage to only web pages

Collapse
 
swyx profile image
Comment marked as low quality/non-constructive by the community. View Code of Conduct
swyx

try to work on your english communication skills. this is not coherent or professional.

Collapse
 
mikenikles profile image
Mike

Pheno, thanks for sharing your thoughts on this topic, I agree with you. This blog post to me looks like it's meant to create controversy and visibility for himself. He started the post by saying this is his personal opinion, so that's where I stopped reading as it is not more than that: a personal opinion of a single individual.

Also, please don't take that comment about your English skills seriously. It was unnecessary and unprofessional to make such a comment.

Collapse
 
jesseskinner profile image
Jesse Skinner • Edited

I disagree with this take. Svelte is more than capable of building any web app that React can. The ecosystem is new, yes, but it's growing quickly. The compiler is young and evolving, with lots of potential for performance to improve further. Svelte today is comparable to React in 2015. If you could travel back to the year 2015, would you tell your company to put off using React and to build all your web apps with Angular 1 or Ember?

Collapse
 
swyx profile image
swyx

I appreciate that you removed "this is a bad take" from your opener.

Collapse
 
peerreynders profile image
peerreynders • Edited

You can, of course, use React to make sites.

At this point I feel you've already lost the potentially sizeable "just pick one" crowd - "OK, React it is" - it doesn't matter how nuanced a case you make for there being "actually different jobs".

React proved Components are the right way to go.
I want to code using components

"I think Components should vanish in the same way as Frameworks."

The Real Cost of UI Components

Objects were going to be the be-all and end-all after structural programming. Where are we now? Functional programming, Data-Oriented Design (ECS), etc. Similarly "UI Components" may not be a lasting abstraction. Convenient for the time being, perhaps. Until it becomes necessary to package things at a finer level of granularity or reorganize according to a different set of concerns (I'm also partially guided by the Elm community's experience that components don't work in Elm - leading to a different approach of composition).

"What size of app are you targeting for React to be 5-13% of total JS?"

I think this has more to do with the npm "there is a dependency for that" culture - i.e. people including dependencies for a tiny fraction of the total capability - there is only so much tree-shaking can do. The Svelte community has always struck me as more lean-minded. The whole productivity centric (DX-first) culture of React encourages the use of additional dependencies without necessarily carefully considering the inevitable tradeoffs down the line (e.g. total size of the app).

The fundamental question in the industry should be "do you need an app for that"? It also needs to be questioned whether "web apps" should keep pursuing the native app experience that SPAs seek to emulate. Even back in 2015 PPK called for Web vs. native: let’s concede defeat - not to give up but so that effort could be redirected to rethink the web - i.e. to find solutions that are more in line with the capabilities and constraints of the web.

From that perspective I think Svelte is more in line with the future of the web than React - provided the web has a future.

Collapse
 
ryansolid profile image
Ryan Carniato

I love this Richard Feldman talk. I hadn't seen this before but this is the sort of thinking I've employed while working on my own UI libraries. In this video he basically recreates OOP in FP environment but that is beside the point. But it isn't about some sort of doctrined approach. He's pointing out that logical breakdown in this manner can help us keep things in our heads. I think flexibility to support this sort of cognitive modelling is essential part of scalable UI libraries. There is value upfront of identifying the build -> discover -> refactor pattern so that you can alleviate the pressure of the inevitable refactor, and not let these organizational concerns own you.

Although admittedly there is another level for people who don't even want to think about that. Like, to quote Rich Harris, "hey computer build me a website". I don't think this is a site versus app distinction but it definitely happens more in the former. Some tools are just easier to use than others. And more often than not it is intentional. If something is inherently complicated making it easy requires adding a level of complexity. When we are ready to advance our knowledge we need to unravel those constructs already made for us in the name of easiness. Whereas the simple tool never really changes just builds upon. But maybe for many things people don't ever need to get past level 1.

Collapse
 
rowemore profile image
Rowe Morehouse

Agree. I don't love writing in .jsx and I find React to have unnecessary complexity for the marketing sites I typically develop.

Collapse
 
ivan_jrmc profile image
Ivan Jeremic

What complexity, you write JS nothing else.

Collapse
 
juanfrank77 profile image
Juan F Gonzalez

Ok @swyx you had my attention before but you convinced me now. I tried Svelte before and thought it was cool but for pet projects (still have to learn React for the job tho)
But with this distinction I see it clearer now, I will reach for Svelte anytime I don't need to build a complex, interactive app and don't want to use just HTML + CSS .

Svelting all the sites!!

Collapse
 
swyx profile image
swyx

yayy!! join us!

Collapse
 
wannabehexagon profile image
ItsThatHexagonGuy • Edited

React was never meant to be a framework/library that a new developer should start with but herd mentality more or less drives them to do so. "Its built by facebook and there's tons of jobs" is enough to convince a lot of people.

While I do understand that particular fact, I don't think a sufficiently experienced developer will have alot of trouble learning React. Because of the aforementioned issue, there's a lot of free and high quality learning material.

Svelte will not replace React, and in time will introduce its own problems. I am a React early-adopter and I was literally thrilled when it came out, I felt the same way I did about JQuery at the time that most do about React when compared to Web Components or X framework/library (ex: Svelte). Now I see that there are problems that React itself introduces.

Hooks hell, using hooks the right way, state management etc. all have solutions but the problem is that its a problem in the first place.

I'm not trying to be critical about anything but I don't believe that the problem lies in React but the way we solve the problem as a whole.

This will however always be a problem that will not be solved perfectly.

So what do we do? Use whatever that attempts to solve the problem the most elegantly. But with the understanding that it will never be solved fully. ex: You can use React for a simple site but should you?

PS: I enjoyed reading this post very much!

Collapse
 
lepinekong profile image
lepinekong • Edited

I believe Svelte within a few years (4 years on average like for node ? ) may be able to be a serious contender to React but I don't believe most developers and companies will be happy to invest in both as It takes investments to do so. So they'd rather play with it until svelte takes over a good chunk of the market before they do the switch.

Collapse
 
lepinekong profile image
lepinekong

I often agree with you on many things you say but since I practice First Principles myself - I've been trained with a friend of Deming who advocates to do so and he goes well beyond with what he called SOPK (System Of Profound Knowledge) - but I think your "First Principles Thinking" may be misleading : for complex systems you cannot deduct everything from just facts and logics rules, Deming insists (as well as others like the great scientist Henri Poincaré in his writing "Science and Hypothesis") that you always have a THEORY behind and that Science is about EXPERIMENTING to make your theory WRONG so as to ADJUST it. So he invented for non-scientific people his Deming wheel or PDSA : Plan Do Study Act (which is the true essence of Kanban - Toyota created Kanban to win the prestigious Deming prize after WWII)

And since you mention epistemology indeed Deming learned with Walter Shewhart who wrote a book on the subject as he was worried about the way statistics are misapplied in the real world including by scientists as they think that math + datas alone equates science which is wrong and that can lead to biases (like in pharmaceutical industry where studies show that many "scientific" studies made by corporations are 4 times more positively conclusive than by public laboratories).

epistemology

In software it's even worse as no stats are not even involved but opinions : there are many cults under the guise of "best practices" which people follow blindly or even by social pressure (which is weird in a technical field) see for example overreacted.io/the-wet-codebase/ or interest in disguise (for example Håkon Wium Lie being accused of abusing his position in w3c according to this article polylogue.org/#:~:text=Paged.js%20...)

Collapse
 
adityapadhikbl profile image
Aditya Padhi

Nice Article @swyx .
I am also experimenting with Svelte. I came across few scenarios like graphql support, UI components for rapid development etc.

If we have support for these then I think it will be more fun to develop apps with Svelte.

Collapse
 
unicorns profile image
Unicorns

I think you have it reversed, it's not just about shipping less code, it's about shipping performant code. Web apps require more re-renders than sites, the more re-renders you have the more performance cost React increases.

On a side note, it's troubling to see how "write once, ship anywhere" development is increasing non-performant apps on mobile & desktop. Majority of them are electron or built on something similar.

Collapse
 
swyx profile image
swyx

react prioritizes correctness over performance. performance is not everything.

Collapse
 
unicorns profile image
Unicorns

So do every other popular framework, not sure what your point is there. Performance is the major factor for apps & websites.

Not hating on React, Vue or Angular but it's time to move on or change the internals. They have popularized component based development. Backbone, underscore and friends did it before them but when React & others came into existence, everyone noticed the benefits and made the switch. Now, we have better frameworks & tools than React, Vue, Angular, etc so it's time to move on and adapt those. In future, if something better than svelte comes up then as a web community we should promote them.

Faster, performant & accessible web is what we should push towards.

Collapse
 
alekseiberezkin profile image
Aleksei Berezkin

How Svelte is different from all others templating engines like Angular, Vue and Ember? Why people are so excited about it? Just another HTML with loops and conditionals.

Collapse
 
swyx profile image
swyx

i don't have the energy to get into this. you can make up your own mind, I don't need to convince you.

Collapse
 
alekseiberezkin profile image
Aleksei Berezkin • Edited

My apologies if it sounded like a trolling, I'm not here to mock anything. I heavily use React in production, however I'm open to new things. There was some hype about Vue, I wanted to try it, but now it seems Svelte is in trend. I watched a couple of tutorials but can't decide. Perhaps I just don't see something important? I'd be glad to change my mind.

Thread Thread
 
pavelloz profile image
Paweł Kowalski • Edited

Good point of start is looking up Youtube: RIch Harris. He has 2 presentations about the differences. At least thats how i got into it. One is with "Reactivity" in the title, the other one i dont remember, but there are only couple anyways :)

Thread Thread
 
peerreynders profile image
peerreynders

Rich Harris - Rethinking reactivity
The Return of 'Write Less, Do More' by Rich Harris

Virtual DOM is pure overhead

To me Svelte feels more like a logical extension to the technologies of the web platform (though there is always room for improvement) while React exists in it's own universe.

For some perspective this might be useful: The Real Cost of UI Components

Collapse
 
urielbitton profile image
Uriel Bitton

Nice article! I love react and use it on all app dev, i would occasionally use it for websites but mostly personal ones, for clients, they usually prefer wordpress and its tough to integrate react with wordpress!

Collapse
 
weakish profile image
Jang Rush

Nice comparison! I want to translate it to Chinese. Can you give me the permission to so?

Collapse
 
swyx profile image
swyx

please go ahead let me know when you're done and I can link you!

Collapse
 
weakish profile image
Jang Rush

Just finished and published the Chinese translation at the weekend: nextfe.com/svelte-for-sites-react-... There is a back link to swyx.io/svelte-sites-react-apps/ at the beginning of the translated text.
P.S. During translation, I noticed that "hundreds more" was linked to github.com/sveltejs/community/tree..., which is 404 now. I changed it to github.com/sveltejs/community/tree... in the translated text.

Thread Thread
 
swyx profile image
swyx

wow thank you!!

Thread Thread
 
swyx profile image
swyx

wowww thank you very much! and i have linked back to you from the top of my article. so glad you enjoyed it and hope it reaches my fellow Chinese devs!

 
codechips profile image
Ilia Mikhailov

Totally agree. However, it requires courage and an open mind. Also helps if you've been in the game for some time too. Herd mentality and FOMO are strong. You are running in the opposite direction than everyone else and that can be scary.

 
renanmouraf profile image
Renan Moura

This! I only see the truth in this statement.

Collapse
 
alaindet profile image
Alain D'Ettorre

Taking this as a personal preference, I respect collegues who go into the wild with React but I've chosen to use Angular for most of my frontend work and despite some criticism it works very fine. The ugly: boilerplating everything, documentation somewhat lackluster in some cases (looking at you, router!), tends to be verbose, generally less packages online, quite big bundle without treeshaking, that damn "providedIn" key of @Injectable, no official packages for native devices, people confuse it with AngularJS, less "cool". The good: forced TypeScript, some inherent structure, any basic-to-intermediate need is covered by the core packages, easy to update to newer versions, creating libraries is easy. The exceptional: working with forms in Angular saves you a big deal of time, properly using Observables is just plain amazing especially with time-related stuff (debounce, throttole, sequentiality), schematics and CLI scaffolding do a good job.

As for Svelte, I believe it is a very cool library because it seems to shift the attention to doing the least possible and do it very well, especially at build-time. We'll see if it will disappear or not anytime soon.

Collapse
 
andrewbaisden profile image
Andrew Baisden

As good as Svelte is it still needs to gain more adoption before it is truly accepted outside of developer circles. Still not many commercial jobs available for it outside of personal projects. And I'm betting many companies and recruiters have never even heard of Svelte. It took a while for Vue to gain awareness.

Collapse
 
kokizzu profile image
Kiswono Prayogo

SvelteNative~

Collapse
 
swyx profile image
swyx

do you understand the difference between NativeScript and React Native's approach?

Collapse
 
kokizzu profile image
Kiswono Prayogo

yes i prefer nativescript approach

Collapse
 
rfinner profile image
Rob Finneran

I would enjoy reading your explanation of the differences between NativeScript and React Native's approach. Thanks!

Thread Thread
 
swyx profile image
swyx

I can't because I've never used NativeScript lol. I just suspect that most pple are giving svelte native too much credit for what it is

Collapse
 
phantas0s profile image
Matthieu Cneude • Edited

To me, the real question is: was it more "difficult" to build an app before React or Svelte? jQuery wasn't that good, for sure, but I mean I saw frontend developers using vanilla JavaScript with great success for apps and websites.

I still wonder if focusing on the tool is the good idea. Not that many people care about that, at the end.

Collapse
 
ajcwebdev profile image
ajcwebdev

So you're saying Svelte should conquer the Jamstack?

Collapse
 
swyx profile image
swyx

idk about conquer but i do think more people should try it as it is a great fit for the Jamstack

Collapse
 
codechips profile image
Ilia Mikhailov

Not sure what side you are referring to, but thanks. I took the path of least resistance 🤷‍♂️

Collapse
 
lil5 profile image
Lucian I. Last

I’d even go a step further and say that AlpineJS is more suitable for web-sites and to try svelte for web-apps

Collapse
 
victoredier profile image
Victor Edier

Why don't you just use HTML as programming language?????

Joking please don't kill me

Collapse
 
catalinradoi profile image
CatalinRadoi

ASP.NET MVC FTW

Collapse
 
Sloan, the sloth mascot
Comment deleted
Collapse
 
swyx profile image
swyx

do what makes you happy man life is short