I agree that JSX is ‘pure’ and allows you to write your templates in the language you know best.
Yes, Vue requires you to learn a small amount of template language (literally it amounts to v-for, v-if/else-if/else, v-bind, v-model (awesome!) and @event). That’s pretty much it. IMO there’s way less to learn and remember with Vue compared to React.
But you asserted that React gives you more ‘control’ and that Vue requires ‘hacks’. I think this is a big misconception about Vue, that it’s somehow less powerful than React - so can you explain something you can do in React that you can’t do just as easily in Vue, or demonstrate some Vue ‘hacks’? Again, not trying to start a war, I’m just trying to understand what I might be missing with React?
Svelte does look awesome and I can’t wait to use it in anger! I think I’ll wait for v3 to mature a bit though and it would be great if there was a material UI library for it because I would hate to reinvent the wheel.
Still very happy using Blaze in all our Meteor projects and have not encountered this vague and mysterious ‘slowness’ that gets brought up every now and then.
Blaze has in my experience been fast - often faster than React. My issue with it are 2 fold. 1) it doesn’t scale with complexity by default (though maybe Blaze Components help, I never used it) - it’s just harder to keep track of execution flow with Blaze compared with React. 2) The ecosystem for Blaze is in shambles. I have an old app built on Blaze, and it can be a challenge to get everything updated (I had to fork a package just to update jQuery to a secure version for example). That may have more to do with the specific packages I’m using, but that’s been my experience.
I also use Blaze in 2019 and I like it because it is stable and well embedded in the Meteor ecosystem. Performance depends on how important this is to you. I, for example, always use the templateIntsance.$ builin jQuery that scopes on the current template root instead of document root, making all jQuery lookups working fine and I have never excperienced lagging etc.
I also successfully managed to integrate any external UI component via NPM from BPMN Modeler to Plotly, noUISlider etc. and they basically follow the same pattern.
One thing however, that concerns me since a while is the size of the packages in the Blaze ecosystem that easily can reach >1MB. Especially autoform, simpleschema and jquery are quite a thing already and I would like to keep my bundle size as small as possible as there are still some 2g users in my target group.
I used to be a proponent of Blaze – after moving to React I can’t say that I miss it. React’s ecosystem is amazing. We use Semantic UI React, a truly well-done project used by big players (we were using the regular Semantic UI before, which uses jQuery).
Imagine no more jQuery or defers (we needed quite a few defers to wait for DOM to render). Without hesitation, go for React and you’ll never look back.
Don’t mean to start a hate thread – but Vue (which I used to love) looks more like Blaze 2.0 (same developer). My opinion of course …
We are slowly replacing our Blaze components with Svelte. Almost 100% of new code is Svelte, unless we can heavily utilize lots of existing complex Blaze components. They work nicely together, especially since Svelte components are self-contained and don’t require a massive runtime to function. Svelte’s stores work well together with DDP & Tracker with a few tiny helpers functions.
That being said, I’d not recommend it, if you want a battle tested workhorse with a useful ecosystem available and lots of resources to guide you. It’s not there yet. There are some unsolved, or at least undocumented problems related to tooling for example.
But if you want a slick, fast and very developer friendly framework that has some of the same jaw dropping wow-factor as Meteor and Blaze had 7 years ago, and is an absolute joy to use, then Svelte is your weapon of choice
I highly recommend going through the tutorial - it’s very well made and gives you a really decent overview in less than 45 minutes.
After using Svelte to build real, complex components and even entire apps, I’m surprised (after being sceptic at first) how well thought out it is and how natural the magical reactivity bits feel after a while.
Meteor/Apollo-server in one repo and create-react-app (with apollo-client) as the frontend in another repo.
imo the react ecosystem is too good to miss out on and using meteor/apollo-server is basically a node app (especially if you try to keep meteor packages to a bare minimum and use npm). That way you get all the goodness of meteor (mostly, the accounts) without being 100% stuck in meteor world.
I went through the Svelte tutorial, and set up a Meteor project, and I’m quite enamored. What are the weak points in your experience? I’m already thinking of trying to duplicate essentially my entire Meteor React Starter (SSR, code splitting, etc.) in Svelte, and see how hard it is.
I also thought of making a small useTracker like implementation, or even trying to dig in to the Svelte compiler and see if there is a way to create an additional binding API which would either set up a computation per bound variable, or one computation per component. I’m thinking m$: as the prefix for code bindings (I still have to learn how this all works better though).
I’ll try to answer to this in more detail when I find some!
Here’s my useTracker
import { Tracker } from 'meteor/tracker';
import { onDestroy } from 'svelte';
/**
* Svelte specific helper function for using Tracker inside
* Svelte components.
*
* @param { Function } fn - Function to run reactively
*/
export function useTracker (fn) {
const computation = Tracker.autorun(() => fn());
onDestroy(() => computation.stop());
}
Yeah, I think that’s all that’s needed. I’d probably take a page out of the react version and run that inside Nonreactive:
import { Tracker } from 'meteor/tracker';
import { onDestroy } from 'svelte';
/**
* Svelte specific helper function for using Tracker inside
* Svelte components.
*
* @param { Function } fn - Function to run reactively
*/
export function useTracker (fn) {
// Use Tracker.nonreactive in case we are inside a Tracker Computation.
// This can happen if someone calls `ReactDOM.render` inside a Computation. (Is there a similar possibility in Svelte?)
// In that case, we want to opt out of the normal behavior of nested
// Computations, where if the outer one is invalidated or stopped,
// it stops the inner one.
const computation = Tracker.nonreactive(() => Tracker.autorun(fn));
onDestroy(() => computation.stop());
}
I deployed my meteor website on Google cloud and it works perfectly.
All media files I store on Google cloud storage
I have meteor instances run on multiple Google compute engine behide a Google load balancer.
Currently I have a server dedicated for mongodb. But I’m thinking moving to mongo atlas which also available on Google cloud.
@arggh, how do you feel about the need to use workarounds to transform arrays? I finally started Svelte tutorial after reading the topic, and — though I understand where it comes from — this feature seemed a quite important weak side to me.
Do you mean the requirement to make an assignment in order to trigger a reactive update to the DOM, hence not getting a reactive update with myArray.pop()?
It really hasn’t yet bothered me. Most of the time I’m trying to avoid mutating the same array anyway.
The only thing that caught me off-guard was this:
const o = {};
o.foo = 'bar'; // triggers reactive update
delete o.foo; // does not trigger reactive update
Yes, that’s what I ment. Thank you for sharing your experience. I was going to take a closer look to Svetle back in December, after your post in the similar topic, now it happened. The framework definitely looks very promising.
I agree, blaze is simple compared to react imo, but every-time I try to use and add atmosphere packages I run in to problems and no solutions wrt compatibility issues. So as good as blaze is I have concluded react is best and can be used in many other frameworks and environment including mobile with react native.
– but Vue (which I used to love) looks more like Blaze 2.0 (same developer). My opinion of course …
