Yet Another Topic about what Meteor should be


#1

What about my ideas : offline support and espacialy make SW installable (mitar even made a PR but they … just refused it … (I say that because I created a SW for meteor : https://github.com/NitroBAY/meteor-service-worker)), windows bash (linux subsystem) support, no DB support : HTTP for basic websites which don’t want DB, websockets (not for DB) for instant chat but actually especially for games (if one wants to share X,Y of a player in real time to other users), keep going on more openess (install any templating framework from npm/atmosphere), transitions : I tried a lot and they were all buggy, like if it couldn’t really implemented by Meteor, I use Flow Router, HTTP 2.
Make meteor installable as a npm module is also a great idea, do you agree that it would make deployment way easier as most server support node.js but we had to do some changes to upload Meteor to a node server ?
Apollo is a great idea.
Other things are weird : I start with a project before summer with Blaze (I look on Internet to choose between this and React/Angular and almost everyone were saying that Blaze > all) and mongodb (no choices) and today mongodb and Blaze has been almost deprecated (no support from official team for Blaze) and Apollo will replace mongodb. I agree with these moves but it was sudden, they could have give me 6 month/1 year, as I first need to end up my project, wait and learn for new techs and refactor my app. NPM integration is a great idea, deprecate Atmosphere is really stupid.
And in a more global way Meteor is missing every single new tech like if it was something incredible when it came first but now it’s old with a potential but too old for new projects : no HTTP 2, no Service Worker etc.
Please progressive web apps should be so obvious to be enabled for a framework like Meteor https://developers.google.com/web/progressive-web-apps but still it lacks HTTP2/SW

Meteor had 2 problems : openness, popularity.

openness is improving

Meteor has now 2 problems : old (some new tech are not compatible), not popular (the ecosystem is definitively way too little).

I think MDG should burn a lot of $$ to push Meteor in a virtuous circle, actually I even think they have no choice… Meteor is so great but sooooo slow. node.js felt better, when node.js was too slow, io.js has been created and finally it put pressure on node and so both has been merged. Meteor could also bennefit from such pressure


#2

Are you referring to build times? Meteor 1.4.2 has improved build times substantially. Also, in a recent Transmission podcast @sashko noted that Webpack slows down with larger projects and has build times that are comparable to Meteor.


#3

I wasn’t talking about building times. But for me even with 1.4.2 I have to wait 30 seconds, because I have windows, the problem is that I actually also have linux as Windows embed Ubuntu shell but Meteor doesn’t support it… It’s one of the issue I raise in my earlier post. I was talking about the fact that Meteor doesn’t adopt new technologies nor requested features.


#4

For discussion purposes, I would like to say a word in support of MDG here. I would say that MDG does adopt new technologies and requested features. The most-requested new features for Meteor recently were:

  • Access to other databases
  • Faster build times

MDG has addressed the first by introducing Apollo, which is now production-ready. v1.4.2 addresses the second, and may possibly put Meteor in range of Webpack in terms of rebuild speed.

Certainly there are always new features to be added, due to the fast-growing node.js world. But it seems to me that MDG has done a great job of adding new features.


#5

That the point, they spent thousands of hours to create and to integrate Apollo but they don’t spend few hours for Service Workers, HTTP 2, or just open the communication protocol, Meteor uses websocket why don’t they just allow us to connect directly to it. They made a full linux versions and spend a lotttt of time on an very slow windows version why don’t they just work to make ubuntu on windows working with Meteor. THIS is the problem, I don’t know how MDG is headed but they sometime spend really a lot of energy, money and time in one project (react/angular, npm, Apollo etc.) but don’t fix little problems who destroy Meteor.


#6

I would like a feedback on what’s going on about the feature I talked about. I would also like an official docker image, even tough MDG is making money with not reasonable price of galaxy this expensive solution
is not a real option for 99% devs in the world (not just Meteor’s one but also those who could one day learn Meteor)


#7

@nitrobay if they can’t do it, let us, the community do it, let’s help them. Take my example:

I whined about why Meteor didn’t do it at first, but then I took charge and began implementation.

Proof:


Official docker, again up to the community check the thread here

You make money, or you want your project to make money of Meteor’s technology, but what do you invest ? Think about that and change the attitude, we’re interested in seeing it grow, but just stating what the problems are, and complaining leads us nowhere unfortunatelly. Come-up with a plan for HTTP2 and Service Workers, figure out what the cost for implementation would be, let’s see the real advantages, why/how should we use it ?

Come on, let’s do it, we are here to help.


#8

Lol obviously I have your mind and I’m glad to make PR for CSS/JS front-end frameworks, for JS plugin but Meteor seems a lil more complex, besides Mitar has already came up with a plan to register web workers, it was perfect and not a big risk for MDG as only a few line were changed. But they refuse their PR.


#9

And when it’s on my level I code directly, I don’t “whine” proof https://github.com/NitroBAY/meteor-service-worker but I’m not at MDG so stuff as HTTP 2 should just be included by them not by the community in my opinion. Other stuff can be proposed by the community but they refuse an essential PR that didn’t push people to spend time changing a complex framework maybe for nothing.


#10

I understand your concerns better now! Well, it’s an open-source project in the end, we can branch it off in whichever directions we need.

I’m almost sure they will come back to Meteor, otherwise they would have lost a ton of money. But we should help them that’s what I’m saying.

Other stuff can be proposed by the community but they refuse an essential PR that didn’t push people to spend time changing a complex framework maybe for nothing

Do you have any examples?


#11

I can tell by your questions that you’re new here… The answers you seek are scattered across this forum if you know what to search for. I no longer go into details on topic, for the most part. But if you read carefully, you’ll find the search terms you’ll need in the following sentences:

``> MDG’s primary focus now is Apollo and the new tech around it.

``> Most tech related to Meteor classic, like Blaze, Tracker, DDP, Livedata will no longer be worked on by MDG. A few are in the process of being broken out into their own projects for the community to further along.

``> MDG is really down to one guy working on Meteor classic these days, and that’s mostly in areas like build tool, separating Blaze and Tracker from the main project, updating Mongo drivers and node versions, etc.


#12

Tracker is reactivity. Reactivity is one of the core of Meteor, how could they split Tracker from Meteor ?


#13

Search on meteor/meteor github, search on these forums to find out.

Here are a couple that came up:


#14

Hmmm intersting I didn’t taught that the core of Meteor can work without Tracker