Author here, just wanted to make a note. This isn't written to hype a battle in the holy war. Frontend frameworks are a positive sum game! Svelte has no monopoly on the compiler paradigm either. Just like I think React is worth learning for the mental model it imparts, where UI is a (pure) function of state, I think the frontend framework-as-compiler paradigm is worth understanding. We're going to see a lot more of it because the tradeoffs are fantastic, to where it'll be a boring talking point before we know it.
Thanks for your work. I watched a few presentations this week and read quite a bit. It looks very promising, and I'd be happy to start migrating my components to Svelte step by step. I'm a Rails dev, and there's a Rails integration through webpacker already. What I'm waiting for is TypeScript support. Once that's officially released, you can count one covert more :).
It's not a comprehensive weighing of alternatives, instead it's a deep dive into Svelte's pros and cons as they relate to my experience and our project.
Elm is awesome! There's nothing quite like it that I know of in its design space to bring user-friendly functional programming to the web. Similar to Svelte, its design holistically packages up the web's languages. Compared to PureScript, it's focused on a small and beginner-friendly feature set, trading general power to optimize for the webapp use cases. Elm has also been influential to a lot of toolmakers!
Sure, thank you for the question! It prompted me to add a note about Elm and Dart in a relevant section in the document.
One important difference with Svelte versus Elm is that Elm makes a clean break from web technologies, while Svelte is designed to work with future versions of the web's languages.
These are the complaints that standout for me with Svelte after using it for a few months:
* Sub-par editor support. For me, the litmus test is whether I can use F2 to rename a variable, and it often does not work inside a Svelte template. There are other places where the editor does not know what to do with your code, because it is not pure JS. Vue is much worse with this since so many things are just strings; React really shines with editor support. This makes a big difference when you are using a large project where you didn't write the code.
* I don't love that you have to re-assign a object/array variable to get Svelte to notice it changed, and you can do that inside a Svelte template to a const variable and you won't get a complaint from the compiler.
* Much smaller ecosystem compared to React and Vue, which is expected at this point.
Other than this, I absolutely love Svelte. Stores are such an amazing abstraction. Animation is well thought out. Storybook works perfectly. Mostly it is pure JS once it gets inside the browser, so you can debug effectively which is not the case with Vue for example.
Since you've been using Svelte for a few months after using React, haven't you been hit by the lack of composability in Svelte?
Passing around components as variables is such a common pattern in React, and there's no good replacement in Svelte. The lack of dynamism in components and styles makes theming and crafting reusable components (outside of simple widgets) very tedious [1][2]. I'm genuinely curious how someone can come from React and not be bothered by it.
It's a great point. I'm not bothered by it only because I'm not using react professionally right now and don't use that pattern. Thanks for bringing that important point up.
The simple usage of passing a component to a component, which almost every decently-sized project will make use of, has no convenient syntax, only workarounds:
// parent.svelte
<script>
import Nested from './nested.svelte'
import Child from './child.svelte';
</script>
<Child>
<div slot="bar"> <-- Extra wrapper DOM node
<Nested foo="Foo"/>
</div>
</Child>
// child.svelte
<slot name="bar" {...data}/>
Passing down an element as a prop requires separating the component constructor and its data and manually re-conciliating the two in the child component every time, since components can't be rendered from functions. It works but it's unnecessary boilerplate.
// parent.svelte
<script>
import Nested from './nested.svelte';
import Child from './child.svelte';
</script>
<Child nested={Nested} nestedData={{ foo: "Foo" }}/>
// child.svelte
<script>
let export Component;
let export componentData;
</script>
<Component {...componentData}/>
But yea that's indeed what I should have done in my example if I wanted the component to be reactive, as you can see that's even more verbose and still doesn't take care of props.
And, isn't it likely this will be easier to support with Svelte eventually? My reasoning is that you just need to add a little syntactic sugar to the language and the compiler can add whatever code is necessary? With a runtime like React and Vue, it seems much harder to add in.
It's think it's likely the two issues I highlighted will eventually have syntactic sugar, I never wrote a transpiler but it doesn't seem that hard to support. It doesn't appear to be a priority though.
> With a runtime like React and Vue, it seems much harder to add in.
As a rule of thumb, it's almost always easier to add things at runtime than at compile time. That's why it took us so long to get Rust.
On your 2nd point, you can tell Svelte that your data is mutable, in which case it will do deep equality. However, the benefits of immutable data often mean it's worth just reassigning the variable.
I also wouldn't consider that a disadvantage vs React/Redux, since that also requires using immutable data.
On point 1, this issue is the one to watch. https://github.com/sveltejs/svelte/issues/4518 Language server support will work for both JavaScript and TypeScript and error/type checking and editor support should be pretty comprehensive when it's ready. Svelte 3 was written with TypeScript in mind, so the idioms are fairly compatible with type checking. (a nice pit of success for design!)
This should also fix reassigning to a const mentioned in point 2.
For me, the biggest downside to Svelte is the lack of TypeScript support. This is a massive deal-breaker for myself as well as many other developers. I am also not a fan of the Moustache/Handlebars inspired templating, it feels outdated in the face of enhancing standard HTML or going in the direction of something more extreme like JSX.
I think Svelte is refreshing, but I would not be comfortable using it on a large-scale web application just yet given the downsides, particularly an enterprise LOB application with many moving pieces. This is why frameworks like Angular, Ember and Aurelia on the front-end lend themselves better to the enterprise and React and other more component-based libraries do not.
In terms of community size, I don't think that matters in 2020. You don't need a big community if you have something straightforward and easy to work with. Great read.
It's buried in the article, but TypeScript support is being worked on by one of the TypeScript team members in collaboration with the Svelte devs - https://github.com/sveltejs/svelte/issues/4518
The template language's restrictions compared to JavaScript/JSX-built views are part of Svelte's performance story. It's able to optimize things ahead of time that are impossible with dynamic code because of the constraints. Here's a couple tweets from the author about that -
The Svelte template language is quite small, and compositional features like slots and <svelte:component> are powerful. There are currently some unwanted edge-case restrictions as this comment points out - https://news.ycombinator.com/item?id=22541100
I submit that Typescript is largely overrated, adds unnecessary complexity and fails to catch a large number of issues at compile time that it should in fact catch.
I'm rapidly becoming a huge Svelte fan. Quick self-promotion plug (but in the name of altruism): I've been working on an open source project that glues together Svelte (on the front end) and Crystal (on the back end).
As someone kind of sitting on the sidelines waiting for Crystal to gain some traction before I dedicate time to learning/working with it, I appreciate you for digging in and moving things forward.
I enjoyed learning Svelte; it was fun to use when I rebuilt a personal project from scratch using it[1].
I'm trying to think of some downsides to balance my enthusiasm for the framework, but can't think of any. The article mentions the smaller community as a possible issue, but the community on Discord seem very welcoming.
Re "using Svelte means adopting a new language" - it didn't feel like that to me. Every framework has its own way of doing things; Svelte's way didn't annoy me as much as some other frameworks have done in the past (eg: Angular before it became Angular2).
I've got another personal project rebuild coming up - I reckon I'll be treating that as an opportunity to learn more Svelte.
> Re "using Svelte means adopting a new language" - it didn't feel like that to me.
Me neither, but I've been around long enough to remember the handlebars.js days. To someone that's only used React I imagine that at first sight things like {#if} {/if} look ugly as hell. To those people I can only say to stick it out: it starts to feel very natural very quickly.
This was my experience. I've been working with Vue for the last few years so Svelte's syntax for loops and conditionals looked a bit funky...but after using it I realised that it's a lot more readable and enjoyable to work with.
I LOVE what svelte is doing. I've been using React daily for the last 5 years & it does the job, documentation is world class, community is great, but it still has sharp edges & parts that feel bad. Things like hooks make complicated things look & feel simple, which is great for 80% of my work, but for that other 20% (exit animations, high frequency re-renders, drag-n-drop without HTML5) I do some pretty atrocious things to make it work. This is where svelete shines.
The readme does a good job of pointing out its shortcomings, too. Primarily, no typescript support yet & the unknown bundle size inflection point. As soon as these are solved, I can't imagine it not becoming the best (albeit not most popular) solution.
Having used Svelte for a couple of projects [1][2], I love it. Compared to my day job working in react/redux, it is much simpler, and feels like it has far less boilerplate.
There are certainly a few rough edges, but it's all related to the immaturity of the language. Specifically, I had a hard time understanding transitions and it wasn't at all obvious how to integrate it with D3. Hopefully as it grows we will see improved docs and examples.
Also, I'm holding out for more mainstream TypeScript support. At that point, it would be hard to convince me to use anything else.
I do use Redux Toolkit, but it really can't compare to Svelte. There are so many moving parts in a Redux app that there's only so far it can be simplified
I watched a tutorial by the author Rich Harris today after reading this link on HN earlier and stopped when he started talking about a DSL he created for Svelte so you don't have to write as much JS. I don't want to learn another DSL. I don't see what the big deal is about compiling. We've have many languages that compile to JavaScript and Google Closure Compiler to tree shake and minify. For years now! Svelte is a nifty DSL to JS compiler that produces small bundles because there is no SDK to back it up or include. Cool, I guess.
Svelte is a component compiler, not a general language compiler. Big distinction! Being purpose-built for this use case opens up a lot of opportunities.
The article goes into this more, but Svelte's DSL is an extension of web languages - not much to learn really! Your existing knowledge of HTML, CSS, and JS transfers directly.
I dislike the templating pseudo language of Svelte (and many view frameworks). Maybe I am spoiled by react but I never ever want to write my view logic in anything else than JS. This is my main blocker for Svelte.
I've never fully understood this viewpoint, which comes up a lot in relation to React and JSX specifically.
The templating in Svelte and Vue is (almost) html with some magic sprinkled here and there, so much closer to the end result. Using JS for everything is moving further away from the metal.
What is it about writing views the React way that appeals to you more?
> What is it about writing views the React way that appeals to you more?
JSX is JS thus it's powerful. I prefer to use JS to "sprinkel the magic", rather than using yet another (awkward) template language. Using JS for everything is keeping my mental consistent. I enjoy getting full editor support for the entire app (typing (via TS), warnings, auto-suggestions, etc...). Overall it feels more consistent, more composable and more functional (as in Functional Programming) to me.
What I found on several consecutive projects was that less the HTML generation resembles the final HTML, the harder it is for people to keep the CSS selectors wired up correctly. Getting text into the page as fast as possible at the cost of layout issues is a sucker's bet.
You can't ship until it looks good, and the longer features are in-flight the worse management feels about the team's abilities.
Two of the projects I'm thinking of used Sass or Less. The problem is on figuring out why you have black text on a black background because your CSS selectors no longer match the DOM structure, when the DOM structure is split up and/or not even HTML-like anymore.
You don't want situations where senior staff have to intervene on what should be a straightforward issue. It gums up the works.
I dislike Vue and similar templates because the result is not used as HTML, it's used as JS to generate HTML, but tries to imitate HTML. I feel the same way about JSX.
IMO a just a simple function/array based templates work better like this that I have used recently:
To my mind the templating language isn't that different to JSX, <div class={classNameVariable}/> and all that. I agree that if and else statements feel a little less natural but for me it's more than worth the price of admission.
I love svelte. but now resorting to server rendered html pages with sprinkles of JS. shit I work on and I have noticed in the world doesn't really need frameworks like react, svelte, vue etc.
Same. I haven't done frontend work for a job for about a decade, but kept up to date with things like Angular/Vue/React. I was recently vountold by my wife to create a reunion site for her class. I looked up "barebones front end frameworks." Anything that began the "Getting Started" page with "npm install" I noped out of there.
I ended up with Skeleton/jQuery for the front end and PHP Slim for the backend. This is a 5 page, 2 forms, site targeted at 100 people. There's no need to SPA this, npm that.
You seem to be refuting a straw-man argument here. Why would a hobby site provide a counter example for people talking about work they do for their employers?
No rational person would advocate using Svelte or React for a static, one-off, informational site to be maintained by a single person.
In fact, you didn't even need jQuery at all. Vanilla JS works across browsers in a way that it didn't when you learned web coding 10 years ago.
Where frameworks become useful is for large projects that many people work on over a long period of time. Turnover is an issue for non-standardized code, as is poorly organized code.
And none of that even touches on security, which absolutely requires libraries, packages, and many of the other benefits of reusing the ecosystem that you seem to eschew.
> No rational person would advocate using Svelte or React for a static, one-off, informational site to be maintained by a single person.
This is where we disagree, and I think that's the problem. In my use case, I just wanted an HTML template file with at most a few CSS files. There's a dearth of those frameworks/templates compared to bigger packages.
Someone on HN recommended it to me before, so I’ll just pass this along: look at intercooler JS for making individual “live widgets” on a well-designed graceful degradation site like you describe.
Also Alpine.js, which has got quite a community behind it (somehow promoted by Laravel, IIRC).
It is less than intercooler, but provides timesavers for simple sites like described. A compromise between a framework and none.
Calling Skelton a dependency is ludicrous. It's just an HTML file with a CSS file. Look at every other "lightweight CSS framework" - Specture, Mustard UI, etc. They all have dozens and dozens of files where you need a package manager.
The whole point was that it's simple enough that I don't have to deal with a package manager, and a lot of projects don't need to.
The whole point is that you choose an arbitrary thing to treat as a dealbreaker that doesn't really make a whole lot of sense. "npm install jquery" would have given you the exact same result you have, except it would have violated your dealbreaker. It just doesn't seem particularly logical to me.
To be honest, if you're going for "as simple as possible" there's no reason to use jQuery at all these days, it's a waste. Modern browsers have perfectly capable APIs!
Svelte can do server-rendered and static page generation with the near-zero overhead of string concatenation, and with it you gain the component model. Part of the magic of compilers is that you can get most of the best of both worlds. Sapper provides both of these use cases.
I worked as a fronted dev, so I know this problem very well. Server rendered pages, I don't mean Sapper. But the ol' rails erb, or flask jinja templates type of rendering.
What I'd hoped to see here was why use Svelte for a large web project. I get the advantages, but devising and maintaining good architecture is hard enough in the more established React paradigm. What do complex and older Svelte apps look like? This is the part that's missing for me, not pleasant DX and early-web nostalgia.
Good question, thanks for asking it. I didn't explicitly address this (oops) and I'll have to do some more thinking. My first reaction is that:
1) Svelte gives you a solid foundation and lots of flexibility
2) difficulty scaling for large apps is mostly orthogonal to the component library
3) Svelte provides flexible and sugary integration points for these orthogonal concerns
For example, since we're talking large projects, the biggest concern is state management. Svelte is like React here, in that you could use MobX or Redux with a connector library, or RxJS with Redux, or other combinations. As long as your solution is compatible with stores like RxJS is, you benefit from Svelte's auto-subscriptions[1] and sugary store dereferencing[2] that's agnostic to your underlying state management solution.
Ah, I mentioned it on Twitter [1] somewhat prompted by seeing this article, but before reading it, but:
> It's interesting that Svelte is positioned as a Javascript framework: it seems to be practically a different language, far more so than JS+JSX.
> The downside is that it's hard to integrate with much of the Javascript ecosystem, e.g. TypeScript.
> Yet at the same time, it doesn't fully embrace being a different language, so it does not add features like e.g. how Elm supports pattern matching.
> It does make it an easier sell, I suppose, which does certainly count for something. Am I missing something else?
After having read it, it does seem that the author does both consider it a separate language, but also still presents it as a JS framework. I wonder if the former isn't being underestimated?
Going back to React a week ago after doing Svelte seriously since Oct 2018 is tough. Asides from the obvious stuff - Svelte's speed and bundle a size of 0: JSX isn't HTML, using weird helpers to enable a class when a JS ternary would do fine, setting state is clumsy, and there's way too much complexity if you're not already used to using React.
That said, I'm also really enjoying TS so could understand why someone may want to stick with React for a new project until Svelte gets TS.
I love many things about Svelte but after using Vue for a couple of years I wouldn't go back to single file components.
The idea of having markup+logic+styles in the same file works for small components but it gets muddy on bigger ones. It can be argued that components should be as small as possible but OTOH having to create a new file for every damn component gets old very quickly.
For the past 2-3 years I've been working again with JSX based libraries and being able to create micro components on the same JS file makes a lot more sense.
I've also gone back to regular SASS and moved all CSS outside of components (except for dynamic CSS). It works better IMO than single file components.
I like what I see from Svelte but I'm afraid it's going down the exact same road Meteor did.
Too many options, not enough Blessed Solutions for basic things.
Take routing for example, in Svelte you have a lot of options but no real #1 "Svelte Recommends (tm)". They should solve this problem before it gets out of hand. It killed Meteor.
Frameworks like React aren't the real headache today, for me at least. It's all the machinery of web development. Webpack, babel, polyfills, various CSS transforms and ways to utilize CSS (sass, less, CSS modules, CSS inline, the list is a mile long).
My organization has tossed so many manhours into maintaining webpack and our build that you could recreate our entire site numerous times over in a bog standard LAMP stack with a fraction of the headcount. The cost of a modern web dev stack is no joke. And for what, I might ask? The UX of a single page app is atrocious. The canonical example of SPA done right is Google Maps. Ever tried Google Maps on a mobile browser? There is a reason the native app still exists.
SPA is, at best, a desktop-first experience that we're trying to force into a mobile-first world we live. It's nearly the definition of insanity, what we're trying to do with the web today.
In the process of everyone following Google and Facebook, we are also destroying the essential ingredient of the web: links. Everything is a walled garden with internal state and incredibly fragile external links (if any at all). Pinterest and Quora, everywhere. What will define the web of the 2010-2020+ is that everything is broken and everything sucks.
>For those who can't live without a framework: What would you miss?
Well, my favourite of choice is Elm, and it's correctness guarantees are really a huge deal to me. Whenever I have to do react or even just vanilla js for work, unless it's really miniscule I will nearly always run into runtime errors because I just forget to check something for null or do something stupid like not awaiting a promise (and that's before any other developers get involved). Typescript helps out a certain extent but I find it isn't nearly prescriptive enough. It's not like I'll ever convince my company to adopt Elm though (and believe me, I tried), so c'est la vie.
Although I suppose these might be considered different languages rather than just a framework, which is where the benefit comes from? It might be just that I'm not very good with dealing with JS as a language rather than needing a framework specifically.
> For those who can't live without a framework: What would you miss?
The thing I miss the most is a good component and state abstraction. That's it.
I would be very happy using ASP.NET WebForms today: components are rendered 100% in the server but the state is persisted by the client using a <input type=hidden> field. The server can be 100% stateless.
Too bad it is impossible to convince anyone to pick up ASP.NET WebForms in 2020 :)
Modern backend frameworks such as Rails and Django have similar "component-ish" helpers, but those always fall short of the capabilities of both React/Vue and ASP.NET WebForms, and you have to worry about state by yourself.
Phoenix Live View is cool, but needs a stateful server, requires JS and polyfills up the wazoo. At this point I'd rather use Vue or React.
part of our code base is a bunch of webforms, it really does work quite well and surprisingly easy to work with in many cases. Would've been interesting if they had kept innovating around the concept.
I go back and forth on this all the time. We have a variety of projects at work and relatively few bodies working on them. Definitely more projects than programmers.
Part of me feels like using "overkill" frameworks for everything is a better bet. It builds more familiarity and expertise. It certain makes some projects more complex than they need to be, but it makes it easier to switch from project to project.
I'm in a similar state of mind as you. Any time I start a web project now I just write vanilla JS and none of my hobby projects has yet to reach a point where I wanted a framework. There have been a couple times, particularly dealing with interactive forms, that I found myself writing a lot of the same code over and over again. I think this would be the first place I would start to build my own little framework. But it hasn't yet made me want to introduce React or Angular to the project. Especially when I consider the hours of free time that I would spend on setup rather than building the actual project itself.
Svelte is not like other frameworks. The core is basically one thing, which is to generate code that updates components when data they depend on changes, just like you would do it yourself when not using a framework. There is no runtime or shadow DOM or anything.
That means you can write in a more functional style: input data -> output HTML+CSS.
Svelte isn’t reaaaally a framework in the way React is, although they do share some commonalities.
It’s pretty innovative in that it’s not really big JS bundle, but more of a compiler for what is essentially quite vanilla JS code. In the end, if you use Svelte, then your final product will be pure HTML/CSS/JS.
I love it because it lets me bundle logically related markup, styling, AND javascript in the same .svelte file. Plus, it’s blazing fast.
I am on a team that has chosen Svelte to replace Riot.js. It has been an excellent experience. We have found that since Riot and Svelte have some similarities in structure and do not use a shadow DOM, we that our old Riot code and new Svelte code co-exist while we build new features and slowly migrate everything.
Our team has diverse experience with the other tools in this space. I would say that the consensus is that Svelte is far more intuitive and fun than other tools.
Shameless plug. I've choosen svelte for webextension that will be allow you to record, replay and modify requests on the fly. I've choosen Svelte, because 1. courisity and 2. it can compile to webcomponents and also reference webcomponents in normal svelte components. I discarded the webcompoments for everything idea, mostly because clunky passing and registering events with svelte (svelte issue). There few thing that needs to be polished, like typescript support and this events handling with webcomponents, but overall, very satisfied with svelte so far (as former React guy).
I enjoyed the brief period I spent playing with Svelte. I ran into some bugs with the built-in animation support when changing states (there's built in animation support for changing states!) that I couldn't resolve, and which were pretty glaring in the UI. This was 6-9 months ago, though, so it may well have been fixed by now.
I'd really encourage all front-end devs to take Svelte for a spin, if for no other reason than to see a framework really trying to do things differently. There are a lot of nice ideas in there, and the works-out-of-the-box level is admirable.
> Svelte is one of the 6 JS frameworks in the (flawed) State of JS 2019 survey — 75% have heard of it, 7% have used it, and 45% are interested in learning more
Why is it flawed and why are you citing a flawed study? You mention that it's flawed twice but then immediately cite data from it. If you're telling me it's flawed why should I care about the data?
I considered linking or footnoting that text and probably should have.
Like all surveys, there's a selection bias. For example where are the world's millions of jQuery developers?
There's also a lot of controversy around Angular's treatment in the survey and an alleged pro-React bias. This shouldn't affect the Svelte numbers much.
Thanks for bringing it up - I'll improve the text somehow.
hate all frontend compile steps from a developer productivity perspective but love it from a user value perspective, especially if that enables JS-disabled browsers to more or less use dynamic sites
Slightly offtopic: Why a git repo for a blog post? I guess there are some pro's: public history, PR's , but a blog has comments directly under the article for example. Forking is not expected. Ah well, extensive information anyway, good work :)
Especially excited to consider a solution without huge runtime libraries (think jQuery, React, Vue). Minimizing web page sizes and enabling dynamic content (which is a mainstay in modern websites) is a huge plus.
> React 16 is 2.2 KB or 34.8 KB if you include react-dom
Gzipped. Uncompressed React is 6.3KB and react-dom is 114.5KB (and of course you're going to include react-dom, how else would you use it?!)
Uncompressed matters because it takes a device longer to parse more code. Particularly in a world where low end Android devices are being shipped with slow CPUs and very little RAM.
The real killer combination is React plus a giant blob of state that has to be parsed, and then hydrated into individual elements. It's a giant, giant waste of CPU time that is acceptable on my iPhone XS, but when I plug in a Nokia 2 it's horrifying. VDOM itself is needlessly CPU intense in many ways.
Even if you don't want to use Svelte it baffles me that more people don't use Preact. 9.5KB uncompressed and it does 95% of what React does. But people just don't seem to care.
I use Preact for small apps and demos, works really well for that! For larger projects I still prefer the real React library because there are some edge cases where Preact does things differently (can’t remember what exactly but I remember that I ran into some problems when trying to migrate a large react codebase to it).
> Uncompressed matters because it takes a device longer to parse more code
This is...a trivial thing to measure, at best. Engineers write way worse code that will be much bigger targets to care about that will likely never be worked on.
> Particularly in a world where low end Android devices are being shipped with slow CPUs and very little RAM
The benchmarks for this (todomvc for example) aren't egregious, even for mobile devices.
> The real killer combination is React plus a giant blob of state that has to be parsed, and then hydrated into individual elements.
That is a bad end-engineer design choice, you don't have to write react that way.
> But people just don't seem to care.
Because they largely don't need to: Even if the end-engineer wrote and designed things in a performant way, it wouldn't account for the slowness of business process.
So I guess the answer is "things are going to be bad, so why bother optimising?". I guess I can't really argue with a self-fulfilling prophecy like that. Not considering the size of a JS library because the business process is slow? Oh... kay? Just feels like real lowest common denominator stuff: why should I do good work when someone else isn't?
FWIW I did Lighthouse audits on React TodoMVC and Svelte TodoMVC In the performance category React gets 74 while Svelte gets 100.
First contentful paint:
React: 3.8s
Svelte: 0.9s
Time to interactive:
React: 4.8s
Svelte: 0.9s
I can't make you care about this stuff but the numbers are very straightforward.
I love svelte on the personal/toy projects I've tried it on, but does someone have an example of a large-ish svelte codebase with an example of a testing pattern that they've found works?
Using mithril/vue/react, there are assertions you can make about how a given action will modify the state, and given some state, how that state will be rendered.
I've not found a good way to make assertions on the behavior of code without resorting to poking through the DOM and dealing with asynchronous behaviors.
I love the idea of svelte and want to try it on my next project.
The compiler paradigm is really powerful. What if you could extend Svelte to give it knowledge of your db schema and it would figure out an optimized way to load data by generating all that code if needed. Probably something like this exists already somewhere and was forgotten about, but one can dream.
How is it that 23 hours in and nobody is pointing out that svelte/sapper just freezes on runtime errors without the ability to show an error page or report them to a tracker like sentry/rollbar/etc.? This is one of the biggest barriers to being production ready or fit for use in large projects.
The one thing that gives me reservations about Svelte is that the description about how code turns into web pages makes me wonder if there are any problems with code-build-run-test cycles.
I'm concerned I'll spend all of my time restarting my application to validate changes. Is this a non-issue?
The lack of a large and mature ecosystem would prevent me for starting a "large" web project. Svelte is still missing UI frameworks like Material UI or Vuetify. Won't you need date range picker ? Full powered data-tables ? Treeview ? Advanced cards or other layouts ? Awesome effects / styles for a rich UI ? Svelte Material UI is a start : https://sveltematerialui.com/ But I will definitely give Svelte a try for my next "medium" size project.
Hey - Svelte Calendar actually has an open PR for a date-range picker which just needs a bit of testing to get it over the line. Feel free to take a look
As for the other components, as the ecosystem grows, these things start to appear. The advantage to Svelte is that it's super-easy to integrate any vanilla component into, much more so than other frameworks. You can totally do away with nonsense wrapping projects, and just add the component verbatim.
does svelte have a way of hiding the .svelte components from the users on the frontend? e.g. so they cant blatantly rip the source code in your components and reuse them
This isn't specific to Svelte though. In fact your code is much more obfuscated with Svelte than with most comparable tools, since you're not serving the code you actually wrote, but rather the output of a compiler (while this is technically true if you're using TypeScript/a minifier/whatever, it's qualitatively different).
It actively encourages mutability, which is a one way avenue to bugs bugs and more bugs. ie, shit like this is all over the official documentation:
<script>
let mutable = 1;
function f1() {
onMount(() => {
mutable = /* do some complex shit here */
});
}
function f2() {
onMount(() => {
mutable = /* do some complex shit here */
});
}
</script>
<Component onclick={f1}>
<Component2 onclick={f2}>
</Component2>
</Component>
Complete non-deterministic state changes. Absolutely abhorrent stuff. Cannot believe my coworkers and others actually like using this absolute garbage of a framework.
Hey, could you please stop posting in the flamewar style to HN? I'm sure you have a point here, but it gets lost in the inverse-shit-sandwich thing (flames on the outside, point on the inside).
If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the spirit of this site more to heart, we'd be grateful. The idea is curious conversation, and you'll be better able to persuade others about mutability that way anyhow.
Nothing IMO but a lot of folks argue that using immutable state and functional paradigm results in more predictable applications.
Not sure if all this immutability talk in the JS community is parroting because "it's what Facebooks does" or what. Maybe it makes sense once you are building really big front end projects but personally I've never had an issue with mutable state in small to medium sized projects (less than 50k LOCs). Although I admit I've never worked on a Facebook-scale kind of project.
I was thinking the same thing at first, why have this monstrous global state which is against every good practice you have ever heard of.
But then, if you want to keep state when switching between pages, you need to hoist up that state to the parent component.
At some point, there's going to be a component near the root that keeps a lot of state for its children, that then has to be trickled down the component tree.
If you don't need to reuse those components in a different setting, then the redux solution feels quite ergonomic.
Now, this is coming from an embedded C programmer point of view, and this is my first foray into react/redux, so I'm obviously lacking context.
But we're writing a front end for our embedded device, and I have to say I am pleasantly surprised with the experience.
Also, note that we have a new Redux Toolkit package, which is intended to simplify many common Redux use cases, and is now our recommended approach for writing Redux logic:
