I'm very intrigued by Svelte and I really hope that it will succeed. In that sense I also hope that this is the last major version, i.e. no more breaking changes. That would be fantastic!
Does anyone here have a major, non trivial app in production that's built on Svelte?
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.
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 the framework.
thanks for the response! Interesting that this article you linked did not include Preact in its tests but I do see what you mean.
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.
How does Svelte compare directly
To more minimal Reactive libraries like most.js or flyd.js? Even MobX? Besides the dissapearing at runtime? It looks very cool I'd like to see how it performs with some complex DOM opps. Might mess around today.
Agreed. I really appreciated him not assuming I know -fucking everything- and his WHAT included the WHY. ‘WHY’ (intent) is far more important an is missing from many different technical industries.
Tell me how you intend it to be used and I’ll see if that matches what I think I want (miss-wanting a different topic!).
In particular, I think this is a recognition of the fact that people these days don't follow random projects, but they do follow social media feeds and news aggregators like HN or Reddit. So an average reader may come to the post not because they know and care about Svelte, but because the link being on their favourite aggregator lent it credence as something worth reading.
It's really not a little thing. The number of blog posts that talk about why version N+1 of X is great, assuming I know what X or version N did is stupid, and I am immediately churned out.
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.
Svelte as a lot in common with Angular, arising from the decision to use a component compiler at build time. But culturally it appears most attention to Svelte comes from a React direction, so Svelte is most often described as a “diff” from React.
You could possibly predict the future of Angular and Svelte by comparing them and looking for ways to cross-pollinate.
Great work, just looking in to Svelte now after reviewing your latest release and video. First thing I looked for was routing, and I see Sapper is essentially batteries-included solution to using Svelte.
Will these always be separate libraries?
Is Sapper basically the create-svelte-app for your framework?
What's the roadmap for Sapper and integrating Svelte v3 changes?
Bringing Sapper up to date is the next big task. In some ways yes, it's a bit like create-svelte-app, though a closer reference point if you're versed in the React world would be Next.js.
We've also mulled creating a React Router equivalent, for people who prefer components-as-routes to files-as-routes.
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 things.
Funny: problems I think are important are "ship less code" and "read less code" (and perhaps "require reading less code to understand what's going on"). The writing part is not something I've considered to be especially problematic, thus far.
Edit: Some more clarification about why the arguments don't hold for me.
- More code = more bugs
I think code that is harder to understand leads to more bugs, but more characters typed does not necessarily directly result in more bugs, as far as I know.
- Writing code takes more time
Again, it's not the typing that takes time, but thinking of which code to write. If I have to type more, but there's less for me to keep in mind while typing (i.e. lower cognitive load), I'll be faster at that.
As said: yes, readability is important, but that's a different value than "write less code".
I'm trying not to make a judgment about Svelte here specifically since I haven't worked with it yet, and the general concept (of being a compiler rather than working during run-time) appeals to me. That said, concepts like bindings do scare me - with e.g. `useState` I know that the only places that can change `a` are those that call `setA`, whereas it appears that with Svelte, it can also change e.g. in response to `bind:value` attributes? I'm (perhaps misguidedly) afraid that that's saving a few characters at the cost of readability.
> more characters typed does not necessarily directly result in more bugs, as far as I know
Most of the discussions I could find on the topic before writing that post suggested that the error rate per thousand lines of code is surprisingly constant across languages, which suggests that more characters typed does result in more bugs. I learned that from the internet though, so take it with a grain of salt!
It's true that `bind:value={foo}` offers another way to change the value of `foo` besides `foo += 1`, since at that point you're explicitly opting in to two-way binding. If you prefer, you certainly can do the `on:change={handler}` thing instead, but as I argue in the post I think that's less effective at capturing the intent of your code (and gives bugs more places to hide). This is definitely a subjective area though.
> Most of the discussions I could find on the topic before writing that post suggested that the error rate per thousand lines of code is surprisingly constant across languages, which suggests that more characters typed does result in more bugs. I learned that from the internet though, so take it with a grain of salt!
It's an interesting subject, but I'd like a causal explanation rather than just the correlation. For example, this would imply that TypeScript code would be more buggy than its Javascript equivalent, since it's the same code I'd write otherwise, with additional annotations. (Then again, there is some code, like null checks, that I don't have to write with TypeScript, so perhaps that evens out.)
> I think that's less effective at capturing the intent of your code
It's been a while since I've worked with Angular.js, the last framework I used with two-way databinding, but now having this conversation I think I recall the main reason it was confusing. A pattern that would sometimes arise is e.g. for a component to receive data through a two-way databinding from its parent, and then likewise passing that on to a child. That could make it very hard to trace where a change was coming from.
It might well be the case that it is far less problematic when e.g. only used to bind form values. Again, I'd have to try it to get a proper feel for it, so I'm looking forward to doing that.
> It's an interesting subject, but I'd like a causal explanation rather than just the correlation.
A large benefit with less code is about the signal/noise ratio. If you need plenty of boiler plate logic, you will have less signal that you can physically read & mentally process at a given time. We naturally ignore the noise, but the noise takes screen space & miscategorizing noise leads to bugs.
Less code leads to less bugs, especially high-level bugs, because the programmer can see more signal at a given time, thus being exposed to a larger system.
The study that Rich mentioned could be interpreted as relating to the comprehension of the code, where more code inherently means the system has more information & is more difficult to comprehend.
Re: two-way binding, the data flow is inherently confusing whether you use imperative or declarative logic. Do you want a clear concise representation or do you want to spread out the implementation over more code/files?
Absolutely, and "higher signal-to-noise-ratio" is something I'd count as a selling point. However, I don't believe fewer characters necessarily result in a higher ratio.
So in the case of two-way data binding, if I'm trying to trace how a certain value was be modified, data flow in the opposite direction might count as "noise", in terms of extra cognitive load.
Again, this might not be something that is the case for Svelte, but it's what I observed in Angular.js.
I have not used Go, or even looked at it, so I can't really give a well-reasoned comment about it. As for the general principle of having just one way to do something: I don't think that's a general rule that I'd prefer, because I don't believe there's always a clear best way.
I think my problem with two-way data binding is not so much that it's an additional way to update a value, but that it doubles up as reading and writing a value, and with that makes code somewhat harder to read. However, as I noted in response to Rich, that might not be a problem if that is only limited to variables bound to forms, but I'd have to try it to get a better feeling for that.
But I'm getting off-topic, so the answer is: I don't really have an opinion about Go, but the general principle you describe is not one that attracts me.
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 existing JS tooling — parsing, syntax highlighting, linting — or is there something deeper going on?
Thanks Jeremy! As I've expressed elsewhere, observablehq.com provided important inspiration. I've also been influenced by your own comments in the past about a language for building web apps.
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.
It's not reactive, but it doesn't need to since everything is memoized. I think it's interesting that they made their own language to solve the front end problem.
I have seen it, yes. I'm impressed by the ambition, though I think that in the long term it's better to work with the grain of the platform by extending the web's existing languages rather than creating a new one.
Memoization certainly makes Imba a lot faster than VDOM-based frameworks. Of course, it's only really beneficial when not many things have changed!
Your article says about `count += 1` that "we can do all this without the overhead and complexity of using proxies or accessors. It's just a variable."
But it's not just a variable; it's a magic variable that $$invalidates its contents. I'd be much happier to write `state.count += 1` and allow my debugger to step into the proxy in dev mode, but then have the production compiler convert the proxy into a direct call to $$invalidate to minimize runtime overhead and support legacy non-proxy browsers.
Firstly, that's more code you're having to write (and object property names don't typically get mangled, so you'll end up shipping more code as well as writing more code). Write less code! https://svelte.dev/blog/write-less-code
Yes! I talk a bit about prior art in this section of a recent talk: https://youtu.be/AdNJ3fydeao?t=504. (Michel Weststrate, the MobX creator, was in the audience!) The difference in how you end up writing your code when you don't have a `this` turns out to be quite profound, and is the main reason that Svelte components are so concise: https://svelte.dev/blog/write-less-code
It's also worth noting that this approach means there's none of the overhead involved in creating proxies.
I was actually physically close to YGLF but unable to attend, I spoke there at a previous year. Michel is a friend and I collaborated with him on MobX. He's also one of the nicest people I know and he visits often.
I think you might want to check out WPF + PostSharp for something very similar to this approach in C# land. I definitely think it's the right approach for reactivity.
Also, thanks for rollup, I've used it today and it was a lot of fun to work with. I was up and running (after experience with webpack) very quickly and everything I needed was well maintained and I was pleasantly surprised!
The main blocker for me adopting Svetle (and opting for Vue and React) is tooling to be honest. I want code that has a lot of visibility, meaningful stack traces and the debugger stopping in relevant places. If Svetle 3 does everything synchronously (like MobX) I'd love to check it out!
Updates are asynchronous (they happen at the end of the event loop, so that `x = 1; y = 2;` results in one update instead of two), but I hear you on tooling. Svelte isn't yet as mature as other frameworks on that front (though debugging isn't bad in my experience). One day soon, hopefully!
> A11y: <img> element should have an alt attribute
> When building web apps, it's important to make sure that they're accessible to the broadest possible userbase, including people with (for example) impaired vision or motion, or people without powerful hardware or good internet connections. Accessibility (shortened to a11y) isn't always easy to get right, but Svelte will help by warning you if you write inaccessible markup.
Thank you! We accessibility advocates have wanted this kind of checking to be built into mainstream development tools for years. I hope Svelte becomes popular for this reason alone.
Eslint already warns you about issues like this, and is framework-agnostic. Does Svelte just use eslint under the hood? Otherwise you risk fracturing the ecosystem with framework-specific a11y requirements.
Accessibility requirements for the web have a centralized source in the WCAG. As long as linters/checkers conform to that, it doesn’t seem like it should be a source of fragmentation.
Since you are reading here Rich Harris; while I really admire your solutions, one weak point with Svelte seems to be a clear unit testing solution, or at least docs last I looked. I also noticed this with Ractive, and feel it weakens these in the eyes of many businesses considering these tools.
I know it's a solved/solvable problem but it feels like better docs and samples in quick start guides would help.
I admire Rich Harris' work as well. 4 years ago I was picking my first SPA framework. Narrowed it down to Ractive and Vue. Picked ractive, it had a beautiful documentation and tutorial. Still have an app in production based on ractive.
But author abandoned it. Then vue 2 took off. I didn't have a choice but switch. Recently I started playing with Svelte/Sapper again. I like it a bit better than vue for some reason and was looking to use it in the next project of mine. So svelte 3 comes at right time for me.
The author is a brilliant developer, but he should narrow his focus on Sapper/Svelte now, beside which he has many other projects (rollup, etc...)
Would you consider adding a way to set tag names in a component dynamically? I’ve found that to be incredibly useful in React, when you want to encapsulate some behavior but use it in different semantic contexts across an app.
Or is it possible already somehow? I tried to use
<svelte:component this={“h1”} ...
but it doesn’t appear to support strings, just Svelte components?
Sort of, via preprocessing, but you won't get any real benefit from it at present. There are two barriers: the compiler itself needs to become TS-aware, and we need to teach editors like VSCode how to typecheck inside <script> blocks.
It's very much on the radar (I'm a TS convert, personally — Svelte itself is written in TypeScript), we just need to get round to it. The version 3 rewrite was largely about laying the foundations for TS support.
Svelte itself has been on my radar for quite a while - I think when proper TypeScript support lands, that will be the first time I'll actually give it a try for one project or another. The idea is intriguing, thanks for working on it!
Do you have any estimate on how much work that'll be? Do you think you'll be able to land TS support (including type-checking through the command line) within half a year, or is that a bigger thing?
Basically, I separate out the <script> & <html> section into two files. The <script> part is generated from typescript and combined later before sending it into the svelte compiler.
I am currently working on a gulp build file to streamline the process.
That is pretty terrible! It seems to me that the main think that distinguishes Svelt is that more work is done at compile-time? Why not a slogan that says just that?
"Compile-time optimised reactivity." or "Low overhead reactive web apps" or something like that. Cybernetics is nonsense waffle.
Anyway good luck! Seems like a better approach than shadow DOM etc.
Agreed: compile-time optimization is a pretty good pitch. Rust and Typescript and Haskell have done all the PR necessary for this pitch; you have a prepared audience.
"Less code" implies less authored code, which may be a benefit of Svelte (is it? I haven't been able to use it much but it's on my radar) but doesn't necessarily map to its technical goals (less built code, less runtime processing).
(Quick example: the countless hello world projects that result in >100KB bundles)
You're not just moving web dev in a better direction, but also fact and data based journalism and visualization! I first learned of Svelt and Rollup (and became your fan) when I asked how you made that great NYT article, The Follower Factory! I'm glad you've kept working on Svelt, and I can't wait to see what you do next.
One area where the virtual DOM seems to be important is for rich text editors, where the VDOM can basically take the input, diff it using an immutable structure, then render it to properly structured HTML.
An example use case where this would be valuable: a user hightlights text, bolds it, then highlights it again plus some more text, and bolds it. A naive approach would have: <b><b>This text is bolded</b> plus I bolded this</b> when what you want would simply be: <b>This text is bolded plus I bolded this</b>
Libraries like DraftJS and SlateJS use immutable data structures to parse the input/formatting in the VDOM and reconcile them into "blocks" (basically javascript objects containing the formatting) that deduplicate formatting.
Rich text editing is possibly a special case, though the right person to ask about that would be Jacob Wright (https://github.com/jacwright). He's the creator of https://www.dabblewriter.com (which uses Svelte) and a Svelte contributor, so he probably knows more about this topic than just about anyone else!
I'd argue that a rich text editor tied to a framework is inflexible, and possibly inefficient. You want a rich text editor to be good at one thing, editing, and not be concerned with how it's invoked.
A good editor would be standalone, with wrappers to make it callable from a framework of your choosing.
Most good rich editors implement their own internal Dom to achieve uniformity across browsers. DraftJs, Quill, Trix... use this strategy. There's nothing unique to react-Dom that benefits rich text editing
An important feature of a good framework is to be able to break out when needed to do normal JS, so I imagine you’d do that and grab a regular editor component.
Svelte looks amazing. Some questions that occurred to me:
- Does it work with TypeScript?
- How does it relate to other reactive frameworks, such as RXJS? Does it make sense to use them together or does the Svelte compiler invalidate the benefits of them?
Basically, I separate out the <script> & <html> section into two files. The <script> part is generated from typescript and combined later before sending it into the svelte compiler.
I am currently working on a gulp build file to streamline the process.
Nice handling of reactivity - I think this should already be in language as well.
I'm not sure I like this single components approach and embedding JS in HTML.
The problem with this is that it's too frameworkish.
The big benefit of JSX/React rendering is that it's composable and declarative (as it's just functions), but it's also simple to get - render just returns wanted structure, given the state and you can use simple assert to verify that.
Solutions like angular/vue/svelte rely on custom template parsing which IMO sucks, because it's hard to extend/test without specific template compilers. JSX in contrast is embracing language.
I think that render functions written like in react and data reactivity is the simplest approach to describe application. Seems like VueJS with JSX is closest to this right now.
It would be cool to keep similar API but maybe use compiling to have smaller bundle/older browsers support/different platform support etc.
To be clear by similar API I mean just pure JSX components, where you plugin reactive data, that could be tested without any frameworks and without rendering. This is the simplest way, yet nobody build it yet - MobX + pure React components is close to this (problem is that still rendering is done by React, so rendering isn't most performant - depends on components hierarchy) - with compilation/integration you could make it more performant, but I would keep declararive nature and simplicity of JSX.
This is actually a feature, considering what Svelte does. I know of more than a few efforts to implement similar compile-time production of low level procedural code from React components, but so far nobody's been quite able to do it. And this is despite these efforts coming from some very smart people. The reason this is so hard to do for React is precisely because Javascript is a huge target with a ton of bizarre quirks and edge cases.
> To be clear by similar API I mean just pure JSX components, where you plugin reactive data,
I think Solid.js is the closest thing to this atm. Not React-based though.
Mobx-state-tree is a really nice balance of state management that also is compatible with all the nice Redux browser tools https://github.com/mobxjs/mobx-state-tree
Their interactive tutorial with sandboxes is really impressive. That's a great onramp into actual usage. It might also be cool to have a good way to "eject" the sandbox into a functional local build.
Anything built inside https://svelte.dev/repl has a 'download' icon (top right) which gives you a zip file containing a ready-made project. We basically just need to have a way to take you from tutorial/example pages to the equivalent REPL page — it's on the TODO list :)
Hey Rich if you're still lurking - I really like the Tutorial layout (even on mobile!) and how that all works. Is this something you built yourself or is there a re-usable component that I can use?
Minor suggestion: it should be easier to find how to get started (read install) for people trying to give Svelte a try. I had already played a bit with Svelte before but wanted to try v3 and the only thing I could find about how to install it was in https://svelte.dev/blog/the-easiest-way-to-get-started.
> this.set is almost identical to the this.setState method used in classical (pre-hooks) React
It's an amazing reflection on the velocity of the web & JS ecosystem that React APIs prior to hooks, which were shipped all of 3 months ago, can be sincerely referred to now as 'classical' :-)
> Instead, Svelte runs at build time, converting your components into highly efficient imperative code that surgically updates the DOM.
So, Svelte is compiled into web assembly? If not, given the emitted imperative code is less efficient than emitted web assembly and the emitted imperative code is less concise than the original declarative code, then what would be the advantage of an imperative translation of the declarative Javascript code compared to emitted web assembly or the original?
185 comments
[ 2.1 ms ] story [ 234 ms ] threadDoes anyone here have a major, non trivial app in production that's built on Svelte?
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...
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 the framework.
This article reinforces that finding by testing the 'RealWorld' project: https://medium.freecodecamp.org/a-realworld-comparison-of-fr.... It's based on an outdated version of Svelte but the broad strokes will be unchanged.
Of course, Svelte is about far more than just bundle size!
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.
Tell me how you intend it to be used and I’ll see if that matches what I think I want (miss-wanting a different topic!).
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)
You could possibly predict the future of Angular and Svelte by comparing them and looking for ways to cross-pollinate.
The gist of Immer is that your framework needs immutable structures, but you want to interact with them imperatively.
It's very interesting, and a reversal of the traditional "functional core, imperative shell" architecture.
https://github.com/immerjs/immer
Will these always be separate libraries? Is Sapper basically the create-svelte-app for your framework? What's the roadmap for Sapper and integrating Svelte v3 changes?
We've also mulled creating a React Router equivalent, for people who prefer components-as-routes to files-as-routes.
https://redux-starter-kit.js.org/api/createreducer
“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.
Edit: Some more clarification about why the arguments don't hold for me.
- More code = more bugs
I think code that is harder to understand leads to more bugs, but more characters typed does not necessarily directly result in more bugs, as far as I know.
- Writing code takes more time
Again, it's not the typing that takes time, but thinking of which code to write. If I have to type more, but there's less for me to keep in mind while typing (i.e. lower cognitive load), I'll be faster at that.
As said: yes, readability is important, but that's a different value than "write less code".
I'm trying not to make a judgment about Svelte here specifically since I haven't worked with it yet, and the general concept (of being a compiler rather than working during run-time) appeals to me. That said, concepts like bindings do scare me - with e.g. `useState` I know that the only places that can change `a` are those that call `setA`, whereas it appears that with Svelte, it can also change e.g. in response to `bind:value` attributes? I'm (perhaps misguidedly) afraid that that's saving a few characters at the cost of readability.
Most of the discussions I could find on the topic before writing that post suggested that the error rate per thousand lines of code is surprisingly constant across languages, which suggests that more characters typed does result in more bugs. I learned that from the internet though, so take it with a grain of salt!
It's true that `bind:value={foo}` offers another way to change the value of `foo` besides `foo += 1`, since at that point you're explicitly opting in to two-way binding. If you prefer, you certainly can do the `on:change={handler}` thing instead, but as I argue in the post I think that's less effective at capturing the intent of your code (and gives bugs more places to hide). This is definitely a subjective area though.
It's an interesting subject, but I'd like a causal explanation rather than just the correlation. For example, this would imply that TypeScript code would be more buggy than its Javascript equivalent, since it's the same code I'd write otherwise, with additional annotations. (Then again, there is some code, like null checks, that I don't have to write with TypeScript, so perhaps that evens out.)
> I think that's less effective at capturing the intent of your code
It's been a while since I've worked with Angular.js, the last framework I used with two-way databinding, but now having this conversation I think I recall the main reason it was confusing. A pattern that would sometimes arise is e.g. for a component to receive data through a two-way databinding from its parent, and then likewise passing that on to a child. That could make it very hard to trace where a change was coming from.
It might well be the case that it is far less problematic when e.g. only used to bind form values. Again, I'd have to try it to get a proper feel for it, so I'm looking forward to doing that.
A large benefit with less code is about the signal/noise ratio. If you need plenty of boiler plate logic, you will have less signal that you can physically read & mentally process at a given time. We naturally ignore the noise, but the noise takes screen space & miscategorizing noise leads to bugs.
Less code leads to less bugs, especially high-level bugs, because the programmer can see more signal at a given time, thus being exposed to a larger system.
The study that Rich mentioned could be interpreted as relating to the comprehension of the code, where more code inherently means the system has more information & is more difficult to comprehend.
Re: two-way binding, the data flow is inherently confusing whether you use imperative or declarative logic. Do you want a clear concise representation or do you want to spread out the implementation over more code/files?
So in the case of two-way data binding, if I'm trying to trace how a certain value was be modified, data flow in the opposite direction might count as "noise", in terms of extra cognitive load.
Again, this might not be something that is the case for Svelte, but it's what I observed in Angular.js.
I think my problem with two-way data binding is not so much that it's an additional way to update a value, but that it doubles up as reading and writing a value, and with that makes code somewhat harder to read. However, as I noted in response to Rich, that might not be a problem if that is only limited to variables bound to forms, but I'd have to try it to get a better feeling for that.
But I'm getting off-topic, so the answer is: I don't really have an opinion about Go, but the general principle you describe is not one that attracts me.
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?
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.
Hey Rich have you seen Imba?
http://imba.io/
It's not reactive, but it doesn't need to since everything is memoized. I think it's interesting that they made their own language to solve the front end problem.
They used it to build https://scrimba.com/ which is pretty awesome.
Memoization certainly makes Imba a lot faster than VDOM-based frameworks. Of course, it's only really beneficial when not many things have changed!
Your article says about `count += 1` that "we can do all this without the overhead and complexity of using proxies or accessors. It's just a variable."
But it's not just a variable; it's a magic variable that $$invalidates its contents. I'd be much happier to write `state.count += 1` and allow my debugger to step into the proxy in dev mode, but then have the production compiler convert the proxy into a direct call to $$invalidate to minimize runtime overhead and support legacy non-proxy browsers.
You can easily debug reactive variables, either using the `{@debug ...}` tag in the template (https://svelte.dev/examples#debug) or by using `debugger` in your script tag (https://svelte.dev/repl?version=3.0.0&gist=adc35e969343aad60...).
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.
We're working on a project with MobX 5 and mid project we realized some of our users on iOS 9 or KitKat do not have Proxy.
I think you might want to check out WPF + PostSharp for something very similar to this approach in C# land. I definitely think it's the right approach for reactivity.
The main blocker for me adopting Svetle (and opting for Vue and React) is tooling to be honest. I want code that has a lot of visibility, meaningful stack traces and the debugger stopping in relevant places. If Svetle 3 does everything synchronously (like MobX) I'd love to check it out!
> Svelte is giving us a warning:
> A11y: <img> element should have an alt attribute
> When building web apps, it's important to make sure that they're accessible to the broadest possible userbase, including people with (for example) impaired vision or motion, or people without powerful hardware or good internet connections. Accessibility (shortened to a11y) isn't always easy to get right, but Svelte will help by warning you if you write inaccessible markup.
Thank you! We accessibility advocates have wanted this kind of checking to be built into mainstream development tools for years. I hope Svelte becomes popular for this reason alone.
I know it's a solved/solvable problem but it feels like better docs and samples in quick start guides would help.
The author is a brilliant developer, but he should narrow his focus on Sapper/Svelte now, beside which he has many other projects (rollup, etc...)
To be clear though, Ractive is still under development by other maintainers: https://github.com/RactiveJS/Ractive.
> he should narrow his focus
Not to speak for him, but I think Rich is an "idea guy" and we'd all miss out if he were throttled to just one thing :-)
Some of the coolest and most beautiful names I've heard in the industry. :)
Or is it possible already somehow? I tried to use
but it doesn’t appear to support strings, just Svelte components?It's very much on the radar (I'm a TS convert, personally — Svelte itself is written in TypeScript), we just need to get round to it. The version 3 rewrite was largely about laying the foundations for TS support.
Basically, I separate out the <script> & <html> section into two files. The <script> part is generated from typescript and combined later before sending it into the svelte compiler.
I am currently working on a gulp build file to streamline the process.
Let me know what you think.
> Cybernetically enhanced web apps
That is pretty terrible! It seems to me that the main think that distinguishes Svelt is that more work is done at compile-time? Why not a slogan that says just that?
"Compile-time optimised reactivity." or "Low overhead reactive web apps" or something like that. Cybernetics is nonsense waffle.
Anyway good luck! Seems like a better approach than shadow DOM etc.
Is not AOT compilation is a more traditional name for such stuff?
Dymaxion: dynamic, maximum, and tension -- maximum gain of advantage from minimal energy input.
https://en.wikipedia.org/wiki/Dymaxion
Simply zip all your content into a sleek .ddu file and upload it to the server:
https://en.wikipedia.org/wiki/Dymaxion_deployment_unit
or "Faster, smaller, web apps?"
They seem to be the main benefits for using Svelte.
(Quick example: the countless hello world projects that result in >100KB bundles)
https://www.nytimes.com/interactive/2018/01/27/technology/so...
https://news.ycombinator.com/item?id=16247571
http://lesscode.org/
Ouroboros: the tail recursive self devouring snake!
I didn't even think it was an English word before I watched Rich's (great) talk.
It gives an inkling of the functionality and most importantly avoids “cybernetically” which makes the framework sound kooky.
An example use case where this would be valuable: a user hightlights text, bolds it, then highlights it again plus some more text, and bolds it. A naive approach would have: <b><b>This text is bolded</b> plus I bolded this</b> when what you want would simply be: <b>This text is bolded plus I bolded this</b>
Libraries like DraftJS and SlateJS use immutable data structures to parse the input/formatting in the VDOM and reconcile them into "blocks" (basically javascript objects containing the formatting) that deduplicate formatting.
The talk below on DraftJS is pretty good.
https://www.youtube.com/watch?v=feUYwoLhE_4
What's the recommended way to handle a rich text application in Svelte? Is there anything like the above for Svelte?
https://github.com/typewriter-editor/typewriter
A good editor would be standalone, with wrappers to make it callable from a framework of your choosing.
Most good rich editors implement their own internal Dom to achieve uniformity across browsers. DraftJs, Quill, Trix... use this strategy. There's nothing unique to react-Dom that benefits rich text editing
- Does it work with TypeScript?
- How does it relate to other reactive frameworks, such as RXJS? Does it make sense to use them together or does the Svelte compiler invalidate the benefits of them?
- Does it work with any existing components?
Basically, I separate out the <script> & <html> section into two files. The <script> part is generated from typescript and combined later before sending it into the svelte compiler.
I am currently working on a gulp build file to streamline the process.
Let me know what you think.
I'm not sure I like this single components approach and embedding JS in HTML.
The problem with this is that it's too frameworkish.
The big benefit of JSX/React rendering is that it's composable and declarative (as it's just functions), but it's also simple to get - render just returns wanted structure, given the state and you can use simple assert to verify that.
Solutions like angular/vue/svelte rely on custom template parsing which IMO sucks, because it's hard to extend/test without specific template compilers. JSX in contrast is embracing language.
I think that render functions written like in react and data reactivity is the simplest approach to describe application. Seems like VueJS with JSX is closest to this right now.
It would be cool to keep similar API but maybe use compiling to have smaller bundle/older browsers support/different platform support etc.
To be clear by similar API I mean just pure JSX components, where you plugin reactive data, that could be tested without any frameworks and without rendering. This is the simplest way, yet nobody build it yet - MobX + pure React components is close to this (problem is that still rendering is done by React, so rendering isn't most performant - depends on components hierarchy) - with compilation/integration you could make it more performant, but I would keep declararive nature and simplicity of JSX.
This is actually a feature, considering what Svelte does. I know of more than a few efforts to implement similar compile-time production of low level procedural code from React components, but so far nobody's been quite able to do it. And this is despite these efforts coming from some very smart people. The reason this is so hard to do for React is precisely because Javascript is a huge target with a ton of bizarre quirks and edge cases.
> To be clear by similar API I mean just pure JSX components, where you plugin reactive data,
I think Solid.js is the closest thing to this atm. Not React-based though.
Minor suggestion: it should be easier to find how to get started (read install) for people trying to give Svelte a try. I had already played a bit with Svelte before but wanted to try v3 and the only thing I could find about how to install it was in https://svelte.dev/blog/the-easiest-way-to-get-started.
It's an amazing reflection on the velocity of the web & JS ecosystem that React APIs prior to hooks, which were shipped all of 3 months ago, can be sincerely referred to now as 'classical' :-)
So, Svelte is compiled into web assembly? If not, given the emitted imperative code is less efficient than emitted web assembly and the emitted imperative code is less concise than the original declarative code, then what would be the advantage of an imperative translation of the declarative Javascript code compared to emitted web assembly or the original?
The code you write in Svelte is reactive/declarative, emitted code is regular imperative JS.