A bit better: https://trends.google.com/trends/explore?cat=31&q=Vue,React,Angular
– 25 vs 100 for React
I imagine The State of Javascript and npm weekly downloads (6,117,132 for React, 1,157,084 for Vue and 465,898 for Angular) would give a better snapshot of how view layers are comparing in popularity.
2 Likes
I think the problem with SSR is that the specific tools you are using require a different set of configuration. For example, in one project, I use: React, React Router, npdev:collections, Material-UI (JSS), react-helmet-async, staringatlights:fast-render, and npdev:react-loadable. In another I use Svelte, svelte-loadable/npdev:svelt-loadable, staringatlights:fast-render, and might use Apollo (currently using straight Meteor pub/sub). These two projects will require a completely different set of tools to be configured in SSR on both the server and client.
I’ve also read that SSR memory leaks in React aren’t exclusive to Meteor, and are just generally hard to manage. In my main React project, I can’t seem to get it to stop leaking memory, though I have significantly reduced (slowed) the leak (this indicates multiple leaks). I currently suspect either Material UI, or uniforms as the culprit - neither satisfies React’s Strict mode, which means either could be creating “side effects” on mount, and causing the leak. (Or possibly some core incompatibility between hooks and/or the mongo driver and Meteor’s Fibers.) I’m not sure yet.
Opinionated Starters (like mine for react and svelte) are probably the way to make this easier.
3 Likes
I find SSR is a little over-rated, in general.
It’s a micro optimization, but gets pushed around like it’s required. You can have a wonderful non-ssr experience with a service worker.
4 Likes
Another feature I’m really interested in is a code sandbox for Meteor.
When MeteorPad went down, a lot of knowledge and examples were lost. It was frustrating to find a blog post I’d read before with the solution to my problem but not be able to access the example.
I participate in other communities (namely Vue), where it is easier to give and get answers to common problems because of the insistence on a small reproduction in Codepen or Codesandbox.io. I happily pay for Codesandbox because of the templates that are readily available, linting, and ease of isolating problems quickly. I’d be thrilled if there were template for Meteor. I’m not sure how Atmosphere packages could be required and DDP could be emulated or if it’s even possible without spinning up an instance of an application.
I’d be open to paying for one from MDG, provided I knew that they would continue support for it in the future.
7 Likes
Interesting take, thanks! Any tips for tutorials on this?
Google has the best documentation I’ve seen: https://developers.google.com/web/fundamentals/primers/service-workers
1 Like
import React from 'react';
import { render } from 'react-dom';
import Whatever from './Whatever'
render(<Whatever />, document.getElementById('whatever-target'));
This is more first-class than create-react-app, which magically sets up an html div with id="root".
2 Likes
+10 for the rational and informed business-minded perspective.
(No personal opinion on React vs. the others.)
Back-of-envelope, a full-time dev pays for him/herself if you get an incremental 50-100 well-heeled Galaxy customers. So maybe Tiny can just officially support all the major front ends.
As for strategy, isn’t Galaxy the only revenue-generating thing at the moment? A few mil/year was the guesstimate, in another thread.
+=10 for your point re shabbiness… it’s so embarrassing. Same for the official docs – For a while, the docs actually had a bug (you couldn’t reliably navigate old versions), which was kind of impressive. But even now, they are lacking. I am optimistic that we’ll see a new-management makeover.
3 Likes
Maybe Tiny is waiting for the end of these posts to take stock 
2 Likes
These posts will end when this thread is forcibly closed LOL.
Tiny - do you have enough to chew on now?
6 Likes
Oh and provide deployment guide and/or tool chain setup for hosting meteor apps and on your own vps or local setup.
3 Likes
Meteor collections (not just Users collection) use a string instead of an ObjectID type. Effectively collections made with Meteor have an _id field that is incompatible with a Mongo _id field.
You can specify the idGeneration: “MONGO” option when creating the collection to make an objectid.
The problem is you can’t do that with the user collection.
1 Like
Speaking of which - I’d love for meteor to support custom _id schemas on a per collection basis (not generation, just allowing insertion/equality). I’ve got collections with 90+million records, and an _id field that is never used because I have a unique composite key elsewhere.
The _id index takes up several GB space, and resources to keep updated
1 Like
To be honest I don’t really get why so many people are so eager to go the React/Vue route with Meteor, split the monolith stack, use GraphQL etc.
The whole point of meteor at its inception and the reason it got so popular was that it is really, really quick and easy to learn and knock ideas together with. As soon as you start bringing all those big complex frameworks and design patterns into the mix it starts losing most of its benefits and advantages.
In fact, I’d go so far as to say that if you’ve already gone to the trouble to build our your app in Vue or React, you may as well use one of the myriad of other decent nodejs backend frameworks that provide auth, API scaffolding etc. and keep things nice and flexible so you can easily swap out front ends or scale out etc. Very few apps actually need everything reactive all over the place and it creates all sorts of scalability and performance problems to deal with as we know.
Meteor is all about speed. Not speed as in app performance (having everything constantly synced over the wire is never going to be the best approach for app performance), but speed as in getting things done and getting ideas online.
Personally I’d like to see Meteor go back to its roots, stick to Blaze and Minimongo and let Meteor handle all the hard work behind the scenes so people can just get stuff done. The dev focus then should be on optimizing to reduce the syncing and server load to the bare minimum each app actually needs and making things scale better. Maybe better tooling (visual tools? IDE plugins?) for creating apps, backing up data, creating failovers etc. so its easy to run and maintain in production.
4 Likes
Given that I know react, and don’t know blaze, it’s significantly faster for me to build a view layer with react than it is for blaze.
2 Likes
That’s just not true for everyone. I have been working in the latest years with Meteor, react and now grapher and is a much better DX than working with blaze + minimongo. And not using blaze and minimongo doesn’t mean I can’t benefit a lot by Meteor accounts, build system, atmosphere packages, npm packages, no config, easy RN integration… I also use webpack with serverless and Meteor is far easier to deal with, so it is not just “use meteor with blaze or go the webpack, parcel or -insert new bundler- way”.
Also, you can still do things the blaze minimongo (old) way without any problems, but probably that backwards compatibility is holding back some new features or improvements.
So, this is relative to the developer, for you is easier and better blaze minimongo for others is better and easier react, grapher, etc. Probably there will be a place for both and even more.
7 Likes
The reason why, from my perspective, is that asking developers to now learn Blaze after already knowing Vue or React isn’t going to fly. Blaze doesn’t offer much in terms of a unique value proposition compared to existing frameworks with much larger communities. I don’t think Blaze is a faster developer experience than Vue or React and certainly won’t be faster for someone who’s never used Blaze.
Besides if we wanted to go with something like Blaze, then Vue is basically a more modern version of it in my eyes. IMO the only reason to stick with Blaze as the main UI layer would be to placate the people already using it.
18 Likes