Question: Philosophy

[sveltejs]

Question: Philosophy

[Rich-Harris]

One of the big mistakes I made with Ractive was making everything super-flexible, on the assumption that the developer always knows better than the framework author. Sometimes that's true, but sometimes it isn't – if you're too flexible, the allowances you have to make can lead to surprising performance characteristics, and then it's the dev's responsibility to understand those characteristics (which often change between versions!) and design their app accordingly. The hard truth is that in those cases the framework author does know best.

A good example would be the fact that data bindings aren't set until run time – it's very easy for parts of the template to be completely ambiguous (what is bar in {{#with foo}}{{bar}}{{/with}}?), and that has huge non-obvious performance implications.

So Svelte's philosophy is this: the framework gives you a stricter template syntax, and will yell at you at compile time if you colour too far outside the lines. Components can have no implicit dependencies (in Ractive, components can have isolated: true which is similar – in Svelte there's no isolated: false). In return, you get very lean generated code with excellent (and predictable) performance, and as a side-effect, anyone familiar with the Svelte syntax (which is very similar to Ractive, but with a few improvements) can easily read any Svelte component, and any Svelte component can be dropped in to any application with basically zero friction.

Another way of stating it: Svelte does a lot of work at compile time so that the browser needs to do very little work at run time. In order to do that, it imposes certain restrictions.

Now, the thing we got right with Ractive was that you can build basically anything with it. And Svelte needs to be the same if anyone is going to use it – even if that just means providing the right escape hatches. So far, I haven't been able to think of anything Ractive or Vue or React can do that's intrinsically impossible with Svelte's architecture, but I'm on the lookout.

For example, we could create a lazy loading sidebar like so:

<!-- Sidebar.html -->
<div ref:container></div>

<script>
  export default {
    onrender () {
      // using the future import() syntax – but it could be AMD or whatever
      import( './SidebarImplementation.html' ).then( Sidebar => {
        if ( this.torndown ) return; // in case it happens before the implementation loads
        this.implementation = new Sidebar({ target: this.refs.container });
      });
    },

    onteardown () {
      if ( this.implementation ) this.implementation.teardown();
      this.torndown = true;
    }
  };
</script>

That could be abstracted out into a generic <LazyComponent implementation='{{Sidebar}}'/> component.

Thanks for the question and for noticing this project – should have more to say about it publicly very soon 😀

[dagnelies]

Hi, to be honest, I find it quite a pity to spin off a completely separate project rather than evolve ractive. I think it'll further fragment the already small community, resulting in less for both worlds.

Concerning your points, I'd have no objections on boiling down some aspects of ractive. As a heavy user of ractive, I attempt to never use ambiguous mappings. I think most other developers do the same. Just get rid of it (but add warnings and keep a compatibility flag for the in-between version) and it'd be fine.

Same goes for isolated: true. I've used it "almost" everywhere. Do the same, add warnings, deprecate it and all is good.

Improving/simplifying ractive seems a much better way to go IMHO rather than spinning off something else. ...everything is not about the framework, it's also about the ecosystem. Currently, both are lacking in that aspect. Don't take me wrong, great support is provided. However, the fragmentation and lack of compatibility from version to version definitely hurts.

[fskreuz]

Wooh! The Ractive camp is all here! I'll chime in then.

• I'd like to think of them as two totally different tools, two totally different approaches, whose only common aspect is the dead-simple syntax we all know and love (and happen to share with Vue).

• I'd also like to think of Svelte as promotional material for Ractive. Saying Svelte came from Ractive is a good way to say "Yeah, Svelte borrows ideas from Ractive, an awesome framework you never knew because you were busy compiling JS in your HTML." 🔥 😄

  (nothing personal, just for laughs)

• One thing I loved about Ractive was that it never boarded the hype train. You don't feel like you have to keep up. Changes happen slower (0.7 took a year to become 0.8) and aren't drastic (what do you think this is, Angular 2? 😉). So Svelte as a separate effort from Ractive is a good thing for Ractive users.

• And it's not like Ractive's going away when Svelte takes off. Everyone in this thread is regularly seen in Ractive, filing issues, evaluating PRs, giving great discussions, reminding people about open bugs - that's a good sign. 😄

My 2c.

[paulocoghi]

Despite @dagnelies' considerations, IMHO Svelte deserves a separated project because it clearly creates a new, important, and meritorious paradigm.

Although they have similarities, Ractive is incompatible with Svelte's paradigm and philosophy.

Also, everything good from Ractive is maintained, including its amazingly human syntax that no other framework has, which makes the transition effortless.

Finally, using Svelte is more than use an improved Ractive, since the former is naturally interchangeable with any other front-end or even node.js technology, a similar position that Rollup takes in the module bundlers world.

It doesn't divide, but helps make the community even more united, not only Ractive's community. And, for me, this is a gift.

--

@Rich-Harris , I'd like to apologize if I said some nonsense.