sveltejs / svelte

Cybernetically enhanced web apps
https://svelte.dev
MIT License
78.69k stars 4.12k forks source link

Question: Philosophy #22

Closed tomekmarchi closed 7 years ago

tomekmarchi commented 7 years ago

What would be svelte's differences over Vue & Ractive? I'm excited would love to know if there are any plans for supporting dynamic components?

An example would be a global component that loads in dynamically and then appears in other components that have it in their template syntax.

Component layout {{sidebar}}

Moments later sidebar.js loads on the page and sets itself as the global sidebar component. Which it then appears in the layout.

This is how my current projects/apps work with some sugar on-top of Ractive; to get it to play nicely. The idea is that the app builds itself over time based on what it needs when it needs it. The new .reset methods in (Ractive) are a huge plus for getting all of that to work especially the hot-reloading I have made. Would love to see that same functionality or even a step in the dynamic direction.

Rich-Harris commented 7 years ago

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 commented 7 years ago

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.

paulocoghi commented 7 years ago

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.

fskreuz commented 7 years ago

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

My 2c.