Comment by ravenstine
5 years ago
Awesome news! Having worked with frontend frameworks for years, I've grown pessimistic about them in general, but I'm enthusiastic about Svelte because it does so many things right that actually avoid a lot of the issues other frameworks claim to solve but actually make worse.
Interacting with the Svelte compiler is ridiculously easy. Though the documentation can be improved, I found it trivial to import the Svelte compiler and prerender a component into an HTML string. Yes, this is somewhat of a niche thing to do, but I appreciate it when libraries and frameworks make it easy to access its internals. Heck, I pretty easily managed to implement Typescript support for Svelte components using Deno's `emit` function; hooking into Svelte's preprocessing was trivial, the complexity I ran into being on the Deno side.
Contrast that with Ember, which seems to have an attitude of "no one would or should ever want to do that", making it really hard to do anything slightly off the beaten path without lots of trial and error or entering the Ember inner-circle.
Yes, I know I'm comparing a component library to a framework, but what I'm commenting on is more about development philosophy.
It's good to hear the creator of Svelte will be able to dedicate his time to it and be able to provide project guidance. I think he has the right vision for what Svelte should be.
Ember was the first framework I used and also the most frustrating. At least with Vue and React I can poke at the internals and they make sense, but Ember's internals had so many oddities that thoroughly confused me.
What I like about Ember is that it gives a lot of rigid structure that, at least at one point, made it comparatively easy to work on multiple Ember based projects and be productive sooner.
As you've pointed out, a problem with that project is that there's a ton of intimate knowledge for how things work under the hood or why things are the way they are. They also seem to oscillate between opting for simplicity and opting for complexity and magic.
One example would be the latest version of Ember which doesn't even ship with `@ember/render-modifiers` by default despite how everyone will end up installing it out of necessity anyway.
Why might that be, you may ask?
> [...] we recommend using these modifiers with caution. They are very useful for quickly bridging the gap between classic components and Glimmer components, but they are still generally an anti-pattern.
https://github.com/emberjs/ember-render-modifiers
Why on earth did they reinvent components and ship them without providing the supposedly correct way of interacting with their lifecycle? You actually have to install a separate add-on to develop a production-ready app with Ember, which completely flies in the face of the idea that you can run `ember new` and have pretty much everything you need. Go ahead and try interacting with individual elements of a Glimmer component in a vanilla Ember project and see how productive and ambitious your web app will be.
Strangely (and thankfully), the RFC for what I think is a needlessly complicated alternative for lifecycle interaction is effectively stalled:
https://github.com/emberjs/rfcs/pull/567
By their own verbiage, the only official way to interact with component/element lifecycle is an antipattern.
So far Svelte and SvelteKit are avoiding all that extra crap. The day that Svelte calls its own solutions "antipatterns" and spends years pontificating things like the actor pattern will be a sad one.
/rant
This is so HN, in an Svelte thread memories from Ember (sharing your sentiments though).
HAHAHA
I try not to go full HN, but sometimes you do.
And I shouldn't have made it about that. As I get older I the more I just get tired of extra things. There's always a price when you add more things. Svelte technically does add things, but I think it has better bang for its buck. The fact it doesn't pointlessly impose OOP constructs upon the end-developer is a big win for me.
1 reply →
Why is this 'awesome news' for us devs, the market and competition if one vendor now controls all modern SSR frameworks plus significant parts of the tool chain (swc)?
Does Vercel actually “control” Svelte, though? The existing governance structure is untouched, they’re just paying the salary of the lead (and definitely not only) developer.
Not sure if this topic is worth our time to debate. There are millions of ways of subtly controlling/influencing entities. And it's much easier if you pay money, ESOP and pay even more money if future goals and exits come alive.
9 replies →
I'm definitely curious about it. I'm one of those "swore off frontend framework" people who's attracted to tools like Phoenix Liveview so I never have to deal with it.
Svelte does look pretty sharp and simple though. I wonder how well it works with something like LiveView? Does it really depend on the styling structure mentioned or can I use it with Tailwind?
It works great with Tailwind, I’m doing that in a project right now. I haven’t tried pairing Svelte with LiveView and I’d worry they would end up fighting over elements of the page, but I’d think you could have them control separate parts of the same page, or have them controlling distinct pages just fine.
What could be improved in the documentation?