What I want is the flexibility to write declarative components with localized state but only introduce client side rendering when I want to introduce it.
I feel like the universal approach can be a bit heavy handed in that everything is getting rendered both on the server and the client. I would love to have something like Angular 1.* but with more structure and server side rendering.
I used it a few years ago and one of my favorite aspects was using primarily for generating templates server side, and only upgrading to a client component when things became more complex. Out-of-order async rendering was pretty nifty too.
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.
I had a look at Svelte in the early days but went with something more mature for the project at the time. I actually recently landed on Sapper while looking around tab Web Component projects and it looks good, though I haven’t had a chance to try it out yet.
edit: also, read a lot of comments about "why the military tagline". It's a play on the name Sapper. An old buddy of mine is one up in the CAF in Edmonton. They're combat engineers— hence the military tag.
New fancy TLD, the most generic name you can think off... so this is probably gonna get bought pretty fast!
For the “yet another new js framework” people out there, in some ways, it's true that Sapper isn't necessarily bringing anything new to the landscape (though I have been very pleased with some of the best-practices adopted-- so much is so-well thought out, and Rich Harris is just a freakin' genius at web systems engineering).
The combination of ingenuity with what Svelte does is completely novel, and in that sense, Sapper is really a different beast-- not just another framework. In that regard, one can't really talk fully about Sapper without also talking in depth about the novelty of Svelte, the "disappearing framework."
The "what" and "how" of Svelte (and Sapper) have been nicely covered elsewhere (article above, for example), so I won't really touch too much on it. But, as a non-n00b in the Internet landscape, I'll just throw out this hyperbole: there really hasn't ever been anything like Svelte and it's pre-compilation process before in front (and back) end technologies, and it's really just a full on joy to work with it.
If you want to get a quick taste, just go check what we Svelters like to say is one of the best kept secrets on the Internet, the Svelte REPL: https://svelte.technology/repl
- Handling auth w/ SSR
- Server side pre-rendering (in case I want to pre-render a template and conditionally cache/expire the HTML for N hours, for better perf instead of rendering on each request)
- SEO / Helmet type stuff
That's not everyone's cup of tea, but it is an area that doesn't have a lot of attention in modern JS libraries.
(The combination of choice paralysis and opportunity cost analysis are a powerful motivator, especially when one comes to the budding realization that even the mightiest frameworks are full of irks. More fun in being a total NIH control freak.)
But, each new iteration of an framework, library or distro will provide some new insight of what can be done better ... or what should not be done.
PSA: Don't make a new JS framework guys we don't need any more. /s