6 ms·

It uses code-splitting, dynamic imports and hot module reloading, which are all well supported in webpack. We definitely plan to support Rollup as well, once it

It uses code-splitting, dynamic imports and hot module reloading, which are all well supported in webpack. We definitely plan to support Rollup as well, once it has those features — it should be possible to shrink down JS payloads by a reasonable amount. (Maybe Parcel too, eventually.) I think the 'too much API' feelings might be more unfamiliarity than anything. The API surface area is much smaller than anything like Angular, Vue etc, and although it's a fundamentally different approach to React I'd argue Svelte has a much shallower learning curve there as well. We're very open to feedback and suggestions though!

tobr 9y ago
Maybe it's just the documentation that is lacking, but when I've played with Svelte, the API and template syntax feels like a hodgepodge of special cases. For example, what exactly does a tag starting with colon mean? Is it just arbitrary syntax for things that don't fit in? What does a colon in an attribute mean? (i.e., why on:click rather than onclick or onClick or even something simpler like :onClick?) Why is there both {{#if condition}}Content{{/if}} and {{{condition && 'Content'}}}? I feel like all these different concepts break the "it's just HTML" promise, when it seems like it could be simplified a lot. Yes, JSX has similar gotchas, but at least it has references and specifications. And what's up with the crazy semantics of computed properties? Sorry if this sounds negative, but these have been genuine problems for me in getting a hang of Svelte.
- rich_harris 9y ago
 Colons indicate that something is a directive rather than an attribute — so `on:click` is the `on` directive with the `click` event, and `bind:thing` is the `bind` directive with the `thing` data property. The one place we violate that slightly is with `:foo`, which is shorthand for `foo={{foo}}` (since people dislike the ceremony of passing props down between components, and this makes it easier). {{#if condition}}...{{/if}} tells Svelte something about the structure of your app. {{{condition && 'Content'}}} doesn't, and you can't add interactivity to the if it's just a string. Moreover, if `condition` is `undefined`, then that's the string that will get rendered to the DOM. Generally, {{{triples}}} should be used for blobs of HTML you get from data sources, such as a blog post. If you can overcome your distaste for the computed property dependency injection, you'll hopefully find it's an extremely easy and compact syntax for declaring arbitrarily complex graphs of properties. The advantage of doing it this way is that Svelte can generate, at compile time, very efficient code for updating computed properties without any wasteful runtime dependency tracking. I realise it's slightly controversial (because it's a Svelte idiom, rather than something in JS itself), but for those who have embraced them, computed properties are one of the best features of Svelte!
 - deleted 9y ago
 [deleted]
 - atoko 9y ago
 That syntax looks arbitrary and frankly, hell to mantain. The cost:benefit ratio of learning all these idioms ("idioms", a huge red flag) doesn't seem efficient at all. I apologize for being blunt, yet I still recognize your work as great for pushing boundaries in web development. What made you turn away from javascript and into templates?
 - rich_harris 9y ago
 Simply put, you can do more with templates. It's the Principle of Least Power at work — the same way you can do more with a blob of JSON than a blob of JavaScript, templates allow you to do things that are basically impossible with JSX, such as compiling to a string concat function for server-side rendering that is much, much faster. Ask the teams behind Glimmer, Marko, and other tools, and they'll tell you the exact same thing. We've basically covered all those idioms in a few paragraphs. There's very little extra stuff to learn. Now if I may be blunt in return, I was converting the React RealWorld implementation to Svelte for the purposes of this post, and there were moments that I spat out my coffee at how absurd some of it was — twice as much code, with some truly bizarre (but idiomatic-to-React) constructs. It's all a matter of perspective and familiarity!
 - fineline 9y ago
 Hi Rich, I notice you mention Marko. That was my first thought when checking out Svelte today - Marko uses somewhat similar approach, and thus brings somewhat similar benefits. But Marko has couple of other advantages - beautiful "concise" syntax option, and easy debugging at dev time as the Lasso bundler turns JS modules into equivalent files in the browser, complete with same line numbering. (It only works with CommonJS modules, but that's what I prefer to use anyway as it allows unit testing in Node without transpilation.) What advantages would you say Svelte has that would make me consider using it over Marko? Thanks.
- arxpoetica 9y ago
 Just like anything, there's a small learning curve on syntax. Once you can get past your grievances (is HTML any less weird?), Svelte is extremely fast to build with.
- dsego 9y ago
 I'd love an attributes syntax akin to riot.js, less noise and blends into html nicely.

tobr 9y ago

Maybe it's just the documentation that is lacking, but when I've played with Svelte, the API and template syntax feels like a hodgepodge of special cases. For example, what exactly does a tag starting with colon mean? Is it just arbitrary syntax for things that don't fit in? What does a colon in an attribute mean? (i.e., why on:click rather than onclick or onClick or even something simpler like :onClick?) Why is there both {{#if condition}}Content{{/if}} and {{{condition && 'Content'}}}? I feel like all these different concepts break the "it's just HTML" promise, when it seems like it could be simplified a lot. Yes, JSX has similar gotchas, but at least it has references and specifications. And what's up with the crazy semantics of computed properties? Sorry if this sounds negative, but these have been genuine problems for me in getting a hang of Svelte.

rich_harris 9y ago
Colons indicate that something is a directive rather than an attribute — so `on:click` is the `on` directive with the `click` event, and `bind:thing` is the `bind` directive with the `thing` data property. The one place we violate that slightly is with `:foo`, which is shorthand for `foo={{foo}}` (since people dislike the ceremony of passing props down between components, and this makes it easier). {{#if condition}}...{{/if}} tells Svelte something about the structure of your app. {{{condition && 'Content'}}} doesn't, and you can't add interactivity to the if it's just a string. Moreover, if `condition` is `undefined`, then that's the string that will get rendered to the DOM. Generally, {{{triples}}} should be used for blobs of HTML you get from data sources, such as a blog post. If you can overcome your distaste for the computed property dependency injection, you'll hopefully find it's an extremely easy and compact syntax for declaring arbitrarily complex graphs of properties. The advantage of doing it this way is that Svelte can generate, at compile time, very efficient code for updating computed properties without any wasteful runtime dependency tracking. I realise it's slightly controversial (because it's a Svelte idiom, rather than something in JS itself), but for those who have embraced them, computed properties are one of the best features of Svelte!
- deleted 9y ago
 [deleted]
- atoko 9y ago
 That syntax looks arbitrary and frankly, hell to mantain. The cost:benefit ratio of learning all these idioms ("idioms", a huge red flag) doesn't seem efficient at all. I apologize for being blunt, yet I still recognize your work as great for pushing boundaries in web development. What made you turn away from javascript and into templates?
 - rich_harris 9y ago
 Simply put, you can do more with templates. It's the Principle of Least Power at work — the same way you can do more with a blob of JSON than a blob of JavaScript, templates allow you to do things that are basically impossible with JSX, such as compiling to a string concat function for server-side rendering that is much, much faster. Ask the teams behind Glimmer, Marko, and other tools, and they'll tell you the exact same thing. We've basically covered all those idioms in a few paragraphs. There's very little extra stuff to learn. Now if I may be blunt in return, I was converting the React RealWorld implementation to Svelte for the purposes of this post, and there were moments that I spat out my coffee at how absurd some of it was — twice as much code, with some truly bizarre (but idiomatic-to-React) constructs. It's all a matter of perspective and familiarity!
 - fineline 9y ago
 Hi Rich, I notice you mention Marko. That was my first thought when checking out Svelte today - Marko uses somewhat similar approach, and thus brings somewhat similar benefits. But Marko has couple of other advantages - beautiful "concise" syntax option, and easy debugging at dev time as the Lasso bundler turns JS modules into equivalent files in the browser, complete with same line numbering. (It only works with CommonJS modules, but that's what I prefer to use anyway as it allows unit testing in Node without transpilation.) What advantages would you say Svelte has that would make me consider using it over Marko? Thanks.
arxpoetica 9y ago
Just like anything, there's a small learning curve on syntax. Once you can get past your grievances (is HTML any less weird?), Svelte is extremely fast to build with.
dsego 9y ago
I'd love an attributes syntax akin to riot.js, less noise and blends into html nicely.