Why not Meteor in 2020?

Planet Earth
22

Regarding Firebase:

  • When I checked, they were using some tree-based storage which was not appealing to me (I think they’ve changed that).
  • It was not easy to customize the onboarding template and flow.
  • There was no way to customize the admin panel (add features etc), so it meant we had to build our own
  • But most importantly, I’ve used Google App Engine a decade ago and had many pain points when I wanted to migrate my data down the road, so I didn’t want to take that path again.

With that said, I do think Firebase has its market as a backend for mobile apps with simple CRUD logic.

With regards to the Auth, we use Meteor accounts. We did build our own auth using PassportJS at one point and it took around 5 weeks (one dev) including testing, I personally think it was not worth it, since the time could be have been spent to add features. The security checklist you shared is very informative, luckily we covered all of it except point 2.4 (secondary data verification).

Same here.

With regards to Time to Interactive (TTI), it is around 2s, this is after code splitting and optimizing the bundle, React apps can easily get bloated with JS code if one is not careful, I like bundlephobia, and use it before adding any React library, there is also bundleWizard and Meteor built-in bundle visualizer. We also use SSR (with data hydration) to get fast first paint. I think this the area where I would give NextJS credit, since they’ve SSR best practices built-in and they made it easier to achieve that performance with React, but again it is not compelling enough of value proposition for us, it takes some effort and knowledge to get this right with Meteor, I think it can be made easier but it is not too hard to do once the optimization is desired, I’d rather have Accounts done by the framework as oppose to SSR, since it is more sensitive and difficult area as you’ve alluded to.

However, if you’re really keen on the very fast TTI, I personally would go with Svelte. The good thing about Meteor that it has differential bundling out-of-the-box, I don’t think other frameworks has it yet, which means you’re shipping modern code to modern browsers, thus speeding up the execution time.

I’m curious about your experience with Parcel (I find it very attractive as well), how do you compare it to something like Meteor?

P.S I checked your website from the medium link, I think it is impressive, you seem to be a very thoughtful person and I share a lot of your views, so keep it up :+1:.

4 Likes
23

GraphQL is great. According to surveys about half of its client usage is with library-free http calls. Apollo helps with React integration and optimistic updates. However subscriptions are not as powerful as Meteor pub/sub. The Meteor community has delivered useTracker react hook which should be praised.

4 Likes
24

I posted about my experience with Parcel here. Back then you didn’t seem really attracted by the way :wink:

Summary: it’s really fast, just occasionally CPU gets really high or React components get messed up and you have to restart Parcel (which often still takes less time than a Meteor reload). It’s not perfect but it really made a difference. Not just the speed, but the hot reloading (keeping scroll position and component state) is a godsend for productivity, it really helps you stay in the flow. You have to experience it to understand what I mean.

2 Likes
25

Yeah I recall that conversation! thanks for sharing that link, but let us also hear it from @dandv since he seems to have first-hand experience with it.

I personally like Parcel as a build-tool, but we ended up with webpack for a project last year since it was more flexible. However, I do find parcel intriguing, and I unfortunately didn’t have the opportunity to use it in any major project, and I probably won’t now that Deno is here with its own bundler and Rust. Deno for sure will be my new go-to for side projects/experiments.

26

Sidenote: I personally find it a little strange how you keep discarding things people recommend (like Next.js and Parcel before), but at the same time are eager to jump on/recommend new, unproven tech you often haven’t even tried yourself (Svelte, Deno, …).

3 Likes
27

We do have hot reloading with large Meteor projects, we run webpack in parallel when doing front-end work, for medium React project, Meteor refresh is good enough. However, I’m willing to invest money to see HRM API first-class in Meteor as I mentioned here, I think it needs to be there and it is a limitation now especially with React Fast Refresh (the previous hot reload was not reliable most of the time).

I’ve not rejected Parcel, I just didn’t have the opportunity to try it in a major production project. I’ve used NextJS, and I just didn’t find its value proposition compelling enough (at least for me) and I’ve mentioned my reasoning above several times, feel free to respond to my question about NextJS value here, perhaps I’m missing something. With Svelte, the benchmarks are very clear. I try to do my own research, try the tools with side projects, and form my opinion while trying my best to filter the hype.

However, I do think Deno has a lot of potential down the road as I explained in that thread.

2 Likes
28

Really just a matter of setting a token with a cookie or localStorage.

I agree with you, few people want to own security.

29

Not recommendable by the way (XSS/CSRF).

30

No such thing as neither nor.

31

I wonder if this is neglectable if there is no attack surface for xss / csrf

32

I have no personal experience with this by the way. For me, app with accounts —> Meteor :smile:

2 Likes
33

Having played this from every possible angle at this point, the truth as I see it is that Meteor is the best developer experience, pound-for-pound in the industry. But, developers (whether we want to admit or not) are obsessed with the new-and-shiny.

Is there any technical reason to not use Meteor in 2020? No, unless you’re being fussy. Having built everything from tiny toy apps to big ol’ systems, you can do it with Meteor if you want to and know what you’re doing.

The only consistent reason people don’t want to use it is that it’s not the prom queen anymore.

14 Likes
34

I have asked number of developers on twitch about their thoughts on Meteor, their response has been mostly, “The core team left to work on Apollo” it’s like the project is abandoned, other thing is they criticize Mongodb a lot , “lack of relationships” will bite you down the line.

Their opinions of meteor is based on out of date information and lack of knowledge of how Mongodb works.

3 Likes
35

I’ve used Parcel to bundle an admin-style app built with with Webix (side note: Webix is another tool from the “amazing productivity” category; orders of magnitude faster to build admins interfaces with it than with anything else I’ve tried, and highly declarative no-BS code - search for anything in the top right at https://snippet.webix.com/, e.g. “side bar”); too bad they suck at marketing and open sourcing). Hot reloading was great, and that’s where the comparison between Parcel and Meteor stops, since Meteor offers so much more. I haven’t seen Meteor’s hot reload in years so I can’t make an informed comparison.

Gatsby’s hot reloading works the same way, preserving scroll position and component state. Very convenient indeed.

For me it would be “official” PWA support, though according to the last blog post, that’s coming.

Exactly. Sadly, lots of uninformed opinions and popularity bias (though not entirely unwarranted, given the risk of libraries falling out of maintenance) in the JS ecosystem.

2 Likes
36

We have one production system (built in 2016/2017) that’s full Meteor and Blaze, including mongodb, pub/sub, accounts, and everything. And it works great, getting to ~100k users / month and still doing fine with a single EC2 node as an app server.

For our latest project however, I’m just using Meteor as a build tool, and use React with a REST API provided by feathersJS connected to a postgresql backend. It’s a great build tool, but leaving the comfy confines of the Meteor environment reminds me just how many problems Meteor solved years ago that the JS community is still grappling with today.

It’s 2020 and I’m still dealing with rolling my own accounts system. And reading tons of blog posts and articles about how to manage data access with a redux store and a REST API leaves me wishing for the simple pub/sub mechanism of Meteor that automatically provides local caching, expiration, record merging, sync, and optimized network transfers without a single line of extra code.

I have a serious case of javascript fatigue, and it’s annoying to see all these shiny new toys that everyone keeps talking about while basic functionality like accounts systems and data management are considered too unsexy for frameworks to focus on. Leaving complex data management optimization, or account security best practices, as an “exercise for the user” while touting a few tenths of a second reduction in time-to-paint benchmarks seems ass-backward to me.

So why am I not using Meteor fully? For me, it comes down to the ability to build a team. In 2016 / 2017, it was fairly easy to find JS developers who were experienced with Meteor. Now, it’s extremely difficult. Even previous developers that we worked with, when we get back in touch with them about working on new stuff, tell us they haven’t touched Meteor projects in years and have moved on to other frameworks. I’m scared to start a new project with Meteor and then be unable to find developers. Meteor is different enough (especially with the way pub/sub and reactivity works) that it takes developers, even ones comfortable with JS, at least a few months to really grok how pub/sub is different than REST APIs. While I’m willing to train new developers, I can’t be sure they’ll actually become good Meteor developers and unlearn the principles of the other frameworks they know.

That’s my biggest reason for “why not meteor in 2020” :slight_smile:

But to that, I’d add maybe a controversial idea: 90% of websites these days don’t need Meteor or even much of javascript. Before Meteor, I used Ruby on Rails to create static sites. And again, it’s amusing when people write React/node.js SPAs that are actually pretty basic static websites. Even many “advanced” websites are often primarily a static website with a few interactive bits that can be easily managed in a couple of limited scripts and AJAX calls.

In fact, for my current site, I wrote my prototype in Rails, because it’s an even better ecosystem, with well maintained gems for just about every problem you have, and only recently rewrote it in React when we better understood the features our early users needed, and decided that interactive and dynamic features were truly necessary and made an SPA worth the hassle.

So perhaps Meteor is stuck in an anti-sweet spot: those who chase shiny new features without regard to utility seem to hop to the latest greatest thing. And those who want a well-engineered full stack solution with a robust ecosystem choose Rails / Django / Java / etc and other older technologies for the 90% of projects that are little more than CRUD frontends to a big database. Meteor is stuck in the middle: not shiny and new enough (any more) to attract early adopters and momentum chasers; not old and established enough (yet) to attract the stable and boring developers.

The good news is that, IMHO, every framework goes through this transition. I think as long as the meteor ecosystem continues to grow, focusing on solving real problems that people have, then it’ll soon cross that valley and be seen as a stable, solid choice by the vast majority of developers that prefer to live a little further away from the bleeding edge.

11 Likes
37

Rebuild it from scratch in TypeScript on top of Deno, rebrand it “Spaceball” or something, and problem solved! :slight_smile:

3 Likes
38

@dandv I agree, although I’d prefer PlutoJS over Spaceball ;), it would be great for the Meteor community to experiment with Deno and attract the early adopters because it is a technology worth investing in, not just another hyped JS framework, and I think the Meteor community has a lot to offer on that front, as I explained here.

However, I’d suggest to ignore the momentum/hype chasers, they will spend their entire career chasing with nothing to show, and they are not worth the effort.

@mraju thanks for sharing your thoughts, great read.

3 Likes
39

Love your post @mraju, hope Tiny is reading this as well (@matthollingsworth), as this seems to be mainly a marketing problem. I agree anno 2020 there is still a space for Meteor (provided it continues to evolve), we just need to lose this image:

I’ve listed some other misconceptions I often encounter in the field here: Introduction, and favour to ask the community! - #19 by rijk

This. Even without accounts, when I’m working in projects that don’t have a Meteor backend and I have to do API requests back and forth to fetch and update data, managing that data in component state manually, feels like going back in time for me. “Ass-backward” is the perfect word :+1:

While I agree that Meteor doesn’t need to change, it works fine, we also should acknowledge that the bar in the industry keeps getting raised. Proper, Parcel/Next speed HMR is more than a ‘shiny new feature’, in my opinion this is now table stakes and Meteor needs to keep up.

That said, implementing this would not only get Meteor back to the bleeding edge of dev experience on all fronts, but could also help shake this “Meteor is no longer maintained” image. So it might even be double bang for your buck :slight_smile:

6 Likes
40

This Webix thing looks very interesting, I didn’t know about it. It even has an open source built-in Meteor real-time pub/sub integration! thanks for the reference.

2 Likes
41

I think the new shiny syndrome reason is kind of wishful thinking for those of us that love a not doing well in adoption stack. I see elixir users saying the same thing. In reality its always more than that (which you alluded to as well). So far for my shop to be convinced to use meteor its answering three issues satisfactorily ( and that means not as a meteor enthusiast but objectively comparing to what else is out there)

Why should we invest in a framework that only has one core database we don’t generally like in Mongo? (and there are TON loads of developers who feel that way)

Why should we use a framework that has an issue out of the box scaling? an unofficial solution package, to a non enthusiast of meteor, is not compelling. Scaling should be built in or have official supported solutions)

whats the unique selling point of Meteor that we NEED and can’t get from a framework that has more community resources and assistance? You alluded to Django and rails etc. Last night I installed the latest version of Meteor on my home windows desktop which seem to go fine until I attempted to create an app and ran into this error

problem is thats all I could find. First time in years I have had a problem with a well known javascript framework and couldn’t even find at least a hint to the solution. Training , people and third party support has moved away from Meteor. If you are not already invested mentally in Meteor that scares the life out of developers who couldn’t care less about shiny things. So the answers have to be VERY compelling to overcome that sense of a dying framework

4 Likes