Have you thought of creating a PR? I know that’s not generally a satisfying response, but it’s all open source. Having your team refactor 69,000 LOC sounds like a lot of work - it may be comparatively much less work to have them create a PR.
1 Like
Meteor just needs to be Meteor, the ultimate web stack.
My top three wishlist is:
- updated Mongo package - the changes in MongoDB 4.0 are worth it
- service workers - the timing is right as iOS is catching up to Android for PWA support
- that’s it - Meteor is great
19 Likes
I do think Atmosphere can use some attention! It’s kind of embarrassing right now, all the counters are off. Also, the UI is kind of clunky… I think something much simpler could be designed.
At least, the counters on the squares should be consistent with what is on the package page, and those fake trending graphs should go. Also, MDG packages should be removed from the Trending packages, obviously they will trend the most, but the real goal is highlight great third party packages. I’d even get rid of MDG packages from Most Used.
10 Likes
There was a bunch of talk a number of years ago about deprecating atmosphere in favor of npm as the new standard. But I think there are a number of advantages to atmosphere packages that make them work it, including but not limited to benefits for modern bundles. Npm packages all come precompiled.
4 Likes
That’s not a restriction on npm itself, you can have a build script run post-install. Quite a few packages that compile native binaries do this, since they must compile on the platform they’re being run on
Yeah, basically, Meteor build tool will always get better integration with its own packages than with NPM
2 Likes
I hope we will ever see a Meteor 1.9. Since it seems Ben is mainly working on Apollo now, leaving Meteor with nobody?
6 Likes
I share that concern, although I think Meteor is relatively mature yet there are always areas of potential improvements specially optimizations around refresh/build speeds, these are always desired. I like Apollo, but Meteor (and especially the build system) is the heart of many products/businesses/open source frameworks thus it is worthy of more attention I think.
With that said, I do sense (and especially in Open Source) that people ask for releases and commits just to signal livelihood, in closed source and typical commercial products there are other ways to get those assurances. In my opinions commits of that nature are not worthy of Ben’s time (or anyones time). We (as a community) had so many rounds on what to expect in Meteor 2.0 on this forum and most of the stuff that came out from the community are good to have but nothing critical really.
Also, I sense that a lot of commercial companies who used Meteor to get to a certain state of success that they can afford some dev cycles to Meteor don’t reciprocate back and most refactor to something else instead of investing back when they can.
I’m really grateful for the work of MDG and the community on Meteor over the years, I really think it’s the best NodeJS framework out there and specially useful for entrepreneurs and those who try to bootstrap their business.
5 Likes
While Meteor is in a pretty good shape right now, the whole ecosystem evolves and so standing still is going backwards.
Yes, but it’s not that easy to contribute back with the way Meteor is set up. A lot of pull requests take months to get a look at from MDG, some are just ignored forever.
6 Likes
Well, I see things slightly differently. Since 2012 I think NodeJS/font-end ecosystem has been churning with a new wave innovation driven by pressure the the growing complexity of web applications and the demand of faster real-time mobile experiences. React (web components), Graphql (data layers) and webpack (build systems) are all symptoms of those pressures. However, I really think the innovation in NodeJS/Web ecosystem will slow down at that stage until another wave of innovation hits. Innovations usually hit in a cycle of 10 to 15 years due to constraints in commercial adoption speed. The ideas of react are at least 10 years old. Until another wave of pressure (IoT, VR/AR, serverless, massive real-time online social experiences?) hits the web platform to trigger another wave of innovation, there will be a slow down over the whole ecosystem, just like all other paradigms and ecosystems before it.
Meteor managed to survive the churn in JS (thanks largely to Ben) with opening up to NPM, supporting multiple view layers, dynamic imports/code splitting, build speed improvements, and ES6 support.
Correct me if I’m wrong, but I think there is nothing that can be done by other JS frameworks today that can’t be done using Meteor, in fact Meteor pushes a little further with different bundles per browser.
Actually I see lack of PRs more than the lack of merge, Meteor code base is complex and cover a really large surface area…but I might be wrong, don’t know.
2 Likes
After 5 years with Meteor the developer experience has been fantastic. The killer feature for clients has been reactivity, thanks to DDP and MiniMongo. The only reason for not using Meteor on all projects now is its lack of offline support, which has become a much requested feature recently.
6 Likes
That’s interesting. The offline support is at the opposite end of the spectrum relative to real-time connectivity, the framework was not designed for that. But I’m curious, what other frameworks does offline support out of the box and what prevents your team from adding offline support using to a Meteor based app? I still struggle to see the use case for offline usage in a web app maybe some example use case would help.
2 Likes
But I’m curious, what other frameworks does offline support out of the box
This is still research, so no recommendation here.
what prevents your team from adding offline support using to a Meteor based app?
That’s limited resources. I have also limited hope that this becomes part of Meteor as the people requesting it can only pay with love and admiration.
I still struggle to see the use case for offline usage in a web app maybe some example use case would help.
I live in the 3rd world, we have areas and times with a good network, that’s when we want reactivity but then the network connection drops, but we still want to do our work and catch up with the net when it feels better.
5 Likes
As I said Meteor is real-time first framework, so offline support seems really the opposite of what Meteor is all about by default. But perhaps it can be extended with community package.
But offline web apps is a strange concept, at least to me, if the data is edited by one user then yes I can see how this might be useful. But as soon as the data shared by multiple users, then when one user is offline and others are still editing those docs, then there is a risk that user entire work might rendered irrelevant when he/she come back online due to conflicts, so how are you planning to work around that in your offline app design? the app needs to do something like merge conflict in git.
I am surprised of your point of view. Offline support is what will bring the web closer to the native apps.
When you are in the train, under a tunnel, in the mountain… You wish you had offline support to let’s say open a map, play a game… possibilities are endless.
When the app goes live again it will sync all the state to the server again.
By the way we have some package for offline use of Meteor, I never tried myself but there is the famous https://github.com/GroundMeteor/db
I believe support for service worker in Meteor is as urgent as it was to adopt npm back then.
I mean, the full web is moving to offline support, PWA and so on…
1 Like
Well I’m just playing devil advocate here. I’m aware of the push for service workers to cache some data and reconcile and improve UX and I’m big fan of PWA, I support anything that improves the web platform.
But that data sync is not at trivial as it sounds so the added complexity need to be analyzed carefully. Service workers support notifications and page caching among other things so it’s definitely good to have to get closer to native. When people say offline support I guess they really mean just gracefully handle the case when user is offline, so show a nice page instead of connection not available. But if all your pages depend on data from remote server that can be edited in real-time by other users, what exactly are you planning to show to the users while they offline?
the app needs to do something like merge conflict in git.
Dealing with conflicts and stale data as old as networks. I don’t say it’s trivial, but there are apps where it is preferable to risk conflicts over not being able to do work.
It’s not trivial and that was my point. In many cases these data reconciliation are not even feasible without getting back to the users and if they’re they might not worth the added complexity. I personally don’t like to chase trends without scrutinized them heavily and I don’t see much UX value in offline-online real-time web apps that justify the added complexity. On top of that, the world is heading to have even faster and better connection globally, so I wouldn’t bet on that trend either. But I’m open to ideas, maybe I’m missing something.
I have a pretty good start to an offline-first solution (actually, it works - my apps are offline-first), which uses the bones of Meteor (mini-mongo through ground:db client side, straight Meteor collection server side, and data over methods, not pub/sub, with SSR, etc.) - part of what I’d like to see in a Meteor 2.0. I’d love to move from ground:db to some apollo service-worker cache based storage (or just keep using ground:db even with apollo!) - the fairly simple pattern I’ve set up should actually work quite well with apollo too. What I think is nice about the patterns I’ve developed is they are easy - the data getters/syncers/SSR (for lack of a better term) are all relatively well contained - the implementer (Meteor user) just has to implement a “connector” which is a set of 4 functions, and then use the HOC wherever they need the data. Wrapping Apollo into a pattern like this could potentially even make that more approachable for Meteor devs. I’d actually love to work on something like this full time - but I suck at financing, and business in general lol, sigh…
8 Likes
@sakulstra It should work: I’ve been working on an accounts package usable as an NPM module instead of requirement a legacy Meteor-style (Atmosphere) package. And it’s written in Typescript 3.x and tested with Jest so it’s definitely doable, although non-obvious.