TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Thoughts on Svelte

364 点作者 naansequitur大约 2 年前

44 条评论

rubenfiszel大约 2 年前
We have a pretty huge codebase [1] in svelte for Windmill, probably one of the biggest SPA on it. We are an open-source n8n&#x2F;temporal + retool alternative so we are building both an advanced flow builder and an advanced app builder.<p>The article is on point. There is 1 caveat to animations that I&#x27;d like to add. Everytime we ended up using animation without the `|local` specifier, it broke completely our app, and that&#x27;s an easy mistake to make. It should be the default imho. That&#x27;s because svelte is updating the whole DOM instead of that specific component without it, and it waits for the animation to be observably over to re-render the DOM .<p>For reactivity, it works surprisingly well but for big state updates, and a redux style of having one big state to update, we ended up splitting the state subparts that were independent in reactivity because otherwise you end up very easily into a reactivity hell (reactivity, calling other reactivity). We also have a lot of pattern to keep in check the reactivity on nested objects such as using object comparison checks (using fastEquals) to make sure the input object actually changed and it was not a leaf node unrelated to this component that triggered the change.<p>Overall, with the small team that we are, we could NOT have build such a complex and blazing fast superapp without svelte. On the other hand, we had to become expert at knowing how svelte would actually compile to otherwise we would have been stuck early at using the reactivity bindings after a certain scale.<p>[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;windmill-labs&#x2F;windmill&#x2F;tree&#x2F;main&#x2F;frontend">https:&#x2F;&#x2F;github.com&#x2F;windmill-labs&#x2F;windmill&#x2F;tree&#x2F;main&#x2F;frontend</a>
评论 #35328009 未加载
评论 #35341265 未加载
fenomas大约 2 年前
I switched my game&#x27;s UI from Vue2 to Svelte maybe a year ago, and I agree with almost all of the article.<p>One thing I think the author overlooks: the appeal of Svelte&#x27;s built-in animations and transitions is that they work correctly when the element&#x27;s lifecycle is being managed by Svelte. E.g. with code like this:<p><pre><code> {#if showFoo} &lt;div transition:fly={{ y: -50 }}&gt; Foo! &lt;&#x2F;div&gt; {&#x2F;if} </code></pre> When `showFoo` changes to false, Svelte will first play a flyout transition and <i>then</i> remove the element from the DOM, and it will correctly handle things if `showFoo` toggles back to true again before the flyout finishes, etc. You could do the same thing with CSS animations, but it would be hairy and you&#x27;d need to learn more about svelte internals than you probably want to.
评论 #35326756 未加载
评论 #35326672 未加载
评论 #35325903 未加载
评论 #35335085 未加载
评论 #35326716 未加载
评论 #35327749 未加载
评论 #35329450 未加载
评论 #35327007 未加载
h4ch1大约 2 年前
I&#x27;ve been building a medium-scale web application that works as a configurator for 3D models (swapping objects&#x2F;changing materials) and parsing&#x2F;storing&#x2F;syncing those configurations in real-time along with images, and a lot of metadata that needs real-time updates. To be honest, it&#x27;s a breeze until it&#x27;s not, my single file gets very long, lots of declarations, $: reactive = another reactive variable, derived stores, the dependency graph can get really deep really quickly and it&#x27;s very important to maintain a sort of heading, and plan ahead, because you can really lose yourself building with Svelte because of how little boilerplate there is.<p>Even then, 100% recommend it, documentation, and existing issues are sometimes lacking and information is hard to come by, but the Discord is helpful, even though it takes a lot of searching their &quot;forums&quot;. Have great hopes for its&#x27; future, and it&#x27;s really fun to build tools in Svelte, I remember giving all my Network Security assignments (transposition cipher, DES&#x2F;AES, KDC) a nice, clean reactive front-end showing intermediate states of the data being passed around even though a simple cpp file would&#x27;ve sufficed, just because of how fun it&#x27;s to use Svelte.
评论 #35326177 未加载
评论 #35353069 未加载
评论 #35325705 未加载
spikey_sanju大约 2 年前
I switched from Next.js to Svelte over a year ago. Since then, I have built medium-sized business products, and I can confidently say that Svelte is a joy to use. Their developer experience is on point. I agree with all the points made in the blog above, especially when it comes to working with forms. Svelte makes it easy with its inbuilt store, form actions, pageload, serverload, animations, and all of this results in a blazingly fast app. I even made an open-source version of my blog with SvelteKit.<p>Portfolio - <a href="https:&#x2F;&#x2F;www.spikeysanju.com" rel="nofollow">https:&#x2F;&#x2F;www.spikeysanju.com</a><p>Source code - <a href="https:&#x2F;&#x2F;www.github.com&#x2F;spikeysanju&#x2F;spikeysanju.com">https:&#x2F;&#x2F;www.github.com&#x2F;spikeysanju&#x2F;spikeysanju.com</a>
评论 #35326879 未加载
illiarian大约 2 年前
&gt; Svelte gives you an elegant way to use CSS in your components with &lt;style&gt; tags, why not implement transitions and animations in CSS there?<p>Because CSS has no hooks into HTML lifecycle. If you want to nimate something that appears in the DOM, or disappears from the DOM elegantly, CSS ain&#x27;t it.<p>That&#x27;s why almost every single framework outside Svelte struggles with animations and employs increasingly bizarre and brittle workarounds to make them work.
评论 #35328371 未加载
评论 #35335098 未加载
pavish大约 2 年前
I agree with most of what the author says, except the part about reactivity. I attribute that sentiment to the author being less familiar with Svelte.<p>I do think that people new to Svelte find it hard. It takes a while to understand how the `$` reactive statements work, and when and when-not to use it. When I first started working with Svelte, I tried to do things the React way and shared similar frustrations. Now that I&#x27;ve been working with Svelte for smaller and bigger projects for nearly 5 years (yes, since 2.0), I find Svelte&#x27;s reactive pattern simple and intuitive.<p>There are some aspects I find frustrating with Svelte. One example is being able to pass templates around. With React I&#x27;d just pass JSX, but since Svelte is statically compiled, I&#x27;ve had to create components for such scenarios. Slots don&#x27;t cover all usecases. I can live with this though.<p>I have built a couple large projects using Svelte and haven&#x27;t faced issues with scaling. I found Svelte to be quite flexible, which has enabled me to build fast, and maintain a performant codebase.<p>My recent project is Mathesar, which has a large frontend codebase in Svelte + Typescript [1]. It&#x27;s also open-source so you can check out the codebase. We use pretty much all of Svelte&#x27;s features and we even implemented a full component library. Here&#x27;s an old discussion for deciding which frontend library to use for Mathesar, where we selected Svelte [2].<p>We have had to establish a number of patterns (including around reactivity) so that new contributors don&#x27;t break things, which happens more often than you think.<p>Svelte&#x27;s primary issue is a lack of established patterns, which makes it easy for new Svelte developers to get things wrong. React has a number of such patterns due to it&#x27;s massive community. I believe as Svelte&#x27;s community keeps growing and more projects choosing Svelte, this would be tackled.<p>[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;centerofci&#x2F;mathesar">https:&#x2F;&#x2F;github.com&#x2F;centerofci&#x2F;mathesar</a> [2]: <a href="https:&#x2F;&#x2F;github.com&#x2F;centerofci&#x2F;mathesar&#x2F;discussions&#x2F;55">https:&#x2F;&#x2F;github.com&#x2F;centerofci&#x2F;mathesar&#x2F;discussions&#x2F;55</a>
评论 #35333542 未加载
评论 #35331572 未加载
davidjfelix大约 2 年前
I think Svelte&#x2F;sveltekit (especially) has really pushed a lot of the ecosystem forward and I love the effort made to exposing platform primatives more explicitly while attempting to make the framework disappear. I think the store mechanism is really great but I have noticed a few usability complaints coming from react land.<p>The main one for me is typing props for a component feels extremely wack. In react I have a function, that function takes a type, I export that type and can import that type. In svelte I&#x27;m exporting the props individually? It&#x27;s annoying to get the type declarations in one spot and make that easy to import for other components to use as intermediate typing. This is one of those things that I didn&#x27;t even think twice about until my project reached a medium size and had multiple developers building out different portions -- it&#x27;s inconvenient to scale and none of the workarounds feel good.
评论 #35328890 未加载
tobr大约 2 年前
&gt; The $ label is one technical reason why I would be hesitant to adopt Svelte for larger projects. It&#x27;s a core part of Svelte that you can&#x27;t always avoid, and I think the potential for introducing bugs through it is high to start and very high at scale.<p>I agree that it can quickly cause confusion, but I can’t really think of a situation where it <i>can’t</i> be avoided.<p>I find it useful for simple things but try to avoid it when the dependency graph gets more complicated.<p>I haven’t built any large-scale Svelte applications but since reactive labels are by definition local to the component (it’s a compiler feature, and each component is compiled independently), I’m not sure why it would cause more issues at scale.<p>EDIT: Maybe they’re thinking of the reactive store syntax, which is harder to avoid but much less of a brainteaser. But that’s really a completely different feature that happens to use the same character.
评论 #35335317 未加载
评论 #35328868 未加载
评论 #35325369 未加载
pkalinowski大约 2 年前
I picked up Svelte to build my first non-trivial app, which is flying navigation aid for hot air balloon pilots[1].<p>Svelte is much, much easier to grasp than React or Vue, especially when it comes to state management. I like that it’s super lean and it never confuses me what’s native Javascript and what’s the framework (pretty important for a non-developer me). And I love not having to write huge amounts of boilerplate code.<p>Reactivity sometimes gets more complicated than advertised on docs. For example, I have a bunch of functions where I manipulate an object and need to reassign it to itself (feature = feature) to trigger refresh on reactivity block. Sometimes it’s easy to miss and not know why reactive statements are not being updated.<p>Also, docs are pretty barebones. For comparison, I think Vue docs are explaining details in better and clearer way.<p>[1]: <a href="https:&#x2F;&#x2F;balloonnavigator.com" rel="nofollow">https:&#x2F;&#x2F;balloonnavigator.com</a>
shanehoban大约 2 年前
I work with React (NextJS) and from working on things in Vue, and Nuxt - the one thing I absolutely hate about React is state management. If you have never used Pinia[0] (Vuex) with Vue, it&#x27;s just so, so, so much easier.<p>I&#x27;m using Zustand[1] with React as it is as similar as I can find to Pinia, but the whole hook system is just painful to work with... OK rant over.<p>I haven&#x27;t built anything substantial with Svelte, but it&#x27;s definitely on the radar, and I like how similar it is to Vue single file components (SFC). Hoping state management will be as nice to work with as Pinia is with Vue.<p>[0] <a href="https:&#x2F;&#x2F;pinia.vuejs.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;pinia.vuejs.org&#x2F;</a><p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;pmndrs&#x2F;zustand">https:&#x2F;&#x2F;github.com&#x2F;pmndrs&#x2F;zustand</a>
评论 #35325455 未加载
评论 #35326867 未加载
评论 #35326509 未加载
评论 #35326322 未加载
评论 #35325868 未加载
评论 #35327386 未加载
tsp大约 2 年前
Vue 3 and Svelte feel very similar to use. I prefer Vue because of the ecosystem. Using it with TypeScript and Pinia is pure joy! Surely, Svelte will catch up, but it will take a while.
评论 #35327841 未加载
评论 #35326496 未加载
pier25大约 2 年前
I&#x27;ve been using Svelte exclusively for the past 3 years or so. I love it and will keep using it as my main solution for interactivity. It&#x27;s fast to use and execute, produces small apps, and it&#x27;s extremely economical in how you express components.<p>The confusion the author expresses with $: reactive statements and store auto subscription with the $ are unwarranted IMO. It&#x27;s really just a lack of familiarity but this kind of stuff becomes intuitive very quickly.<p>My criticism of Svelte is rather that they haven&#x27;t gone deep enough into the compiler-based approach.<p>Would be great if there were something like .svelteStore files where you had all the automatic reactivity tracking without having to use a component. Or some kind of improvements into writing styles. With a compiler you can do anything you want and I think Svelte has been a bit timid, maybe to not scare people away.<p>For example Imba[1] also bet on a compiler-based approach (years before Svelte existed) and created their own language&#x2F;framework&#x2F;compiler. They have come up with amazing solutions to many problems. It&#x27;s a shame they bet on Ruby aesthetics though and also that they aren&#x27;t investing into marketing&#x2F;docs.<p>Of course, one might argue that using a compiler is a bad idea for a number of reasons. And yeah of course there are objective issues to any approach, but you have to pick your poison. All in all, Svelte has made me tremendously productive compared to using other solutions for years (React, Vue, Mithril, Inferno, etc).<p>I will say though that I would rather use a solution that doesn&#x27;t have any reactivity at all. Mithril and Imba have this concept of just &quot;redrawing the whole thing&quot; like a game GUI without having to worry about reactivity. Cognitively speaking, no reactivity is the best mental model IMO. With any reactive solution, it&#x27;s very easy to fall into complex reactive dependencies which can be hard to track. The author of Imba has a video from 2018 where he talks about this[2].<p>[1] <a href="https:&#x2F;&#x2F;imba.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;imba.io&#x2F;</a><p>[2] <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=jwoApTLvRdQ">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=jwoApTLvRdQ</a>
评论 #35329191 未加载
codelikeawolf大约 2 年前
I&#x27;ve been using Svelte at the day job for almost 3 years (coming from a React background). We&#x27;re using it for a pretty large application that&#x27;s probably going to end up being at least 400K lines of code. I love how you can leverage CSS to visually indicate state changes:<p><pre><code> &lt;script&gt; export let selected; &lt;&#x2F;script&gt; &lt;style&gt; [aria-selected] { background-color: blue; } &lt;&#x2F;style&gt; &lt;button aria-selected={selected}&gt;Click Me&lt;&#x2F;button&gt; </code></pre> You can&#x27;t do that with React. The lack of a VDOM is incredibly refreshing and I don&#x27;t notice any performance issues.<p>I occasionally come across articles expressing concern that it won&#x27;t scale up for large applications and I find that confusing. React has considerably more footguns than Svelte. I&#x27;ve ported over several personal projects from React to Svelte and it always shaves quite a bit off the line count and makes the code less confusing (at least in my opinion). Granted, it&#x27;s not perfect. Forwarding props is kind of a pain in the butt and the docs advise against using `$$restProps`. There&#x27;s also some trickiness when it comes to overriding styles. The only way to override a certain style in a custom `&lt;Button&gt;` component is via a `style` prop, using CSS Modules, or a CSS-in-JS library like Emotion. I&#x27;ve been using Vite&#x27;s built-in CSS Modules and it&#x27;s working pretty well.<p>The scoped styles are really nice. If you structure your components right, make sure you&#x27;re adhering to accessibility guidelines, and use semantic HTML, you can usually get away with styling the markup based on the element type or attribute without having to define classes on the elements.
georgefrick大约 2 年前
I&#x27;ve been building an app with Sveltekit (ok, two); and I&#x27;ve proposed a talk at THAT conf in the summer. I agree with the author&#x27;s positive and negative assessments, but really for me the developer experience outweighs the negatives.<p>In VS Code I turn on seeing short directories in the tabs, which prevents file confusion. Beyond that it&#x27;s been a joy to use and pretty easy to get going with. Any confusion or learning comes from not doing next.js first and having to learn about which things happen where in terms of client and server. It&#x27;s eye opening though and it isn&#x27;t forced learning.<p>I give Sveltekit a &quot;you should certainly consider it&quot; vote.
yawnxyz大约 2 年前
I&#x27;ve been using Svelte and Sveltekit daily for a few years (back when it was Sapper!). I consider myself a product designer and not an engineer.<p>With the new direction of Sveltekit, the absolutely worst thing is the documentation. The new server-side endpoints have confusingly similar nuances (certain things like fetch can be used on certain server-side files, but another kind of fetch can only be used on another). The documentation style makes these nuances next to impossible to find, and I find myself having to Google or ask Chat GPT to help me figure those problems.<p>Otherwise, it&#x27;s been a breeze to build with!
评论 #35325490 未加载
seanwilson大约 2 年前
What&#x27;s a good frontend setup right now if you want strong static typing? I know Vue 3 supports TypeScript for example but it doesn&#x27;t look like that&#x27;s their core audience?<p>I don&#x27;t get the appeal of frameworks introducing template tags like `{#if showFoo}` vs JSX personally. You have the learn new syntax for things you already know how to do in JavaScript but with less expressibility, and JSX can at least be type checked so you don&#x27;t have runtime problems like an `&lt;input&gt;` sneaking a string in a number field.
评论 #35330517 未加载
评论 #35325925 未加载
评论 #35325791 未加载
评论 #35327254 未加载
评论 #35326687 未加载
评论 #35326175 未加载
评论 #35328021 未加载
CharlieDigital大约 2 年前
Really interesting observation about the context of React being JS and the context of Svelte (and Vue, similarly) being HTML.<p>Makes so much sense once it&#x27;s pointed out.
评论 #35325762 未加载
nailer大约 2 年前
As a Svelte user, and someone who definitely prefers it over the old frameworks, the praise and the criticisms seem accurate:<p>&gt; In the end I found it was difficult to determine reliably when to reach for the $ label. I&#x27;d use it in one scenario and it seemed to work like I expect, then throw it at another scenario and it didn&#x27;t work like I expect.<p>Yep. There&#x27;s a bunch of different syntaxes and I can&#x27;t find a documentation page that lists all of them. I use it, but I don&#x27;t have confidence to always know when it&#x27;s appropriate.<p>&gt; Rip out {#await ...} and put it in the &lt;script&gt; logic, then use local variables when rendering.<p>Yep. Handling promises isn&#x27;t something to be done in the HTML. HTML should deal with values.<p>I think even given these Svelte is still the obvious choice for new apps. Particularly the cleaner syntax, less code, batteries-included handling of CSS, and stores. But the two points above would be great to improve for future versions.
codeptualize大约 2 年前
Great article, it&#x27;s good to read a nuanced take on a hot topic.<p>I think the $ shows the tradeoff of reactivity. It makes updates sort of automatic which is great, until it&#x27;s not. React on the other hand is a bit more explicit and cumbersome, until it&#x27;s not. Rules of hooks vs rules of reactivity, it&#x27;s all about managing triggers and dependencies, which easily gets complex. I think there might be a possibility for a mix, reactivity with escape hatches, idk.
评论 #35325411 未加载
synergy20大约 2 年前
I used Vue in the past and decided to use Svelte early this year, I do not need SEO or anything SSR, just the original SPA with CSR.<p>then I found out Sveltekit is really a SSR-first design, and Svelte itself has no client side routing etc. While Vercel sells Sveltekit(and Next.js) to be CSR ready, I don&#x27;t buy it, I don&#x27;t need the complexity of SSR in the code when I just need a clean CSR, however you paint the SSR-is-for-all picture.<p>So I switched to React, now React is also favoring SSR-first(next.js etc) approach. I&#x27;m back to Vue for future projects.<p>Vue by default remains to be the sole and true CSR SPA, if you need SSR, add Nuxt will do, but, at least it does not force me into a SSR-first default (and recommended) framework.
评论 #35327980 未加载
评论 #35329007 未加载
评论 #35328610 未加载
评论 #35328123 未加载
mhaberl大约 2 年前
&gt; I&#x27;d use it again for personal projects, maybe not for large company projects if I was the architect.<p>Questions about large projects always arise when talking about Svelte. Did you &#x2F; would you use it and why not?<p>I would certainly NOT suggest using Svelte on enterprise projects. Why not?<p>Because other people don’t do it, and that means that it is very likely that there are no (not many anyway ) experienced Svelte devs that are willing to work at&#x2F;for some large company. React and Angular are safe bets in THAT space.<p>On the other hand, would I use it for personal projects or in a startup - absolutely. It&#x27;s simple, it is fast and it is fun to work with.
评论 #35329509 未加载
评论 #35327975 未加载
评论 #35327804 未加载
lionls大约 2 年前
I share your view that Svelte is a great framework for small projects. It is also really useful if you want to build small standalone javascript widgets. I&#x27;ve used it at work to build a fast video testimonial slider for Shopify [1]. I really liked the component format as we could quickly integrate our code in the existing HTML layout. The Svelte built-in store has also been useful for us to manage the current state of the application. Overall development with Svelte has been really quick.<p>[1] <a href="https:&#x2F;&#x2F;vimonial.com" rel="nofollow">https:&#x2F;&#x2F;vimonial.com</a>
评论 #35325373 未加载
评论 #35326857 未加载
jamincan大约 2 年前
&gt; I like the idea, but in practice I always ended up refactoring it out. There was always something else I needed to do after the Promise resolved or rejected prior to rendering, and I didn&#x27;t want to run that logic every time I used the service.<p>&gt; The logic also didn&#x27;t belong inline in the rendering code, though. So where does it go?<p>I think the idea would normally be that you would handle loading the data in +page.ts and do any transformations there, and only deal with rendering and ui elements in the +page.svelte file.
评论 #35326351 未加载
评论 #35328662 未加载
nathias大约 2 年前
I&#x27;m a React dev, I recently rewrote my websitein Svelte. Svelte is my favorite by far, it does so many things in a smarter way so its really hard to go back.
Pr0ject217大约 2 年前
&quot;The $ label is one technical reason why I would be hesitant to adopt Svelte for larger projects. It&#x27;s a core part of Svelte that you can&#x27;t always avoid, and I think the potential for introducing bugs through it is high to start and very high at scale.&quot;<p>At work, we use Svelte throughout our entire FE platform in many SPA micro-frontends, on both the web and mobile (w&#x2F; Cordova). We have 10,000+ daily active users. Our team has used Svelte in production for a few years. All of our developers learned it during the coding interview project, and on the job. It&#x27;s fun and enjoyable to use.<p>I disagree strongly with this statement (not using it in production because of the reactive syntax). Reactive-blocks will trigger an update if their direct top-level dependencies change, not if one of their dependencies change from within a new scope&#x2F;block (e.g. function-call) - that&#x27;s all. Also, we only use reactive statements when we need to - we typically use data-binding instead.
sebastianconcpt大约 2 年前
Now I notice I was doing:<p><pre><code> Rip out {#await ...} and put it in the &lt;script&gt; logic, then use local variables when rendering. </code></pre> intuitively and without realizing. Thanks for writing about it.
评论 #35326817 未加载
Mavvie大约 2 年前
I agree with pretty much everything the author said. I&#x27;ll also add that one of my biggest complaints is that you can&#x27;t use typescript inside the &quot;markup section&quot; (eg. for type casts or null assertions).<p>I still don&#x27;t fully understand reactivity, or how to handle complex reactivity use cases, but it&#x27;s not like the story in react is much better.<p>Overall it was a joy to work with even though I don&#x27;t think it&#x27;s a perfect framework and may not have what it takes to unseat react as king.
whiddershins大约 2 年前
The author had a completely different experience from mine.<p>I adored the $: reactive variables, I liked the await blocks, and I found built in stores difficult.<p>This was as of a year ago, but still interesting.
nvegater大约 2 年前
Last year I wrote a comparison between Sveltekit and React with focus on Typescript and Graphql. What I didn&#x27;t like particularly was that for-loops had no type inference [1]. Until this changes there is no reason for me to use Sveltekit in big projects. Typesafety is very important and nothing beats react on that.<p>[1]: <a href="https:&#x2F;&#x2F;www.nvegater.info&#x2F;blog&#x2F;SvelteKit#bad" rel="nofollow">https:&#x2F;&#x2F;www.nvegater.info&#x2F;blog&#x2F;SvelteKit#bad</a>
Rapzid大约 2 年前
A lot of the pluses mentioned are things I really enjoyed about Vue. The bind system works great for syncing inputs to arbitrary reactive objects(or not reactive), the in-built transition support, the event system, and I don&#x27;t know if Svelte has this but Vue&#x27;s async component factory support is fantastically useful.<p>Just can&#x27;t get on board with yet another compiler and string template language. Towards the end of my time with Vue I was favoring JSX more and more. The VSCode Vue extension of choice at the time(this was a couple years ago) was Vetur and they really struggled with performance regressions and great intellisense support.<p>These libraries with their custom string templates I expect to really struggle to achieve and maintain the level of tooling support I&#x27;ve come to expect. And even if they can; why god, why another custom language requiring a pre-compiler? Felt like we were finally getting out of that a bit with fall of coffeescript, SASS falling out of favor due to the performance issues, babel falling by the wayside in favor of fast SWC or Esbuild with the death of IE and the rise of greenfield browsers.<p>IMHO MobX has shown us how fine grain reactivity can be accomplished with proxies ages ago; with great DX. SolidJS is showing us what can be done without a compiler(it does some light JSX transformation but AFIAK it doesn&#x27;t have too and there is no custom language). Vue has made most of the goodness of their string template syntax available in JSX via the newish attribute extensions.<p>Why do we need another string template language? Why another compiler? React Optimizing Compiler? This is not the way.
adonig大约 2 年前
I recommend you to have a look at Phoenix Elixir LiveView next.
评论 #35331028 未加载
评论 #35326160 未加载
dbrueck大约 2 年前
I&#x27;m a huge fan of svelte because the developer experience is pretty great when you first build something but also when you revisit something you haven&#x27;t touched for a year or two.<p>Another thing that svelte and similar tools get right IMO is that if you have someone dedicated to design, then the HTML&#x2F;CSS are maintainable by them throughout the lifetime of the project. A lot of times we&#x27;ll have a dev do a rough pass on basic functionality and then a web designer come back and make it look good and it rarely requires much back and forth or coordination. Or later in life the project will get a revamped design and it gets implemented without the dev having to do anything. No doubt the JSX-based frameworks have figured out a way to make these scenarios work just fine, but I&#x27;ve been really happy with how naturally the division of labor works out with svelte.
WuxiFingerHold大约 2 年前
After having used all of the big libs&#x2F;framesworks I honestly only care about DX. They all get the job done, are fast enough and have some major or minor gotchas.<p>Svelte&#x2F;Sveltekit has the best DX by far and only some minor gotchas, esp. reactive expressions as described in the article. Once you get how it works, Sveltekit is such an empowering experience, I can&#x27;t imagine being more productive with anything else.<p>BTW, I&#x27;m using Sveltekit for an SPA, which is well documented, and skeleton.dev, a young but promising UI Tookit. Integration with native libs like echarts or three without any issues.
jFriedensreich大约 2 年前
the problem that the transition api solves is that if you want to animate a dom node on removal you have to delay the actual removal until its animations are done. you even need this feature if you do all animations with pure css.
评论 #35325457 未加载
PlkMarudny大约 2 年前
I use Svelte for all the project under my supervision and the biggest problem I encountered is that functions defined in a component &lt;script&gt; section are all executed when the component is created. This is painful sometimes, especially for new team members. Never used ``` {#await} ``` SvelteKit works. Reactivity is not a problem, but we use stores a lot, however (means global variables of a kind?).
SinParadise大约 2 年前
So basically, using $ with expressions and no side-effects within the expression will not cause the issue the article is having?
uhtred大约 2 年前
I&#x27;m pretty sure there are still people building really awesome things with Ember or JQuery or Angular or Backbone.<p>Oh have you heard of luxpop.js all the cool people are using it, it has bitransitional anti-mutation mega-flip data binding so you regain a microsecond rendering that p tag.<p>You haven&#x27;t heard of it? You dinosaur!
kokizzu2大约 2 年前
rewritten an nuxt+vue2 svelte like 2 months ago, and I love it, it just works, no gotchas<p>bind:this is amazing, just lack of IDE support
pupppet大约 2 年前
Anyone transitioned from Vue 3 to Svelte? Worth it, regrets?
DeathArrow大约 2 年前
I wonder how many JS&#x2F;TS fronted frameworks are there.
评论 #35329343 未加载
opensas大约 2 年前
&gt; The $ label is one technical reason why I would be hesitant to adopt Svelte for larger projects. It&#x27;s a core part of Svelte that you can&#x27;t always avoid, and I think the potential for introducing bugs through it is high to start and very high at scale.<p>The reactivity system in Svelte is really a joy to use, once you get used to it there&#x27;s no turning back.<p>But the author did hit one of the ugliest pain points about it. Svelte can NOT correctly infer transitive dependencies when the variable being updated is inside a function. Meaning that the variable itself will be reactive (it will be invalidated every time it&#x27;s assigned, even inside a function) but Svelte is not using that information to build the dependency graph, and falls back to the order in which the reactive blocks were defined, which may or may not be right.<p>I created this issue <a href="https:&#x2F;&#x2F;github.com&#x2F;sveltejs&#x2F;svelte&#x2F;issues&#x2F;5190">https:&#x2F;&#x2F;github.com&#x2F;sveltejs&#x2F;svelte&#x2F;issues&#x2F;5190</a> a couple years ago documenting it.<p>It&#x27;s not so common, but when it bytes you it&#x27;s pretty nasty.<p>The workarounds I found are the following<p>These are the workarounds I found:<p>- a repl with the issue: <a href="https:&#x2F;&#x2F;svelte.dev&#x2F;repl&#x2F;640736d3c91d40d3971afcc3eef8b25e?version=3" rel="nofollow">https:&#x2F;&#x2F;svelte.dev&#x2F;repl&#x2F;640736d3c91d40d3971afcc3eef8b25e?ver...</a><p>- workaround 1: manually reorder statements, need to figure out by yourself (and maintain!) the dependency graph: <a href="https:&#x2F;&#x2F;svelte.dev&#x2F;repl&#x2F;3ecd6aa918e045999db32d379270fc1c?version=3.57.0" rel="nofollow">https:&#x2F;&#x2F;svelte.dev&#x2F;repl&#x2F;3ecd6aa918e045999db32d379270fc1c?ver...</a><p>- workaround 2 (my favorite): provide a redundant update as &quot;hint&quot; to tell the compiler that setY updates y: <a href="https:&#x2F;&#x2F;svelte.dev&#x2F;repl&#x2F;cbf98bb35f5e4dd4b037d13254853c90?version=3.57.0" rel="nofollow">https:&#x2F;&#x2F;svelte.dev&#x2F;repl&#x2F;cbf98bb35f5e4dd4b037d13254853c90?ver...</a><p>(thanks to TylerRick for this: <a href="https:&#x2F;&#x2F;github.com&#x2F;sveltejs&#x2F;svelte&#x2F;issues&#x2F;5190#issuecomment-717603421">https:&#x2F;&#x2F;github.com&#x2F;sveltejs&#x2F;svelte&#x2F;issues&#x2F;5190#issuecomment-...</a>)<p>in practice it means to do something like: `$: { setY(x); y = y };`<p>- workaround 3: put the update operations in order in a single block (it&#x27;s just the workaround 1 with improved legibility, IMHO): <a href="https:&#x2F;&#x2F;svelte.dev&#x2F;repl&#x2F;074df362bb934312bbe6fd3aeccab771?version=3.57.0" rel="nofollow">https:&#x2F;&#x2F;svelte.dev&#x2F;repl&#x2F;074df362bb934312bbe6fd3aeccab771?ver...</a><p>I still think we could do better, at least explaining the issue and how avoid to fall into it (perhaps some linting warning?)<p>But I really hope svelte developers start considering this an issue to solve, it&#x27;s inconsistent (meaning the variable is reactive but that reactivity is not taken into account to order the operation in &quot;topological order&quot; (Hey, I learnt about that from one of Rich&#x27;s presentations, see <a href="https:&#x2F;&#x2F;rethinking-reactivity.surge.sh&#x2F;#slide=19" rel="nofollow">https:&#x2F;&#x2F;rethinking-reactivity.surge.sh&#x2F;#slide=19</a>) and as I said before, in the rare occasions you stumble upon it is not so easy to understand what&#x27;s going on.
评论 #35331976 未加载
danfry大约 2 年前
Use the platform!
willio58大约 2 年前
Thanks for this overview, I definitely had some svelte fomo and now I’m feeling better in a react land.
评论 #35329820 未加载
rsp1984大约 2 年前
Mostly agree with the article but cringed a bit when I read this:<p>&gt; This subtlety led to more than one case where I didn&#x27;t understand why a component didn&#x27;t update. ... In the end I found it was difficult to determine reliably when to reach for the $ label. I&#x27;d use it in one scenario and it seemed to work like I expect, then throw it at another scenario and it didn&#x27;t work like I expect.<p>OK, that&#x27;s like you&#x27;re used to using an old donkey for transport and then someone hands you a brand new car and you start complaining about it not having seat heaters.<p>The $-based reactiveness of Svelte is great! Just don&#x27;t expect that every possible side case is covered 100%. Same as with just about any other technology.
评论 #35325853 未加载