Converted a project to Svelte. AMA

Some quick context: I recently converted a project from Blaze to Svelte. I love Blaze. It’s amazing how quickly it is to get things going with it, but as I started going deeper down the rabbit hole, I knew I needed to find an alternative. I couldn’t get past React’s syntax and excessive boilerplate. Vue looked promising but still had a few things I wasn’t crazy about. Then I found Svelte. It was like they took all the great things about Blaze, component-based development, and compilers and smashed them together. Once things started to settle out a bit with the integration between Svelte and Meteor, I dove in.

Key Packages

  • svelte:compiler
  • rdb:svelte-meteor-data

Router

Hurdles

  • Router: For some reason it needs to be imported like this:

    import { Route } from 'tinro/cmp/index.js';
    

    See: https://github.com/AlexxNB/tinro/issues/14

  • Cordova: I had to create a symbolic link to get Cordova working. To create the symbolic link:

    // navigate to your app's root directory, then go to imports, and then create the symbolic link there
    $ cd imports
    $ ln -s ../node_modules/svelte/
    

Note: I’m not sure why this is necessary. If someone can shed some light, I’d appreciate it. Also, using nodeModules recompile option in package.json did not work for me. I had to create a symbolic link.

  • Email templates

    • I’m using svelte-mail to render custom html email templates.
  • Easy Search

    • Easy Search is great. I had been using easy search’s pre-built Blaze templates. I ended up creating my own Svelte component.
  • SCSS

    • I had been using SCSS for all my CSS. I decided to keep a small SCSS global file that has some functions and use plain CSS in my Svelte components.

Auth

  • Since there wasn’t a set of already baked authorization templates and I didn’t want to inject blaze templates, I created a super simple skeleton for Auth.

Other tips

  • One thing to be aware of with svelte-meteor-data: If you create a Meteor subscription with a dynamic prop, you’ll need to stop the subscription. See: https://github.com/rdb/svelte-meteor-data/issues/5
  • For some reason, when I had pure Svelte stores and stores that relied on svelte-meteor-data in the same .js file, I was running into errors. So I separated them into two files. YMMV.

This forum has been super helpful for me. I hope this post helps others. I’d love to see Svelte gain broader adoption with the Meteor community. I think they are a perfect pair. I’d be happy to answer any questions. :slight_smile:

16 Likes

Thanks for this detailed project report and links given. This is super helpful for others that are considering to replace Blaze (like us) and who aren’t super where to switch to (thought VueJS was the best choice but since I’m reading more and more how close Svelte is to Blaze I have second guesses about VueJS).

It would be great if more people would report their experience in the way you have done. Once again, thank you!

2 Likes
  • 1 for this.

I really wanted to see a svelte project. Was thinking about going to VueJs also, but the more I read about this combo, more I want to go Svelte.

3 Likes

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. :slight_smile:

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! :slight_smile:

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. :slight_smile: 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! :slight_smile:

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.