3 ms·
One of the advantages of the Svelte approach is that you can theoretically make those determinations at compile time - if there's no interactivity on a page, do
by rich_harris 8y ago
One of the advantages of the Svelte approach is that you can theoretically make those determinations at compile time - if there's no interactivity on a page, don't serve any JavaScript. We're not quite there yet but it's very much on our radar. You should be able to use a consistent programming model whether you're building an app that makes most sense as a purely server-rendered app, an SPA, or something in between - especially since your requirements can change unexpectedly - and if the framework is designed correctly, it shouldn't even require configuration.
- rajangdavis 8y agoI was definitely looking at Svelte, Vue, and React for this. I played around with Nuxt and couldn't get it to work in a way where I could avoid rendering on the client. It's not a bad framework, but it doesn't work for the purposes that I am looking for. What I am doing today is using Ruby and Sinatra for the back end. I have figured out a way to build out a light weight component system where this is an html view, some vanilla js for interactivity, and CSS for styling. The problem is that it is really difficult to localize the scope of the js and I have to work with the DOM to add interactivity. Scoping the CSS isn't necessary but would be nice. I don't dislike doing things in Ruby, but I am very much attracted to the idea that I can use one language for the server and client logic and avoid having to tap into the DOM for managing state.