Same here. I’m new to both Meteor and Svelte but love the combination and it’d be great to see more learning resources and posts like this from @jam. Add in TypeScript for both Meteor and Svelte and we have the perfect trifecta IMHO!
3 Likes
I am so glad you followed through and posted your experience! As you know we also did something super similar! We actually had 3 apps running on Blaze, and while we also love Blaze…we knew it was time. We dove right in and converted our biggest app over, and WOW…its just better. Like…leaps and bounds better! Code stays more organized, and you find yourself following the bouncing ball of state far less! More time coding = more productivity. 
We never did have the issue with needing to stop our subscriptions. Not sure how/what we may be doing differently, but as far as we can tell our subs stop when leaving a route as they should.
Now when we go back in and start working on our other 2 Blaze projects…it just feels so chaotic and slow. At this point, I am telling every Meteor Dev I know about Svelte. As with any framework (or compiler if you want to be specific), nothing will ever be perfect…but this is pretty darn close!
Lastly, none of this is possible without a great community. I can say wholeheartedly that Meteor has THE BEST developer community around. I have been at this for over 20 years, and until Meteor + Svelte I have never had a big urge to get involved in forums. Take it for what you will…but you guys have been fantastic!
8 Likes
@jam thanks for sharing bud. I have been looking into meteor svelte for the longest time. We have interacted before regarding svelte mobile symbolic link thingy… I am glad you found a solution for. I have few questions:
1- this is more about svelte than meteor I guess but besides the global scss, are you using sass inside your components and was it easy to setup?
2- do you the project deployed? Can you provide a lighthouse report?
@jhochgreve one of the biggest things that are stopping me from commiting to meteor svelte is actually this. I do not know how well it’ll perform due to not being reassured by enough community activity. Can you provide more insight on that and performance? I have never deployed a meteor app before and if I am ever going to do that… It’d be with svelte. Idk why the community have not steered into that direction yet. Svelte imo seems like the most compatible/natural option with meteor. Anyhow, to be more concise. Tldr, I’d like to ask about:
1- How did you deploy meteor? Perhaps galaxy or directly through aws?
2- Do you have a before and after benchmarks (or rough estimate/prespective) to how the app was performing after switching to svelte.
1 Like
Good questions!
To be honest, no we have not run any benchmarks; however, I can honestly say that the performance gains were so significant honestly I hardly feel the need to go that far…the moment we began working on it we all immediately noticed the difference. We are still in development right now, but I think we may run some benchmarks once we are done.
Regarding deployment, we currently use NodeChef: https://www.nodechef.com/
We have had pretty great success using their services. As with any host…your mileage may vary, but we have enjoyed the elastic nature of their Docker-based containers. Deployment is as simple as running a meteor build command they have all of the documentation here: https://www.nodechef.com/docs/node We do not use their CLI (though I hear its good) but rather just upload directly via their online GUI.
I should mention that I do hear pretty great things about the Galaxy services also! We originally chose NodeChef only because they offer MongoDB hosting.
Keep in mind when it comes to Svelte, and the Meteor community as a whole…Svelte is pretty darn new to Meteor. In my opinion, it is production-ready but if you have concerns…keep in mind that Blaze is still great and has been utilized in countless production environments. Our decision to swap to Svelte over Blaze was certainly partly based on performance gains, but more so that that was based on 2 things:
1. Cleaner more concise and less opinionated Javascript Code: Sure…just like with any compiler/framework Svelte has a certain way of doing things, but it allows you a pretty great amount of freedom and handles state pretty easily.
2. Easier to scaffold and organize code: Simply put, there are WAY fewer files to deal with, and more potential for reusable component based architecture (not that you couldn’t do this with Blaze…but it was much more of a hassle). This helps to keep your apps more organized and thus much more scalable…along with making it far easier to have more developers working on the project at the same time.
Sorry for the super long reply! The reality is that in the end…much of this could be subjective; however, there is more than enough compelling evidence to suggest that it is probably worth your time to give Meteor/Svelte a shot!
2 Likes
No, I’m using plain CSS in my components. Once I started down this path, I realized that I didn’t really need sass in my components. I switched from using sass variables to CSS variables.
Yep. I deployed with waveshosting.com. It sits on top of AWS and scales with beanstalk (if needed). It was really easy to get going with it and recommend checking it out.
Tbh, I should spend some time optimizing for lighthouse. Let me do that and run a report.
1 Like
that fixed it thx, much easier than react native
fwiw, I was able to remove this symbolic link and am now using the nodeModules recompile option in package.json like so:
"nodeModules": {
"recompile": {
"svelte": ["legacy"]
}
}
Also, I switched from using svelte:compiler and rdb:svelte-meteor-data to zodern:melte. I can’t say for sure that the switch was the fix or if I simply had the wrong syntax originally to recompile svelte.
Was this really necessary? I am asking because I am an SCSS addict. Having to switch to pure CSS would be deal-breaker for me.
1 Like
It was necessary however since then a community member has forked zodern:melte to enable SCSS GitHub - r00t3g/melte: Svelte compiler for Meteor with built in tracker integration and HMR.
I’ve actually since gone a step further and removed SCSS all together. In a component based world, it isn’t as useful IMO (though the functions were handy) and removing it allowed me to drop another dependency.
Did you do a comparison of bundle size before and after the conversion?
It’s not exactly apples to apples because I’ve since removed a couple packages but here are the results:
**Blaze**
3.97MB Minified (2.33MB node_modules)
1.11MB Gzipped
**Svelte**
2.67MB Minified (1.82MB node_modules)
790kB Gzipped
Interesting, thanks.
I was expecting the Svelte bundle to be larger because it compiles most of the DOM maintenance logic into each component as vanillaJS, so it has a smaller runtime library but larger component code - compared to non-compiled frameworks (vue, React, Blaze, etc) which have smaller component code at the expense of a bigger runtime.
Thanks very much for the pointer about creating a symlink. How on earth did you figure out that was what’s needed? All I was seeing was an obscure message “Class constructor SvelteComponentDev cannot be invoked without ‘new’” that led me nowhere helpful when Googling.
Ha I wish I could remember. Lots of searching and reading. The good news is I found I no longer needed it with zodern:melte. See my comment here: Converted a project to Svelte. AMA - #10 by jam
Thanks very much! I’ll give that a try.
what do you recommend for server side rendering I mean not static data but data that comes from database and passed into a template.
I need this for my next project, its only one page that I want to server render it
I haven’t tried server side rendering but the zodern:melte package does support it. See GitHub - zodern/melte: Svelte compiler for Meteor with built in tracker integration and HMR
If you give it a go, would be curious to hear how it went for you.
don’t mean to necrobump, but did you or anyone in the thread ever run svelte components side by side with blaze?
I think I was able to do it with accounts-ui initially as a POC but I ended up dropping that and writing simple Svelte components for authentication.
What’s your use case?
The problem with running them side by side is Blaze has a jquery dependency which can be kinda heavy.
Yes, I do, on two projects; I am trying to phase out Blaze. Works well. Svelte simplifies a lot of code, and I am happy I can do it progressively and not all at once (that would be months of work)
2 Likes