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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Svelte 5: Runes

471 点作者 benmccann超过 1 年前

88 条评论

EvanYou超过 1 年前
This is (surprisingly) almost identical to the Reactivity Transform explorations we did in Vue: <a href="https:&#x2F;&#x2F;vuejs.org&#x2F;guide&#x2F;extras&#x2F;reactivity-transform.html" rel="nofollow noreferrer">https:&#x2F;&#x2F;vuejs.org&#x2F;guide&#x2F;extras&#x2F;reactivity-transform.html</a><p><pre><code> let count = $ref(0) const double = $computed(() =&gt; count * 2) watchEffect(() =&gt; { console.log(double) }) </code></pre> We started experimenting with this ling of thought almost 3 years ago:<p>- First take (ref sugar), Nov 2020: <a href="https:&#x2F;&#x2F;github.com&#x2F;vuejs&#x2F;rfcs&#x2F;pull&#x2F;228">https:&#x2F;&#x2F;github.com&#x2F;vuejs&#x2F;rfcs&#x2F;pull&#x2F;228</a><p>- Take 2, Aug 2021: <a href="https:&#x2F;&#x2F;github.com&#x2F;vuejs&#x2F;rfcs&#x2F;pull&#x2F;368">https:&#x2F;&#x2F;github.com&#x2F;vuejs&#x2F;rfcs&#x2F;pull&#x2F;368</a><p>- Take 3, Nov 2021: <a href="https:&#x2F;&#x2F;github.com&#x2F;vuejs&#x2F;rfcs&#x2F;discussions&#x2F;369">https:&#x2F;&#x2F;github.com&#x2F;vuejs&#x2F;rfcs&#x2F;discussions&#x2F;369</a><p>We provided it as an experimental feature and had a decent number of users trying it out in production. The feedback wasn&#x27;t great and eventually decided to drop it. <a href="https:&#x2F;&#x2F;github.com&#x2F;vuejs&#x2F;rfcs&#x2F;discussions&#x2F;369#discussioncomment-5059028">https:&#x2F;&#x2F;github.com&#x2F;vuejs&#x2F;rfcs&#x2F;discussions&#x2F;369#discussioncomm...</a>
评论 #37596916 未加载
评论 #37592693 未加载
评论 #37594309 未加载
评论 #37593270 未加载
评论 #37596951 未加载
评论 #37596414 未加载
satvikpendem超过 1 年前
This is basically what Vue and Solid do, no? Same sort of state and derive&#x2F;computed variables, it seems like.<p>Also, I will never understand why people like reactive signals. The article even quotes &quot;Knockout being right all along&quot; which, no, reactivity and two way data binding creating a spaghetti mess of changes affecting other changes all over the place unless you&#x27;re really careful is why React was made in the first place, to have only one way data binding and to re-render the entire page in a smart way. React will soon get its own compiler as well which will made regenerating the DOM even more efficient.<p>It&#x27;s like every other framework is slowly rediscovering why React made the decisions it made. I am assuming it&#x27;s because the users who are making these frameworks now have not used or do not remember the times where &quot;signals&quot; were called observables, or the usage of Rx libraries, and how having too many of these would cause you to lose your mind debugging the intricate webs you inadvertently spun.
评论 #37585078 未加载
评论 #37585051 未加载
评论 #37584931 未加载
评论 #37588430 未加载
评论 #37585173 未加载
评论 #37584925 未加载
评论 #37586927 未加载
评论 #37585169 未加载
评论 #37585538 未加载
评论 #37591744 未加载
评论 #37586736 未加载
评论 #37585340 未加载
评论 #37585443 未加载
评论 #37588486 未加载
评论 #37586228 未加载
chrismorgan超过 1 年前
I’m not particularly comfortable with some of the nature of the change. Runes are magic compiler symbols, but they look <i>even more</i> like just normal code than was the case before. Previously, Svelte’s reactivity model was very easy to understand, including its limitations, because it was the result of very simple analysis—you can cover the rules in a few minutes without difficulty. It included some things that were <i>obviously</i> magic: $: reactive blocks and $ prefixes on stores.<p>When you had this:<p><pre><code> let count = 0; count += 1; </code></pre> … it made reasonable sense, because that’s just normal JavaScript; the fact that `count` was made reactive was basically incidental.<p>But once it’s this:<p><pre><code> let count = $state(0); count += 1; </code></pre> This looks like you’ve called a function named $state, and given that you’re talking about migrating from compile-time to runtime reactivity, you might (I think reasonably) expect `count` then to be some <i>object</i>, not just an integer, and so `+= 1` would be the wrong (since JavaScript doesn’t let you overload those operators). But no, it’s instead some kind of decorator&#x2F;annotation.<p>Yes, stores are unwieldy as you scale them up, and definitely have some practical problems, but that createCounter stuff <i>looks</i> fragile. I’m curious how it all works, because it <i>looks</i> like it’d be needing to do quite a lot of control flow analysis, but not curious enough to investigate at this time. But my intuitions suggest it’s probably markedly more complex and difficult to explain, though perhaps and hopefully more consistent.
评论 #37584833 未加载
评论 #37585355 未加载
ranting-moth超过 1 年前
Perhaps I&#x27;m just the grumpy old guy that&#x27;s afraid of change.<p>But I fell in love with Svelte because it was dead simple (according to me). It was a breeze of fresh air and I felt I just program again without wiring enchantments together.<p>I do agree that its simplicity has downsides too, so perhaps it&#x27;s just nothing to be afraid of?<p>But I can&#x27;t help seeing this as ominous:<p>&gt; This is just the beginning though. We have a long list of ideas for subsequent releases that will make Svelte simpler and more capable.<p>Please don&#x27;t turn Svelte into a black magic box.
评论 #37585566 未加载
评论 #37586140 未加载
评论 #37585491 未加载
评论 #37589062 未加载
wentin超过 1 年前
One of Svelte&#x27;s biggest advantages is its compiler, positioning it more as a language than just another JS framework. If I&#x27;m not mistaken, the compiler allows Svelte to define its syntax to anything they want.<p>Given this, I&#x27;m curious: couldn&#x27;t the traditional syntax of `let counter = 0` be made to function similarly to the new let count = $state(0);? Transpile it to let count = $state(0) under the hood? If that can work technically, instead of introducing a new rune for reactivity, why not introduce a &quot;negative&quot; rune to denote non-reactive statements? This way, the change wouldn&#x27;t break existing code; it would be more of a progressive enhancement.<p>I agree the move to unify the Svelte &lt;script&gt; tag with regular js&#x2F;ts files is an improvement. It was indeed a little odd that certain syntactic sugar, like the $, would work exclusively within the Svelte &lt;script&gt; and not in a js&#x2F;ts file that&#x27;s right next to it. However, from what I gather, it seems the Svelte team is aligning the Svelte script more with js&#x2F;ts, rather than bringing the js&#x2F;ts closer to Svelte&#x27;s unique syntax. This trajectory seems to be pushing Svelte towards resembling traditional JavaScript frameworks, like React. It&#x27;s a departure from Svelte&#x27;s unique strength of having a custom compiler and behaving more like a language. If every syntax in Svelte is expected to mirror its behavior in js&#x2F;ts, eventually svelte will lose all it secret sauce that made it so unique. Why can&#x27;t we add a rune into js&#x2F;ts file, a note in the beginning to tell svelte compiler that this is svelte enhanced js&#x2F;ts file, compile it like svelte script tag code? Bring js&#x2F;ts more alike to svelte?
评论 #37586235 未加载
评论 #37586377 未加载
评论 #37586234 未加载
pimterry超过 1 年前
It&#x27;s great to see people moving in this direction, but I&#x27;m disappointed that everybody has decided to reimplement basically the same thing independently.<p>Mobx was ahead of the game here (though, granted, it too draws on Knockout.js). You can use Mobx to declaratively describe reactive state, much like this. But it isn&#x27;t integrated into any framework - you can use it in vanilla JavaScript with no other runtime or compilation required. You define models with Mobx, then on top of that there&#x27;s mobx-react, which ties your model into React&#x27;s update APIs (essentially making render() automatically observe values, and making relevant changes trigger a re-render), or there&#x27;s mobx-vue, or mobx-svelte, or mobx-preact, etc etc. Decoupling this is super helpful - for example I&#x27;m using mobx to model raw state, computed state &amp; reactions to changes in server side Node.js, no problem.<p>Meanwhile, recreating the same reactive concepts independently in each library instead makes all the resulting code incompatible, so even your pure JS state models are coupled to your UI framework - e.g. createCounter in this post has to import &amp; use $state from Svelte. That makes it far harder to change frameworks in future, hard to share code between apps using different frameworks (plausibly even different versions of the same framework), etc etc.<p>I&#x27;d love to see a native common standard for this, similar to how promises were eventually standarized and suddenly everything had a compatible model for handling async future results (I could swear I&#x27;ve seen initial discussion on exactly that already, but I can&#x27;t find it anywhere now sadly).
评论 #37585739 未加载
评论 #37586074 未加载
评论 #37586106 未加载
评论 #37585703 未加载
mbStavola超过 1 年前
As a recent adopter of Svelte, these changes are intriguing but I don&#x27;t really have a grasp of how I feel about it quite yet.<p>One thing that I <i>am</i> definitely happy to see is the removal of $: as it should help Typescript users. Personally, I was quite sick of writing:<p><pre><code> let input = &#x27;Hello&#x27;; &#x2F;&#x2F; ... let loudInput: string; $: loudInput = `${input)!`; </code></pre> Instead of:<p><pre><code> let input = &#x27;Hello&#x27;; &#x2F;&#x2F; ... $: loudInput: string = `${input)!`; </code></pre> It&#x27;s an incredibly minor thing, but when you do it 1000 times it becomes very frustrating. Having reactivity be rune-based should help TS avoid the syntactic confusion, bringing us to:<p><pre><code> let input = $state(&#x27;hello&#x27;); &#x2F;&#x2F; ... let loudInput: string = `${input)!`;</code></pre>
评论 #37585555 未加载
评论 #37590930 未加载
jasim超过 1 年前
What about long arrays? Is there a mechanism where Svelte knows which element is mutated, and do fine-grained recomputation&#x2F;update only the corresponding view elements?<p>This is the primary place where we have to go outside the framework in React. Only a large linear list has this problem -- if it was a decently balanced component tree, then we could skip updating huge swathes of it by skipping at a top level node. But it is not possible in an array. You have it iterate through each element and do a shallow comparison to see if the references have changed.<p>That said, it is fairly easy to escape to DOM from inside a React component with useRef and the portal pattern. Then we can write vanilla JS which makes updates to only the values it changes.<p>If Svelte solves this in an elegant manner, then it would be a very compelling feature over React. I&#x27;m asking here because last I checked, most of the examples in Svelte&#x27;s documentation pointed to simple counters and regular objects, and I couldn&#x27;t find an example of a large linear list.
评论 #37585104 未加载
评论 #37585546 未加载
schietegal超过 1 年前
Comparisons (Svelte 4 vs. Svelte 5 and other Frameworks): <a href="https:&#x2F;&#x2F;component-party-runes.vercel.app&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;component-party-runes.vercel.app&#x2F;</a>
评论 #37588902 未加载
评论 #37591854 未加载
评论 #37628276 未加载
评论 #37585129 未加载
cornfutes超过 1 年前
&gt; At first glance, this might seem like a step back — perhaps even un-Svelte-like. Isn&#x27;t it better if let count is reactive by default<p>Actually, it was Svelte who coined the term and sold us on the idea of reactivity by default. I don’t think anybody asked for “Reactivity by default”. Svelte advanced this idea, and it helped the framework gain traction. It was easy to get started, and gave Svelte this sense of better ergonomics than other frameworks. I was always skeptical about the performance claims, amortized, and the real selling point of Svelte was ergonomics and the dev experience.<p>The problem with the Node.js ecosystem is the devs are borderline marketing and sales type. They’ll justify, rationalize and make things sound good after the fact. Previously, Svelte was persuading us that Svelte was better than the rest because of reactivity by default. Now they did a literal 180. It’s probably in the right direction, and maybe how things should have been. A related symptom of the Node.js ecosystem is reinventing and rediscovering the wheel. The problem here is a lost of trust. Anything else which Svelte purports it’s got figured out or is more enlightened about should be taken with a grain of salt.<p>So it seems those boring FANG engineers with React has it right all along. They had experiencing building sufficiently complex apps where verbose but explicit code was necessary.<p>&gt; Because the compiler can &#x27;see&#x27; where count is referenced, the generated code is highly efficient<p>Yeah, I don’t believe such claims anymore. Sure, in cherry picked and constrained settings, the performance benchmarks might seem good. As much as I hate to admit, I will reach for the production ready and battle tested React, as boring as it is.
评论 #37585384 未加载
handsaway超过 1 年前
I&#x27;ve dabbled with Svelte and find it pleasant to use and I think this is a step in the right direction. The main reason I ultimately keep coming back to React is I find the compile-time alterations to the semantics of my code difficult to reason about.<p>I&#x27;ve spent a lot of time building an intuition for how Javascript code executes and how I can combine its primitives to make reasonable abstractions. The fact that this _looks_ like Javascript but suddenly operates differently is almost more confusing to me than if Svelte was just a non-Javascript language.<p>React&#x27;s `useState`, `useMemo`, etc. are perhaps more verbose but they&#x27;re just functions. Dependency arrays are messy but it&#x27;s fairly easy to extrapolate their behavior from a basic description.
Dnguyen超过 1 年前
I&#x27;ve been trying Svelte for the last couple of months. At first the claim was that it&#x27;s not complicated like React because there&#x27;s a lot less concepts to learn. And it&#x27;s just using basic Javascript and CSS so those skill sets are transferable to any other job. As I use it more and more, there&#x27;s more and more special way of doing things I have to learn: store, reactive variable, $, $$, etc. I didn&#x27;t mind, sure I&#x27;m in Svelte&#x27;s world. But the number of libraries is limited and it really slowed me down tremendously. Now with runes, it&#x27;s just more &quot;magic&quot; to learn. I think that&#x27;s the last straw for me. I&#x27;m done with Svelte experiment. Back to React land.
评论 #37585304 未加载
评论 #37586057 未加载
评论 #37589421 未加载
epmatsw超过 1 年前
This looks like it’s moving closer to React Hooks, but using the compile step to optimize them out? Kinda like a better React Forget?
评论 #37585021 未加载
评论 #37585133 未加载
评论 #37584596 未加载
评论 #37584897 未加载
pier25超过 1 年前
This makes a lot of sense and will simplify some confusions around reactivity.<p>I&#x27;m guessing runes will make it easier for the compiler to track the reactivity which will enable stuff like automatic partial hydration? Maybe even something like qwik?<p>I only read the blog post and didn&#x27;t watch the video... was there any mention on perf and size improvements?
评论 #37585529 未加载
评论 #37584629 未加载
hinkley超过 1 年前
So if I’m understanding this, Svelte is moving from reactive by default to declarative reactivity? That does seem like an improvement in signal to noise ratio.<p>Shared-everything does not scale. It ends in whack-a-mole and an escalating blame game about whether team members are fit to work on the project. It’s bunk. It’s deflecting from the real problem which was dereliction of duty by the “architects” who took a laissez-faire stance on state management instead of providing structure. Worked on a couple of those. Never again.<p>Practically the whole point of encapsulation is gated access to data, putting constraints on sharing, compressing the possible state space of the system closer to the <i>desired</i> state space.
wirahx超过 1 年前
I&#x27;ll be the first to mourn the (future) loss of $: but the video clearly shows that the changes are a pretty enticing way to make your code that little bit cleaner, and solve all of the &quot;but Redux!&quot; style questions.<p>Svelte for Apps. Svelte for Sites.
评论 #37584639 未加载
orangepanda超过 1 年前
React Hooks has its problems, but it got so many things right from the start - code written in 2018, when hooks first came out, still works today. No need to rewrite everything when a new major release comes out.<p>That said, svelte5 does solve a lot of problems that stop me from trying it.
评论 #37584734 未加载
评论 #37586386 未加载
onsclom超过 1 年前
Most of this I really love. One thing seems a bit strange though...<p>Let&#x27;s compare Svelte&#x27;s and Solid&#x27;s approach to nested reactivity. Both of them implement the same nested reactivity todo example:<p>Svelte: <a href="https:&#x2F;&#x2F;svelte-5-preview.vercel.app&#x2F;docs&#x2F;fine-grained-reactivity" rel="nofollow noreferrer">https:&#x2F;&#x2F;svelte-5-preview.vercel.app&#x2F;docs&#x2F;fine-grained-reacti...</a><p>Solid: <a href="https:&#x2F;&#x2F;www.solidjs.com&#x2F;tutorial&#x2F;stores_nested_reactivity?solved" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.solidjs.com&#x2F;tutorial&#x2F;stores_nested_reactivity?so...</a><p>In Solid, converting something to use nested reactivity is one step. In Svelte, it is two steps. And that second step is really verbose and annoying:<p><pre><code> todos = [...todos, { get done() { return done }, set done(value) { done = value }, get text() { return text }, set text(value) { text = value } }]; </code></pre> Solid makes read and write segregation very simple and obvious. You don&#x27;t need to manually make all these getters and setters.<p>It is nice that runes allows nested reactivity in Svelte, but it feels nicer to use in Solid.
评论 #37596482 未加载
评论 #37590288 未加载
bluelightning2k超过 1 年前
I&#x27;ve always respected Rich Harris and the Svelte team.<p>They do an excellent job of some pretty substantial tech. But also the way he&#x2F;they explain it is so powerful.<p>That includes the blog posts, the videos, the framework itself and the playground.<p>This does seem like a unifying step. Seems like (at least) Svelte and Angular have both declared this model superior to their existing implementations. The video gave credit to prior art in general but would have been better to give the specific projects credit - not just ethically but also to be explicit about what is and is not similar.
spencerchubb超过 1 年前
The whole selling point of Svelte was that it was simple, like a breath of fresh air. You could update the state of your component just by assigning a variable. I guess this is the natural progression of web frameworks.
评论 #37589660 未加载
4kimov超过 1 年前
Having moved from React to Svelte, it was always a breath of fresh air to write less and have it just work. Feels strange seeing state&#x2F;props&#x2F;effect again, almost like I&#x27;m back to React.
评论 #37591289 未加载
chrisco255超过 1 年前
&quot;Like every other framework, we&#x27;ve come to the realisation that Knockout was right all along.&quot;<p>Nope, nope. Been there, done that, with 2-way data binding and never going back.
评论 #37584568 未加载
评论 #37584560 未加载
评论 #37584682 未加载
评论 #37584959 未加载
评论 #37584545 未加载
kalpolintrol超过 1 年前
theyre really not mucking about - just a cursory play in the live preview and it promises to solve basically 99% of the weirdness I encounter in my projects. it makes sense that automatic reactivity for any let was always overkill, and the use of $: in complex scenarios got stringy. $state &#x2F; $derived &#x2F; $effect seems elegant and I&#x27;m sure will make everyday grokking + maintenance easier (&quot;ergonomics&quot;). bigup
zztop44超过 1 年前
This looks great. Stores are one of the unexpected pleasures of Svelte and this seems like it will extend them both in terms of power and also grokability
jussayin超过 1 年前
I&#x27;m evaluating Svelte for a project. The previous Svelte syntax governing reactivity is easier to reason about. For what it&#x27;s worth, I don&#x27;t understand the new proposal after several readings. I suggest that the Svelte team pause and consider feedback for a year before jumping into a what appears to be a wrong design direction.
评论 #37586237 未加载
gsuuon超过 1 年前
Interesting that signals are coming back hard - Elm had and removed signals due to the learning curve and complexity. With solidjs I pretty immediately ran into the gotchas of signals. I like that reactivity is explicit rather than implicit in svelte 5 - implicit reactivity makes debugging stale views pretty unintuitive.
评论 #37586274 未加载
emmanueloga_超过 1 年前
Hmmm. Perhaps &quot;intrinsic&quot; would have been ok for this? &quot;a function which a compiler implements directly&quot;. In any case, it really seems like mainstream frontend programming has gone too far, and has started parodying itself... Runes... sigh :-p<p>Facebook itself (and FB messenger) are pretty buggy apps that are built on React, so not even the &quot;masters&quot; know how to do React properly, judging by the results... To be honest, I don&#x27;t know that the whole thing that KnockoutJS started is really necessary. These days I prefer to work with the DOM directly when possible. <a href="http:&#x2F;&#x2F;domenlightenment.com&#x2F;" rel="nofollow noreferrer">http:&#x2F;&#x2F;domenlightenment.com&#x2F;</a> is a good resource for people wanting to explore how to implement HTML5 applications, going back to the basics.
lominming超过 1 年前
Obviously there are huge similarities to solid-js and other signals based framework with creating a signal, creating computed&#x2F;derived, creating effects, etc. Would it be fair to say that Svelte 5 is going to more &quot;runtime reactivity&quot; rather than compiled time?
trafnar超过 1 年前
What I like about Imba is that you can update a variable, and the result in the view&#x2F;page is updated, without <i>any</i> special syntax.<p><pre><code> let count = 0 def increment count++ tag App &lt;self&gt; &lt;button @click=increment&gt; &quot;Increment&quot; &lt;div&gt; &quot;Count: {count}&quot; imba.mount &lt;App&gt; </code></pre> Try this example here: <a href="https:&#x2F;&#x2F;scrimba.com&#x2F;scrim&#x2F;cpbmKzsq">https:&#x2F;&#x2F;scrimba.com&#x2F;scrim&#x2F;cpbmKzsq</a><p>(Imba is a compile-to-js language that includes JS&#x2F;HTML&#x2F;CSS and a react-like framework all as part of the language. <a href="https:&#x2F;&#x2F;www.imba.io" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.imba.io</a>)
评论 #37587689 未加载
viviansolide超过 1 年前
It&#x27;s pretty cool to see the direction this framework is taking. It was already easy enough to work on Svelte, but now it&#x27;s even easier. Especially if you&#x27;re familiar with a framework like Vue or React. Performance seems to have improved quite a bit too.<p>GG
sbjs超过 1 年前
&gt; Isn&#x27;t it better if let count is reactive by default?<p>&gt; Well, no. The reality is that as applications grow in complexity, figuring out which values are reactive and which aren&#x27;t can get tricky.<p>People keep re-learning that there&#x27;s a certain amount of context that needs to be explicit, and you can&#x27;t just imply everything. Just like when ruby and python made the mistake of getting rid of let&#x2F;contst&#x2F;var&#x2F;etc and programmers said wait no that&#x27;s a bad idea, now it just makes everyone&#x27;s job harder, because neither the compiler nor the developer can figure out what context something belongs to.
评论 #37585935 未加载
crackinmalackin超过 1 年前
I see these changes as net positive in the long run. Especially since it sounds like performance is getting a boost as well. The $props rune isn&#x27;t something I realized I needed, but it definitely clears up code clarity. The $effect runes makes people think we are going down the React useEffect route... but I didn&#x27;t see a dependency array attached there waiting to obliterate performance? I&#x27;m all for removing a tiny piece of Svelte magic to improve code clarity and performance gains. Seems like a big win to me. Thanks Rich and team!
评论 #37589600 未加载
Heechul超过 1 年前
I feel weird that runes are being used in `.js` files without explicit imports. This means some `.js` files without runes can still be interpreted independently without being compiled, but some `.js` files with using runes will not (how do I tell my editor to not warn about these runes while still being `.js&#x2F;.ts` files?) . For components, using `.svelte` instead of something like `.jsx` allowed avoiding this kind of issue. What would be a good solution to this? Would explicit imports fix this issue?
skrebbel超过 1 年前
If you like this, I recommend you also look into SolidJS, which is basically this idea with less compiler magic and fewer dollar signs (and more JSX).<p>It also comes with a built-in model layer called Stores which is genius in its simplicity. In React land I’ve used Flux, Redux, MobX, mobx-state-tree, zustand and pullstate, and IMO Solid Stores beats them all (because Solid makes this possible, not because those libs are dumb)<p><a href="https:&#x2F;&#x2F;www.solidjs.com&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.solidjs.com&#x2F;</a>
评论 #37585400 未加载
评论 #37585226 未加载
onsclom超过 1 年前
I snooped around Rich&#x27;s GitHub history and found he&#x27;s working on esrap[1], a package to convert an AST into code. It uses Bun for development and testing!<p>Crazy theory: esrap will be part of a transpiler that converts Svelte 4 code to Svelte 5 code. I&#x27;m not sure if that&#x27;s actually the case or if it&#x27;s even technically possible. But it would be really cool!<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;Rich-Harris&#x2F;esrap">https:&#x2F;&#x2F;github.com&#x2F;Rich-Harris&#x2F;esrap</a>
matthewmueller超过 1 年前
Congrats on the announcement! This seems like an impressive step forward to accommodate larger Svelte apps while making the language simpler.<p>One thing that popped out was that it seems like .js files will also need to be transformed now to accommodate the $ to rune translation.<p>Feature request to make that optional, perhaps something like:<p><pre><code> import { rune } from &quot;svelte&#x2F;rune&quot; let $count = rune(0) </code></pre> Oh, one other thing. Will reactivity apply to nested fields in objects and arrays?
评论 #37591305 未加载
adantes超过 1 年前
For a large code base, this is a massive step backwards. Open up a Svelte file and try to figure out which, if any of these, are reactive:<p><pre><code> &lt;script&gt; let thing_a = createThingA() let thing_b = createThingB() &lt;&#x2F;script&gt; </code></pre> There&#x27;s no hints from the Svelte language. There&#x27;s no hints from the tooling. You have to manually open up both of those functions to see what they&#x27;re doing. For a large code base, they probably just call another layer of utility functions so you that&#x27;s <i>another</i> level to dig deeper.<p>And that&#x27;s on top of plain *.js&#x2F;*.ts suddenly being hi-jacked. New team members can look at the *.svelte extension and know to go look at Svelte documentation. Why would they think to do that for plain *.js? They already know JavaScript.
评论 #37625699 未加载
netcraft超过 1 年前
I dont use Svelte or react, im sure its lovely and solves real problems. And maybe im just getting old, but over the last 20 years all evidence I have is that &quot;magic&quot; is a trap. Its so strange to me to see such a high profile project leaning into it like this. Youre writing javascript, but the way you must reason about what your code is doing is so different than javascript.
评论 #37585279 未加载
评论 #37591038 未加载
michaelsbradley超过 1 年前
It&#x27;s amazing how far back all the research and experimentation goes on reactive Web&#x2F;JS tech, e.g. Brown PLT&#x27;s work on Flapjax starting back in 2006, even before the JS renaissance kicked off by googl&#x27;s V8!<p><a href="https:&#x2F;&#x2F;github.com&#x2F;brownplt&#x2F;flapjax">https:&#x2F;&#x2F;github.com&#x2F;brownplt&#x2F;flapjax</a><p><a href="https:&#x2F;&#x2F;cs.brown.edu&#x2F;~sk&#x2F;Publications&#x2F;Papers&#x2F;Published&#x2F;mgbcgbk-flapjax&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;cs.brown.edu&#x2F;~sk&#x2F;Publications&#x2F;Papers&#x2F;Published&#x2F;mgbcg...</a><p><a href="http:&#x2F;&#x2F;static.cs.brown.edu&#x2F;research&#x2F;pubs&#x2F;theses&#x2F;ugrad&#x2F;2007&#x2F;lmeyerov.pdf" rel="nofollow noreferrer">http:&#x2F;&#x2F;static.cs.brown.edu&#x2F;research&#x2F;pubs&#x2F;theses&#x2F;ugrad&#x2F;2007&#x2F;l...</a><p>It might be interesting to do a compare&#x2F;contrast with v5&#x27;s Runes and Flapjax&#x27;s implementations.
beders超过 1 年前
&gt; Like every other framework, we&#x27;ve come to the realisation that Knockout was right all along.<p>And we are back full-circle ;)
vorbiscuit超过 1 年前
I&#x27;m not a website programmer like most people here (I work mostly in C and ARM assembly) so can someone knowledgeable on this topic please explain what is the purpose and background of this?<p>Also, I don&#x27;t really understand why it&#x27;s at the top of HN either, is this a groundbreaking change to whatever Svelte is?
评论 #37585224 未加载
supz_k超过 1 年前
&quot;At first glance, this might seem like a step back — perhaps even un-Svelte-like. Isn&#x27;t it better if let count is reactive by default? Well, no. The reality is that as applications grow in complexity, figuring out which values are reactive and which aren&#x27;t can get tricky. And the heuristic only works for let declarations at the top level of a component, which can cause confusion. Having code behave one way inside .svelte files and another inside .js can make it hard to refactor code, for example if you need to turn something into a store so that you can use it in multiple places.&quot;<p>This is absolutely true. I have been confused many times figuring out what are reactive states and what are not.<p>I never knew Svelte needs changes like this, but seeing this, it sounds like a good plan.
评论 #37585721 未加载
amadeuspagel超过 1 年前
Exporting functions makes so much sense. Had asked myself why this doesn&#x27;t work many times.
评论 #37603551 未加载
notfed超过 1 年前
As someone who just started Svelte two days ago, my naïve take is that this feels like adding verbosity.<p>1. Is there no way for the compiler to automatically, recursively find reactive dependencies?<p>2. Assuming no, is there not a more terse way to decorate reactive expressions?
评论 #37589828 未加载
Nezteb超过 1 年前
Runes remind me of Recoil atoms&#x2F;selectors: <a href="https:&#x2F;&#x2F;recoiljs.org&#x2F;docs&#x2F;introduction&#x2F;core-concepts" rel="nofollow noreferrer">https:&#x2F;&#x2F;recoiljs.org&#x2F;docs&#x2F;introduction&#x2F;core-concepts</a>
makingstuffs超过 1 年前
Guess that puts an end to the whole spiel of &quot;You already know Svelte&quot;
mgaunard超过 1 年前
Web tech. So much noise about trivial things.
评论 #37588690 未加载
klysm超过 1 年前
I don&#x27;t know svelte, but it seems like every front end framework introduces &#x27;new&#x27; reactivity concepts deep into it&#x27;s lifetime. A lot of them start looking like react hooks too.
joeldrake超过 1 年前
Why not just call it signal and computed? (instead of state and derived)
评论 #37585618 未加载
评论 #37585090 未加载
zenbai超过 1 年前
Solid is still the best implementation of fine grained reactivity.
barrongineer超过 1 年前
Svelte has never looked more like Vue to me. I don&#x27;t mean this as a dig, I think it looks great.<p>It&#x27;s just even less obvious to me why I might pick it over Vue at this point.
评论 #37591307 未加载
codelikeawolf超过 1 年前
There&#x27;s a lot of comments here so I may be asking a question that was already answered, but will the runes be explicitly importable in non-Svelte files? Or does it use an approach similar to testing frameworks like Jest and Vitest where you have access to them as globals? I&#x27;m thinking of the implications for TypeScript. I usually opt out of globals and import explicitly when I can.
wikoj1021超过 1 年前
What about scoped reactivity? Sometimes you need to react on some of the states not all of them. Right now we are achieving this by passing function with arguments to react on to $: but with $derived and $effect it seems to be not possible because it takes variables from every function passed. Are there any plans how to resolve this? Also nested $effect instead of onMount looks awfull and to be honest is less readable.
评论 #37586387 未加载
tootie超过 1 年前
Perl called these sigils. They were incredibly useful and powerful, but the dev community decided that they hated them.
评论 #37584665 未加载
评论 #37584718 未加载
jzig超过 1 年前
Everyone comparing to React but this looks similar to RxJS Observables as well. Don&#x27;t leave out us Angular folks!
machiaweliczny超过 1 年前
Doesn’t it basically another implementation of MobX? Seems like Vue, Signals, Angular 14 all copy this reactive pattern which IMO is simplest to write testable apps.<p>The only drawback with MobX is that’s its upadates are as granular as components but in practice it’s not hard to optimise manually.
schnebbau超过 1 年前
This is what happens when bored developers just <i>have</i> to improve something that doesn&#x27;t need improving.
评论 #37584636 未加载
评论 #37584620 未加载
评论 #37586269 未加载
评论 #37586189 未加载
pupppet超过 1 年前
These updates lean heavily towards how Vue approaches setting reactivity.<p>Is there any slam-dunk case for using Svelte over Vue?
tln超过 1 年前
I recently wrote a game in Svelte 4, and went through a transition from using the &lt;script&gt;&#x2F;$ reactivity to stores. This looks MUCH nicer to deal with.<p>Their examples seem to be missing some imports? Trying to use $state as shown with svelte@5.0.6 gives &quot;ReferenceError: state is not defined&quot;.
评论 #37585163 未加载
评论 #37590018 未加载
donpark超过 1 年前
Unless I misunderstood, Svelte 5 &#x27;runes&#x27; appears to be just &#x27;markers&#x27; making explicit what used to be implicit with two noteworthy benefits:<p>- simpler compiler implementation - easier to identify moving parts<p>If so then the intro article needs a rewrite to be simpler without unnecessary districting details.
noelwelsh超过 1 年前
So it&#x27;s a kind of type system using a kind of Hungarian notation? :Flashbacks to Win32 intensify:<p>I think a real type system (i.e. compiler checked, rather than relying on falibilities of human programmers) would be a better solution. If Svelte already has a compiler why not implement this as part of it?
评论 #37587565 未加载
评论 #37584790 未加载
tamimio超过 1 年前
Is this the turning point where svelte start to over engineer stuff and becomes just like other frameworks&#x2F;libraries? The whole selling point of svelte is simplicity and straightforward implementation, you over complicate it, I will just use something else, popular at least.
评论 #37588846 未加载
ptrwis超过 1 年前
This is cool, Svelte5 may be the lightest signal-based library. I hope that the old, outdated things mentioned at the end of the article will be finally removed in the future. I like it&#x27;s API for signals more than in SolidJS returning an array with setter and getter.
jcuenod超过 1 年前
I have a complicated spaghetti object that I need to render. Given:<p><pre><code> let spaghetti = $state(uglyMess) </code></pre> Does `uglyMess.thingOne[1].anotherThing = { moreMess }` re-render the whole tree or just the children of `uglyMess.thingOne[1].anotherThing`?
评论 #37589536 未加载
keb_超过 1 年前
I&#x27;m cautiously optimistic for this. My first instinct is that it doesn&#x27;t seem to provide much value add over just sticking with stores, which I think were already thoughtfully designed, but I won&#x27;t knock it till I&#x27;ve tried it.
revskill超过 1 年前
What you don&#x27;t get about React is that, in React, the reactivity atom is the component itself, not those state in useState. It&#x27;s encapsulated if you look from the outside. And what you really care is reactivity at the component level.
jaeming超过 1 年前
Yeah, you know that thing Vue did with the composition API that a bunch of their users didn&#x27;t like and then subsequently turned to Svelte over? Well, it turns out they were right and we&#x27;re going to do the same thing.
cayter超过 1 年前
Can anyone share how this change would help with your current app&#x2F;library? Would be great if we get to see how this change leads to real world use case improvement.
aarpmcgee超过 1 年前
For me, in both Firefox and Chrome (but not Safari), all the code samples look like this:<p><a href="https:&#x2F;&#x2F;imgur.com&#x2F;yGXHb1h" rel="nofollow noreferrer">https:&#x2F;&#x2F;imgur.com&#x2F;yGXHb1h</a><p>Anyone know what&#x27;s going on here?
bilekas超过 1 年前
&gt; Like every other framework, we&#x27;ve come to the realisation that Knockout was right all along.<p>I never had so much fun and understanding of a UI framework as I did when working with KnowckoutJS and DurandalJS way back when.
jcuenod超过 1 年前
I must say, when I see `$` in js, I think it is going to refer to a DOM element. Maybe the new kids don&#x27;t have those vestigial jquery instincts, but I dislike the use of $ for non-DOM element things.
nsonha超过 1 年前
Lots of roundabout thinking to eventually reinvent observable
meiraleal超过 1 年前
Honestly, quite the over-engineered solution for a problem they were supposed to solve. What does svelte brings to the table with this much complexity? Speed?
jamincan超过 1 年前
As I understand it, this should make it possible to subscribe to non-top-level stores and avoid having to use the horrible hack from svelte-subscribe.
aatd86超过 1 年前
Can you build a $derived from multiple other $derived?<p>If yes, how do you deal with two $derived sharing some dependencies?<p>Will the end result see temporary, half-updated values?
评论 #37590682 未加载
ilrwbwrkhv超过 1 年前
All of these frameworks like react vue svelte solid are basically the same framework.<p>If you actually want something different and better look at Imba.
wg0超过 1 年前
This seems better and makes JS uniform all across but I hope we don&#x27;t go to the nightmare called hooks. useXXX - please no.
tipiirai超过 1 年前
The canvas painting &#x2F; $effect() demo on the video was super cool! Is the source publicly available somewhere?
lakomen超过 1 年前
Aw man... It&#x27;s spreading. Soon Svelte will be identical to Vue, React and to a degree Angular. Why bother
yewenjie超过 1 年前
This is all great stuff but my silly mind was expecting new cool features from Svelte 5, not only DX improvements.
ramesh31超过 1 年前
If you collect them all, does Douglas Crockford magically appear to grant you three wishes?
EugeneOZ超过 1 年前
Same thing but without magic - Angular Signals.<p>I do not like magic in code.
karol超过 1 年前
I never expected that in 2023 someone will still be inventing new abstractions in JavaScript.<p>I see it a bit like chess now, there will always be people making progress on a particular opening and variant.
spankalee超过 1 年前
All these compilers and language forks, man...
sambeau超过 1 年前
Isn’t this just qwik?<p>Or have I missed something important?
评论 #37592467 未加载
评论 #37584845 未加载
jcuenod超过 1 年前
Now the only thing missing is JSX
sambeau超过 1 年前
Isn’t this just Qwik?<p>Or am I missing something important?
评论 #37584857 未加载
评论 #37585314 未加载
high_priest超过 1 年前
Svelte slowly shapeshifting into jquery. Day after day, methodical evolution.
评论 #37584429 未加载