11–20 of 186 posts
“Write less code”
Svelte has a ways to go to catch up with the leaders on popularity and future breadth, but it is focused on the right problem: reducing the cost/size/effort of making things.
I'm really impressed that the release announcement starts by explaining what Svelte is. It's a little thing, but it's appreciated.
I haven't used it yet but I really like the idea of Svelte, just how I really enjoy using Preact over React for certain projects. One question about version 3. I was wondering if they addressed the issue of how a Svelte code base can grow in size larger[1] than a Preact based codebase the bigger it gets. [1] https://medium.com/@chrisdaviesgeek/tiny-js-frameworks-preac...
Creator here. We get this question a lot, and should probably dedicate a blog post to it. It's true that the incremental cost per-component is higher than with some frameworks. In theory, you hit an inflection point. In practice though this doesn't really happen, because by the time you get there, you should be code-splitting anyway — and each of your code-split chunks have a hard minimum size which is the size of th…
Keep up the good work! I think Svelte is really cool. Like I said before, I like the idea of it. I am going to promote it to the rest of my team and hopefully we can give it shot on one of our next projects.
I'm excited about the updated Svelte. Although it is currently nowhere near being in the top handful of frameworks by adoption, it has some very forward ideas. Most prominently, look at the first main value proposition on its website: “Write less code” Svelte has a ways to go to catch up with the leaders on popularity and future breadth, but it is focused on the right problem: reducing the cost/size/effort of making…
One small question about some of the pragmatic choices in Svelte 3: What was the decision process behind choosing to smuggle the new reactive features under a "standard" JavaScript skin? ($:, export let, etc.) Is it just to avoid needing to rewrite all existing JS tooling — parsing, syntax highlighting, linting — or is there something deeper going on?
That's not a bad thing - that's the "good" kind of Reactivity and how most UI should be written IMO - it involves significantly less boilerplate.
Congratulations on the launch, Rich! It's looking like we're really starting to approach the form and function of what "a language to build the web" ought to be. One small question about some of the pragmatic choices in Svelte 3: What was the decision process behind choosing to smuggle the new reactive features under a "standard" JavaScript skin? ($:, export let, etc.) Is it just to avoid needing to rewrite all exist…
It's exactly that — there's so much tooling in the JS ecosystem that we can lean on, and by inventing new syntax we'd be throwing all that away. It'd be great if we could do `prop answer = 42` and `a <= b`, but it's just not worth it — once you get used to `export let` and `$: a = b` it quickly becomes second nature, we've found.
Odd that they don't mention Angular amongst the component-based frameworks, as what they're describing sounds very similar to Angular's compiler and change-detection system.
This is actually quite similar to what PostSharp did with WPF where it injected INotifyPropertyChanged and WPF compiling its getters and setters.
Then it's also similar to KnockoutJS (inspired by WPF), MobX (inspired by Knockout) and Vue (also inspired by Knockout)
So basically mostly the same thing MobX does in React and Vue does out of the box? That's not a bad thing - that's the "good" kind of Reactivity and how most UI should be written IMO - it involves significantly less boilerplate.
It's also worth noting that this approach means there's none of the overhead involved in creating proxies.
So basically mostly the same thing MobX does in React and Vue does out of the box? That's not a bad thing - that's the "good" kind of Reactivity and how most UI should be written IMO - it involves significantly less boilerplate.