Translations: 中文版
In 2020, my personal recommendation to web developers is to use Svelte for Sites, and React for Apps. This is, remarkably, a n...
For further actions, you may consider blocking this person and/or reporting abuse
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.
i dont agree with the premise of the question, but fwiw my list is in the blogpost. here is a summary.
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.
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.
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.
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.
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.
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
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:
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.
React also has significantly more developed meta-frameworks.
yeah I count that as part of 3rd party ecosystem advantage
Better implemented in React:
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.
These are "developer experience" related opinions, nothing to do with the output for the end user.
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)
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.
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...
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."
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.
Naahh... React Elements ... which if I understand correctly are more generally vnodes.
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.
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.
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.
If you are talking about compiled Javascript (e.g. es5, minified), I think it is always Hyperscript, not JSX.
Everybody is different.
deep
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.
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.
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.
hence my point about Islands Architecture and Elder.js. We agree!
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.
can you TLDR the alpine results? I find this table hard to read
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:
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:
Or updating every 10th row with some additional text:
Finally looking at runtime memory with all list items on the page Alpine is middle of the pack again:
*** obligatory disclaimer: this is a single benchmark scenario and not representative of all realworld apps... yada yada...
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.
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.
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.
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.
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.
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.
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!
JSX is an ugly mess, using both Vue and Svelte very happily but sure ;)
Most designers prefer Vue nothing new here.
Not sure what you mean by this but, I have been doing full stack dev for 20 years.
And 15 of them with Vue.
This doesn't even make sense... oh well
k
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
try to work on your english communication skills. this is not coherent or professional.
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.
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?
I appreciate that you removed "this is a bad take" from your opener.
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".
"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).
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.
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.
Agree. I don't love writing in
.jsxand I find React to have unnecessary complexity for the marketing sites I typically develop.What complexity, you write JS nothing else.
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!!
yayy!! join us!
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!
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.
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).
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...)
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.
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.
react prioritizes correctness over performance. performance is not everything.
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.
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.
i don't have the energy to get into this. you can make up your own mind, I don't need to convince you.
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.
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 :)
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
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!
Nice comparison! I want to translate it to Chinese. Can you give me the permission to so?
please go ahead let me know when you're done and I can link you!
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.
wow thank you!!
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!
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.
This! I only see the truth in this statement.
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.
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.
SvelteNative~
do you understand the difference between NativeScript and React Native's approach?
yes i prefer nativescript approach
I would enjoy reading your explanation of the differences between NativeScript and React Native's approach. Thanks!
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
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.
So you're saying Svelte should conquer the Jamstack?
idk about conquer but i do think more people should try it as it is a great fit for the Jamstack
Not sure what side you are referring to, but thanks. I took the path of least resistance 🤷♂️
I’d even go a step further and say that AlpineJS is more suitable for web-sites and to try svelte for web-apps
Why don't you just use HTML as programming language?????
Joking please don't kill me
ASP.NET MVC FTW
do what makes you happy man life is short