4 ms·

As much as i want to like it, i have troubles thinking of templates as something that questions the status-quo. The other big thing seems to be loading effort,

As much as i want to like it, i have troubles thinking of templates as something that questions the status-quo. The other big thing seems to be loading effort, but react has gotten so small (react+react-dom = 29kb, react+react-dom-lite 15kb, preact-compat 4kb), there's not really an impact any longer. And as for performance, could Svelte even approach something like the Sierpinski demo - something that would allow React to finally breach the gap between native and web performance? When look at fiber and react-reconciler, it seems to me react is already contemplating the future. The reconciler especially.

gedy 9y ago
Svelte is not "templates" (i.e. client-side), it compiles to JS modules
- dmitriid 9y ago
  Whatever it compiles down to in the end, it's stringly-typed templates with a custom syntax and weird assumptions about code that break everything you know about Javascript: scoping rules, variable declarations etc.
  - gedy 9y ago
    Okay, but JSX is not 'just JavaScript' either - it's a DSL embedded in JS. You could make the same argument that Svelte is 'just HTML' with a script block, style block etc.
    - mlsarecmg 9y ago
      Like typescript, flow or even es-next. An optional DSL that transpiles to pure javascript isn't an obstacle to programming. A string-template with an arbitrary syntax is an obstacle on the other hand.
      - Touche 9y ago
        svelte templates compile to "pure javascript".
        mlsarecmg 9y ago
        All template engines do. JSX doesn't get compiled but transpiled which makes all the difference. Therefore it works with the language, uses latest es-drafts without problems, is 100% typesafe as it can work with other supersets like TS or flow, it also doesn't rely on dependency injection and all the other annoyances. The biggest reason for me to prefer it: JSX is a simple but elegant solution to a decades old problem. A function signature was all it took to allow it to become cross platform and independent of the browser. A template engine comes at the expense of simplicity and flexibility. It needs so many abstraction and circumventions to function, injecting scope, evals, parsers, foreign syntax ... and for what, it most certainly doesn't make things easier.
    - dmitriid 9y ago
      Nope. True, JSX is thin XML-like DSL on top of Javascript. However, it uses Javascript everywhere. It never breaks assumptions about scoping, hoisting, where variables come from etc. You can skip JSX and write `React.createElement` everywhere, and nothing will change. Your code remains Javascript code. Unlike whatever svelte/sapper is. More details in a different comment: https://news.ycombinator.com/item?id=16053685 https://news.ycombinator.com/item?id=16053685 Nothing about svelte is "just HTML with styles and scripts". It's a yet another custom weird templating language with its own custom magic binding rules and a Javascript-like scripting language which breaks all assumptions about Javascript (methods/properties hoisting, invalid scoping rules, automatic data/variable injection etc. etc. etc.). And it's also just strings everywhere. And magic strings (as in "add $ to tell svelte the property comes from a store").
rich_harris 9y ago
You mean this Sierpinski demo? http://svelte-sierpinski.surge.sh/ http://svelte-sierpinski.surge.sh/ Ok, I'll level with you — that's not actually doing the same thing as the Fiber version. But that's it's basically impossible to accidentally slow down your Svelte app in the same way as the Fiber demo depends on. Fiber doesn't really speed things up so much as it prevents bad code slowing things down. The innovation isn't templates (though these aren't your grandad's templates), it's compiling those templates to lean, memory-efficient JS code that doesn't depend on virtual DOM reconciliation or anything like that.
- mlsarecmg 9y ago
  The whole point is the artificial slowdown. Taking it out makes it meaningless, it prints a few blue bubbles. Scheduling is and always will be the biggest bottleneck. It is that kind of innovation that keeps react relative. As for a lean dom representation, i have never seen or heard of memory related problems regarding v-dom. And won't byte-code make it leaner in any case? React-compiled is already being tested.
  - vanderZwan 9y ago
    "lean" is not limited to memory though - walking down the vdom reconciliation tree can incur get some pretty large overheads in terms of nested JS calls, just to decide that only a few buttons have to change. PureComponents and things like that are meant to help with this, but it still can take quite a bit of engineering effort to get this right. Mind you, I don't actually know if Svelte avoids this problem, but a statement like "doesn't depend on virtual DOM reconciliation or anything like that" kind of implies that it defaults to less work.

gedy 9y ago

Svelte is not "templates" (i.e. client-side), it compiles to JS modules

dmitriid 9y ago
Whatever it compiles down to in the end, it's stringly-typed templates with a custom syntax and weird assumptions about code that break everything you know about Javascript: scoping rules, variable declarations etc.
- gedy 9y ago
  Okay, but JSX is not 'just JavaScript' either - it's a DSL embedded in JS. You could make the same argument that Svelte is 'just HTML' with a script block, style block etc.
  - mlsarecmg 9y ago
    Like typescript, flow or even es-next. An optional DSL that transpiles to pure javascript isn't an obstacle to programming. A string-template with an arbitrary syntax is an obstacle on the other hand.
    - Touche 9y ago
      svelte templates compile to "pure javascript".
      - mlsarecmg 9y ago
        All template engines do. JSX doesn't get compiled but transpiled which makes all the difference. Therefore it works with the language, uses latest es-drafts without problems, is 100% typesafe as it can work with other supersets like TS or flow, it also doesn't rely on dependency injection and all the other annoyances. The biggest reason for me to prefer it: JSX is a simple but elegant solution to a decades old problem. A function signature was all it took to allow it to become cross platform and independent of the browser. A template engine comes at the expense of simplicity and flexibility. It needs so many abstraction and circumventions to function, injecting scope, evals, parsers, foreign syntax ... and for what, it most certainly doesn't make things easier.
  - dmitriid 9y ago
    Nope. True, JSX is thin XML-like DSL on top of Javascript. However, it uses Javascript everywhere. It never breaks assumptions about scoping, hoisting, where variables come from etc. You can skip JSX and write `React.createElement` everywhere, and nothing will change. Your code remains Javascript code. Unlike whatever svelte/sapper is. More details in a different comment: https://news.ycombinator.com/item?id=16053685 https://news.ycombinator.com/item?id=16053685 Nothing about svelte is "just HTML with styles and scripts". It's a yet another custom weird templating language with its own custom magic binding rules and a Javascript-like scripting language which breaks all assumptions about Javascript (methods/properties hoisting, invalid scoping rules, automatic data/variable injection etc. etc. etc.). And it's also just strings everywhere. And magic strings (as in "add $ to tell svelte the property comes from a store").

rich_harris 9y ago

You mean this Sierpinski demo? http://svelte-sierpinski.surge.sh/ http://svelte-sierpinski.surge.sh/ Ok, I'll level with you — that's not actually doing the same thing as the Fiber version. But that's it's basically impossible to accidentally slow down your Svelte app in the same way as the Fiber demo depends on. Fiber doesn't really speed things up so much as it prevents bad code slowing things down. The innovation isn't templates (though these aren't your grandad's templates), it's compiling those templates to lean, memory-efficient JS code that doesn't depend on virtual DOM reconciliation or anything like that.

mlsarecmg 9y ago
The whole point is the artificial slowdown. Taking it out makes it meaningless, it prints a few blue bubbles. Scheduling is and always will be the biggest bottleneck. It is that kind of innovation that keeps react relative. As for a lean dom representation, i have never seen or heard of memory related problems regarding v-dom. And won't byte-code make it leaner in any case? React-compiled is already being tested.
- vanderZwan 9y ago
  "lean" is not limited to memory though - walking down the vdom reconciliation tree can incur get some pretty large overheads in terms of nested JS calls, just to decide that only a few buttons have to change. PureComponents and things like that are meant to help with this, but it still can take quite a bit of engineering effort to get this right. Mind you, I don't actually know if Svelte avoids this problem, but a statement like "doesn't depend on virtual DOM reconciliation or anything like that" kind of implies that it defaults to less work.