Rebuild it from scratch in TypeScript on top of Deno, rebrand it “Spaceball” or something, and problem solved! 
3 Likes
@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
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 
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
6 Likes
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
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
Node Back end - NestJS
Front end - VueJS and (recently) Sveltejs
1 Like
NestJS seems good, I like it. Relatively new (2017+) it looks like a thin wrapper around the already existing NodeJS pieces (express, passport etc.), little better than just using webpack with express (at least there are some standards), looks similar to FeatherJS in terms of value proposition and I find it interesting that they’re using Gulp as the build system. From the first impression, it seems a viable choice, decoupling the client from the server.
Can you do SSR with NestJS? Edit - It seems SSR is feasible since it is on top of express.
I think it could be a good alternative to Meteor backend, it doesn’t seem to cover as much as Meteor, it doesn’t have Meteor packaging system (and all the third party community packages), it’s not full-stack, and no real-time/DDP solution, no SSR out-of-box, no accounts, no hosting, and differential bundling, no default database (convention over configuration), no community forum.
Are you planning to build multiple apps (contracting development shop)? I mean most folks wouldn’t want to support multiple databases. NestJS would still have scaling issues, at the end of the day, you still need to add more machines as you hit certain traffic, both meteor and nest are using node, the only difference is that Meteor has pub/sub and Nest doesn’t and this is where most of the scaling problems happen.
Meteor seems way more opinionated than NestJS (convention over configuration), it has MongoDB, DDP, and uses WebSocket for RPC, with Blaze as default view layers, while NestJS keeps everything open and flexible, that is why you can have a hello world running example in Meteor but not in NestJS.
I still prefer Meteor simplicity, real-timeness, ecosystem, community and defaults. I think it saves way man-hours than NestJS does. But I think NestJS is a very well designed framework (better than just express + webpack) and might be a good fit for enterprises and dev shops, I think it’s more of competitor to FeatherJS (which I also like) than Meteor.
Got to love the NodeJS ecosystem, every day you discover a new framework! I would like to see NestJS port with DDP on Deno.
Thanks for sharing.
3 Likes
Yes not a problem with nestjs. As you stated its built on express but with fastify also as an option. Its pretty well architectured with modularity as a feature. It has Graphql and prisma support as well. so generally not a tight lock in.
However its nowhere as easy/fast to work with as Meteor. Knowledge of Angular is NOT required but it clearly is designed along angular’s mindset and conventions. I still check up on Meteor because we really could do with speedier development time on some of our MVPs
Yes we build multiple apps so its not a matter for us of multiple databases per app. Most developers I know don’t want and don’t see the need to invest in mongo on a per project basis. They can’t think of any thing mongo can do that postgres can’t but see many areas where they think postgres is clearly more suited. So faced with just mongo in a framework as a first class citizen they say - no thanks
Heres the thing with that though. I don’t know of many enterprises and growing businesess that don’t want flexibility down the line. When you first build an app sure - speed of development is a big issue. With success not so much. with money coming in you can afford to build infrastructure that can adapt and grow with the technology. It seems to me that any company looking to make its money from hosting would need to be backing a stack that could inherently scale, grow and adapt. .
those aren’t sweet spots for Meteor as it is now and from what I read even the scaling that is possible in Meteor is more because of unofficial third parties.
I guess what also is puzzling me is I can’t get a sense of what Meteor wants itself to be - a build tool? A prototype tool? for mainline business? Theres been so many twists and turrns and reverses its hard to see the goal and thats affecting marketing because the only real selling point I hear is reactive out of the box which instantly reminds people - scaling issues out of the box.
Apollo as i understood it was to be an integral part of Meteor . That made sense because in my understanding it gave multiple databases and solved in built scaling issues tied to DDP (maybe I was wrong). For a hosting business model a stack you would stay on even after success was and is critical. Now I hear just as much about meteor being just a build tool as full stack.
I guess to put it short I don’t know after all these years what Meteor’s real identity is.
Agreed in regard to simplicity and development hours. I don’t think the argument can be made for community and ecosystem (unless you meant tight integration). the thing is - if I have to move off meteor once I my app is successful - what good does that do for galaxy? So shouldn’t I be going for what MDG was going for - another solution like apollo tight integrated and at core - ala vulcanjs?
3 Likes
My opinions on what needs to change in 2020 is largely in line with the roadmap. The problem is that people like to see updates, they like to see improvement and movement. And since the roadmap was released in Jan2020 there seems to be a ton of ??? around some of the most needed features still.
Treeshaking status -
HMR status -
Better PWA tools status -
It seems like the effort around these things is pretty quiet. While I know there is some great work being done by talented individuals, it not hard to see that things like NextJS are constantly shipping huge improvements.
11 Likes
Before diving in to all this, I’m just going to say, I still find a LOT of value in Meteor - as is. It’s got a ton of stuff that the other platforms don’t have, or are hard to set up and require a lot of maintenance.
Meteor has so much going for it, it’s just sort of obfuscated. Even during that period when it had the outward appearance of being abandoned (which the new Tiny team has been dutifully correcting), it made huge progress. Look at all the features that shipped during that time: perfect code splitting, modern bundles, constantly updated node.js, cordova, babel, the addition of typescript, and tons of other stuff I’m forgetting.
If I had my way, I’d focus on a central reorg of the way the app’s internals are organized, and maybe work on some splashy marquee features:
- Separate the build system in to it’s own project similar to the way React Native does it with Metro (and maybe some other parts too). (It’s entirely possible this doesn’t make any actual sense, given the tight integration between build system and server. But it’d be nice to be able to use Meteor almost like a CRA alternative for non-Meteor backend projects more easily.)
- Part of this could involve a more formal interface between the various parts - which could lead to opportunities to make things more pluggable - imagine if the node.js tier was as pluggable as the front end.
- Deliver a first-class service worker (hopefully, one built with the extracted build system! That’s not strictly necessary, a statically generated service worker is possible).
- (Begrudgingly) Provide HMR (hot module replacement) or at least some sort of support for the upcoming react fast-refresh. HMR is a splashy feature that people think they want (and maybe is necessary for tighter integration with platforms like React Native) - but is also problematic in a lot of ways. I end up disabling that half the time on projects that can support it. But people want it, and it sets a minimum bar in that way, from a product perspective.
- Alternatively, or in addition to - continue to make improvements on rapid client refreshes when working on local dev. Maybe for example, there is a way to disable server builds for files linked by SSR during development, without having to comment out the entire SSR system (this is pretty easy if your SSR code is in a standalone file, but it can cause workflow side effects, like constantly being in your way when committing to git, etc.). We now have
--exclude-archsto avoid recompiling legacy bundles, or cordova bundles, etc, but it’d be nice if we could target specific aspects of a build, rather than the entire arch in some cases (like SSR).
- Alternatively, or in addition to - continue to make improvements on rapid client refreshes when working on local dev. Maybe for example, there is a way to disable server builds for files linked by SSR during development, without having to comment out the entire SSR system (this is pretty easy if your SSR code is in a standalone file, but it can cause workflow side effects, like constantly being in your way when committing to git, etc.). We now have
Other nice to haves, but not essential features:
- Better command line output. I’m thinking webpack dashboard type stuff
- Maybe some tools for generating PWA assets, similar to how Cordova works
- Better integration options for NativeScript based platforms and React Native (we’re getting there - at least there’s a guide now!). My main goal with the idea of breaking out the build system is to make it more generally useful, but also to make it clearer how we might add extensibility for these types of additional build targets.
- Tighter, more performance focused integration for Cursors with React, as I’ve mentioned elsewhere (some of us are already working on this, maybe we’ll get somewhere some day).
- I once thought that GraphGL/Apollo should be more tightly integrated, but I kind of like Meteor’s system. We could maybe use some higher level abstractions on Meteor’s pub/sub, with data over methods. I’ve got a pretty good base for that that I build for PixStori - I just need to work out the live subscription strategy (I’m actually doing that now for a hobby chat project, might even open source that). The idea is to make it all more compatible with SSR out of the box, providing pagination by default, and make it more scalable than going through pub/sub for everything.
- There was once thought of moving everything to
npm. I still like the idea, even if we would have to extendpackage.json, and/or ship source code, as other projects like svelte are doing. (Or we could jump to deno and support git hosted projects instead -npmcan load from git end points)
There are also things I’d like to see - more open ways to debug problems like memory leaks which only occur in production builds on Galaxy, and things like that. There are some things in the build pipeline that might need adjusting sooner rather than later. I’m adding more and more npm packages to the recompile list of late, for example. I’m not sure there’s a better way to deal with this than what I have set up (which would make a good Medium article - I’ll get on that, it’s kind of important for some things), but it’s becoming an issue.
8 Likes
I think there are two things that cause the perception of lack of progress, and I think @filipenevola has been addressing both of them.
- Some documentation has fallen out of date, and some entire awesome features haven’t had any at all - until recently! There’s been a ton of work going on to bring the documentation up to date.
- There hasn’t a been a huge number of announcements about what all is in what state of release. There is now a regular release newsletter, which is a start. We probably need to somehow promote that better, maybe by mirroring those each with a Medium/blog post.
2 Likes
I hear your point and indeed the identity of Meteor changed a lot with the years, after all Meteor has been around and backward compatible since 2012 (not just 2017) an achievement in the JS land.
I think the new website capture what Meteor does pretty well, it says:
“Build Javascript Applications Faster with Meteor”
I think it a solid description, I’d say it’s the fastest and easiest way to get Javascript web and mobile apps without sacrificing too much control, it has just the right defaults to get you going.
Meteor is opinionated enough to get you started quickly (as opposed to NestJS for example) and flexible enough to get you to production (you can see some of the example production app here), and then you’ve the Galaxy to eliminate the need for DevOps (although you can host it elsewhere since it is just a Node process). But I worked in large and small companies, I understand the resistance of developers in larger teams to use something highly opinionated, developers, like flexibility (and trendy tech), some might be more familiar with SQL and have a preference for it, so they won’t like a framework that forces them to use Mongo, NoSQL is relatively new and most developers are more familiar with SQL, and if your developer is more productive in SQL, then yes, I’d give them the tool they’re comfortable with. I see it as a spectrum, you’ve things like Firebase at one end where you’ve no control at all, Meteor somewhere in the middle, NestJS is more flexible, Feather is even more flexible and then you’ve Express.
But the fact is, Meteor is more productive than NestJS, it’ll save you man-hours (with accounts, real-time pub/sub, hosting, and sensible defaults) however you’ve to agree and stick with its initial choices (especially MongoDB), if you can’t and want the flexibility, then perhaps NestJS, Feather or just plain Express would be a better choice, I personally would go with just plain express, passport, webpack, if I want total flexibility, I don’t see much value in either Nest or Feather at this point, why coupling myself with another new JS framework (2017) with little to add and that could be abandoned (it seems to be maintained by only one developer)? I don’t see much value in NestJS relative to plain express/passport/webpack really, I personally would never use it, we’ve webpack/express and Meteor projects and we’ll explore Deno, I don’t see where NestJS would fit, it is the same reason why FeatherJS didn’t grow, they offer very little to plain express/webpack.
WIth regards to scaling, like I said, if you remove pub/sub then you are dealing with scaling Node sockets, no different than express. With pub/sub you need to scale horizontally quickly to minimize the hit on the CPU (or use something like RedisOplog), again it is solvable and can be optimized with scale. NestJS is not giving you any scaling advantage, in fact, it is offering your nothing for real-time pub/sub or hosting, therefore for me, NestJS is a also a no-go tech.
1 Like
There is already an awesome package (that requires some additional work) that does this, “Grapher”. It will be interesting to capitalize that work and try to use it to create some type of queries that can run over methods and over publications just by setting a flag like reactive: true. I use grapher for all my projects now and its an awesome package to get this performance (scaling) improvements by just setting that flag, among many other things.
A pattern like this shouldnt be that difficult to implement and might be a good selling point. “Reactive where you need it” as opposed to “Reactive everywhere”.
2 Likes
Not sure, but probably the advantage is that handling http request’s is much less expensive that handling websocket connections for every user. Can’t say exactly how much less expensive, but for some people that small (or big) optimizations might be important.
Having some tests and charts to compare the requests per second (for methods vs http requests) would be something interesting to have for comparison. I saw one chart in a GH issue once, but it was not comparing http to websockets but current WS implementation to uWS.
1 Like
This is true, but I think its minor. NodeJS is good enough for handling a large number of open socket connections. However, it does make scaling meteor a bit more expensive (it needs more server RAM) if you hit very a large number of concurrent users, for that, I’d switch to GraphQL or Rest over DDP for the hot pages (and remove DDP accounts) since those protocols are stateless. One thing to keep in mind though, that sockets once established are faster than Rest/GraphQL (since the packets size are smaller), you can see this advantage in infinite scroll for example.
I personally think all real-time by default was not the best Meteor design decision, I think it should have been opt-in and Meteor accounts should have been done over Rest, but it is what it is now.
However, we derive benefits from having stateful bi-directional socket (over-the-air update, simple RPC, faster response, pub/sub) so the tradeoff is worth it. So you’ve to evaluate your use case and pick the best tool for the job.
3 Likes
There are ways to convert to REST pretty quickly (thinking of simple:rest in particular). I’ve often thought that if I ever hit scale issues (so far I haven’t), I’d try that, maybe convert my one paginated package (which 95% of my queries run through) to use REST end points - maybe put a front-end cache in between my running server and the client, etc. Or just use redis. There seems to be no shortage of ways to scale Meteor.
4 Likes
From scratch yes. I don’t think anyone is denying that. but don’t oversell things because with a lot of frameworks you need not start from scratch. I rarely have to start from scratch with Nestjs. To be honest lightning speed of development is always relative to knowledge. Nice to have some framework level built in tools sometime though. However lets be clear here. You asked me what my present go to stack was. I took that as an aside not as a turn in the subject of this discussion. After all I am here and I wouldn’t be if I thought nestjs was the answer to everything. I don’t think ANY tech is. lets not turn this into a Meteor vs Nestjs discussion. If I answer some of your points thats where it would go and I am not here for that. I never volunteered Nestjs as superior or inferior oreven brought up it up until asked.
Unfortunately ( or perhaps fortunately) thats not the way the world works. You don’t need to stick with anything. You can rewrite (and only app flops never get rewritten) and leave (which does Galaxy no good). Technology moves on which was my point and if we are honest whats happened to Meteor to a large degree. With new ownership I see a hope from most to have a new resurgence . I don’t think that kind of binary thinking really helps. we are talking technology here. the idea that its a positive thing to be locked in doesn’t make a lot of sense unless the thing you are locked into is so ideal and near perfect there’s no issue.
Still, don’t really accept your premise of “especially mongo” or no fast development speed benefits . As if that’s the only way forward. Curious as to what you think of Vulcanjs. Yes Meteor as a build tool (and I believe for things like accounts) but no not married and forever bound to Mongo for all the rest. As for Nosql being relatively young. Thats a bit of a reach. Anything in tech for over a decade can’t make claim to being new in anyway.
On the whole other stuff on nestjs (hosting , real time etc), like I said won’t get into it. You are wrong but nestjs was never the subject of this thread or my initial post. My point on scaling always referred to third party packages such as diaconutheodor’s great work and to that being brought in in an official way. Like it or not The framework architecture creates a scaling issue so solutions either should be built in or officially promoted and taught. In my discussion with diaconutheodor a good while back The numbers looked much better but we’ll just disagree that express has nothing to offer in its whole ecosystem that gives it an advantage. I don’t think that would need a rebuttal even if this were a discussion about nestjs
3 Likes
Definitely Meteor in 2020 and beyond!!! 
@dandv you really gave a nice summary of why Meteor is still really amazing!! Meteor + Vue for me is a dream come true, and I can see reasons why people want their front-end (view layer) of choice to integrate with Meteor.
Building a new app is the dream with Meteor and it’s so much easier to maintain than any other option too. 
Great additions @alawi and @jkuester … I think any Meteor app can meet the PWA criteria. And to have a stack that is all open-source, should really never be undervalued, it’s the key to longevity & a strong eco-system of devs.
I really like this idea of Meteor devs cross-pollinating with other devcommunitiess as I think it will bring a lot of the right kind of attention to Meteor.
6 Likes
I don’t see much locking me in to Meteor, except convenience. Most of my code is portable React code. On the server side, my methods could easily be ported to any other transport framework. My SSR code is a light abstraction on connect.js, and could easily be ported to Express.js or anything else. I’m a bit locked in to Mongo, but even there, I could rework most of my queries to use any Mongo driver directly - I just lose convenience.
In fact, I could literally replace each of these aspects within Meteor to start - replace the build system with webpack (but why?), replace Meteor collections with Mongo directly - I’ve seen some folks swear by that - or better, replace it with Apollo, in Meteor. I can even run Express.js along side or on top of connect.js (I think). In fact, one of the Apollo package does exactly that. I could replace Meteor’s accounts system with account-js. After each thing has been ported away, I could replace the entire build chain.
I just don’t see a reason to do that. The problematic parts people reference in Meteor when it comes to scaling all have workarounds, and models we can use to scale them - or you can just use Meteor’s underlying node.js system directly, and not use the parts you don’t like. It’s so modular that way. It’s like ejecting, without ejecting.
Unless I’m missing something.
6 Likes