lock-in was a poor choice of words especially in the tech community where it has a particularly negative connotation.
I meant more “attract people on their own free will to use MDG’s paid services/products”.
Is it time to leave Meteor & MDG?
No, but I think it’s time to leave this thread … reading and digesting all of the great points in this thread is seriously hurting my productivity …
21 Likes
In my opinion MDG is doing the right thing.
Like any other business in a capitalist market they need to adapt, evolve and grow as the market and ecosystem evolves. They’ve sensed the risk from React.JS, GraphQL, Angular.JS, NPM, etc… and concluded that it’s difficult and more importantly unnecessary to compete with those emerging open source communities so they embraced them. And to their credit they’ve been transparent about their decisions, they’ve communicated their roadmap and they’ve kept their backward compatibility. They’ve also modularized the framework to make it easier for the community to maintain going forward. So to sum up, they need to adapt and grow their business just like any other business and that sometimes involve tough decisions and compromises since they’ve a wide user base to serve.
So what about all stuff being ‘deprecated’? well these are open source libraries, the code is available and if many people need it and depend on it, then I think a community will emerge to maintain them. I personally appreciate what MDG is doing in adapting to the ever-evolving ecosystem, brining the best of what out there so we can actually focus on our business.
So relax my friend, we’ve something that works today and open source, and there are exciting stuff on the pipeline, yes you might need to learn new stuff, yes you might need to refactor some apps, but that is the nature of JS ecosystem, the tradeoffs of being cutting edge and innovative is the necessity of constant change and learning.
Just sharing my opinion!
7 Likes
Haha, the conspiracy theorist in me says that MDG has been intentionally not fixing build times to increase forum activity… 
3 Likes
I have developed music using AIR and shelved the project after a year of wiring code. Not due to performance issue, it’s frustrated how Flex 3 is almost unheard in Singapore, likewise, Meteor and Apollo as well.
Adobe AIR is not a framework (runtime) and not the leading, Swift and Objective C programming language is the leading. Look at the jobs availability and iPhone has the largest market share in Singapore.
Whether to leave or stay is largely depend on the community you have. It’s also makes sense at this period, lot of technology transform significantly.
Swift
Java
Python
Javascript
RubyonRails
Go
Rust
PHP
Some Javascript framework.
Whether it’s worth the investment, Java is the safest, RubyonRails, Go and Python are popular. e.g. Kickstarter stack are built on RubyonRails.
If you have a good knowledge in Meteor’s internals, you can contribute to it, that about it.
1 Like
OK so I would summarize problem points for meteor right now like this:
- After 4 years Meteor still feels amateurish (looking from java world perspective). They are delusional if they think they can get any big traction in enterprise against java and .net ecosystems. Documentation, support, partnerships, products, integrations, stability, legacy, the way enterprise moves and the way decisions are made etc… Lets just get real.
- From innovation and leading they became simple followers chasing the last “best” technology. That creates uncertainty and show they are not confident in their own product. Which leads to # 3
- “Old” Meteor seems a bit neglected and it looks like most of the things will be deprecated. And if stuff you use is deprecated then definitely you need to use something else.
- Even for things that are added documentation is poor and it’s hard to find out how they work. I personally got stuck with ddpratelimiter (how to make a global rule for all methods?) and pollingInterval/pollingThrottle (https://github.com/meteor/docs/issues/72). But that’s probably side effect of # 3.
- Third party meteor packages are mostly unmaintained now and any development/improvement completely stopped. That’s bad. Very bad.
- Meteor is slowly loosing its "easy to use and productivity “features” and it’s bad because that was one of the core selling point.
- Not solving some important problems like those f** build times. I still see posts about those infinite reloads (which is a huge issue if that is still happening). Not sure if it’s just me and my setup but stacktraces are often worthless. Pretty sure performance and scalability could use some work too.
- Not that good tooling. I personally absolutely don’t understand why profiler was created and monetized by a third party. When it was closed ecosystem tooling was an obvious place for monetization. Meteor IDE, Meteor debugger, Meteor Profiler, Meteor deployer, Meteor load balancer, Meteor production monitor, Meteor app store for paid packages… Now there isn’t even official support on how to deploy an app on server (not on galaxy). Good luck with enterprise.
- Lack of communication about this transition. Yes MDG kinda provided information, but that’s not enough. They need a marketing guy or maybe PR firm. I think that could possibly make a difference from “is Meteor dying?” to “I’m so pumped up for 1.5 and apollo I can’t wait”. Unless of course apollo is not what users want. I asked here on the forum about a clear explanation of what value does apollo bring over just using facebook stuff and even asked one MDG member who seemed to answering questions in one of those “meteor is dying” threads but really got no answer. So I am not sold. This is a critical moment for the framework and MDG needs to learn to sell now. Hire a marketing guy.
- Because of some or all of those reasons the biggest problem - loss of confidence. That’s why 3rd party maintainers are leaving and all those threads are popping up.
Oh I wrote more that I thought I will 
So after all this - is it time to leave? IMO it’s no. If it worked for you before, it is working for you now. Framework is still moving forward and in 1.4 we have got node4 and mongo 3.2 which is nice. We can still use “old” meteor and be productive. Now let’s just wait until transition is completed and then we will see. However even if it’s not a time to leave I would also not enter right now because of all those reasons.
14 Likes
I fully agree, especially on points 6, 9 and 10. I’m President of an academic department in digital humanities. I was the first promoter of Meteor to my colleagues. Students with no heavy background in IT need a framework easy to grasp with good documentation, sandbox, easy deployment and a great bunch of open source examples. Meteor had a lot of those when I started, less than two years ago. Quite everything is gone now, and MDG never looked really concerned about it.
Like other people here, I hope those are just turbulences. I’ll stick with meteor for one more year, but I am sadly looking at alternatives and will be really cautious recommending it to our students.
6 Likes
Meteor needs to redouble on its current products and rethink their strategy. Apollo is a great initiative and deserves the investment. That said, Focusing too much on the future and not on the present will continue generating these types of thread and discussion in the community.
I wrote an app in meteors early days and it was a pleasure. I sat down, drew a few diagrams, read a bit of documentation on blaze, installed a few packages and in 30 minutes I was writing code that pertained directly to my needs. 3 days later I had a testable application and didn’t need to write much code that didn’t pertain to my particular application logic. Like many, I thought meteor had hit a sweet spot.
Now we are on react. I think that’s great. React is wonderful to use. a bit more boiler plate than blaze, but well worth it. Last week I sat down to write a meteor react app and let look at how that experience went.
I sketched out my app, did some reading on meteor/react integration. Then I sat down and started writing. Set up some collections, worked with both create container and tracker react to see which appealed more and picked a direction. Getting data in and out was still a piece of cake. That’s good news. Data to react seemed reactive. all good. I picked flow router and that worked well. so far so good.
Then I tried the login packages for react and they were all crap. I had to write my own. Then I looked at integrating a few custom components and had issues getting Meteor.User as a reactive source. More headaches. and a ton of other small headaches.
The point is it was a different experience this time around. I spent significantly more time writing boilerplate and components that didn’t apply to this specific case. There was no magic any more. It left me wondering why I was using meteor. Elixr or horizon would have been a better solution. At least in those cases I wouldn’t have had to deal with the headaches of React/blaze, flow, react router etc.
Meteor needs to (IMHO), Pick a direction and fully support that. that means…
If you support react and include it in your documentation, then support it. Take the time to create all of the key packages, or throw bounties out to give me user packages, form packages, etc that give us all the same experience we fell in love with the first time around. Don’t document that I need to wrap a blaze component in react. It feels like a hack. I shouldn’t have to install blaze at all. That’s the whole point of react. You react documentation shouldn’t include blaze for a new project. the current document is find for hacking a transition together, but not for a NEW react/Meteor project.
Key point is, that MDG needs to take a step back and remember why many of us fell in love with Meteor. At the end of the day it wasn’t blaze. Blaze was just easy to pick up and then we were off writing our code. Our code. COde for our app. That wasn’t the case this time around, beyond the authentication example I gave above. Just my 2 cents.
9 Likes
WIth all the problems you listed why are you still using meteor. Because if I read your list there is no case to even use meteor. Better go back to Java and .NET as they are mature and great ecosystems.
Your point about the React integration is spot on. They need to come up with packages for react as they did for blaze. They should create all these packages like Accounts for react, Some forms package. Adding Apollo, npm support is all fine and dandy but keeping an easy/low entry bar for new comers is also very important which basically is lost once blaze was deprecated.
3 Likes
Thanks for the affirmation. Meteor will never be the greatest most efficient technology. If you write something your self and tool for your specific needs and you have a good team, you should always beat meteors performance. That’s the truth for all frameworks. Meteor USED to fill the get it done quick and deploy, but I know it will scale reasonably well (especially with Meteor Hosting) and its easy to tweak and add features. It was great for startups and Marketing apps that needed quick reactivity. No long the case. Not sure if I’ll use meteor again until I see a guide for best practices without the word blaze in it : ) and with some work on the react native side added. Sad thing is that its out there. I see the code. I just don’t have the time to refactor it into NPM only packages and test it. That is, after all, why we use frameworks.
1 Like
From what I can tell, there will be two different stacks soon:
1- “Classic Meteor” - Blaze/LiveData
2- “Facebook Stack” - React/GraphQL/Webpack
Meteor has indicated interest in Webpack, the idea of making React #1, etc.
I think what we’re worried of is one day being told something like, “so, we’re moving to Webpack, which works great with React and not Blaze, and React works great with Apollo, so we’re deprecating all the previous tools.” That seems to be the direction.
I kinda wish Meteor would be left as Meteor and improved with the things we asked. As Sashko said,you can literally “copy and paste” your way to an app - and that’s a very unique value prop. In fact, there will be many options for GraphQL on FE and BE, while Meteor has true uniqueness with its integrated approach and development velocity.
Apollo can be big because it will leverage all the marketing Facebook did for GraphQL, but I think Meteor could still earn its place.
I feel the transition from the Classic Meteor to the Facebook stack is driven by the needs of Galaxy customers, but I think the better move would be to maintain two frameworks instead of moulding one into the other.
8 Likes
I think the Apollo strategy is a reaction to the JavaScript world, but I think if MDG marched on with Meteor it could end up in a really unique place.
8 Likes
Lock in factor is basically an anti-pattern of business. Having a hard, long term commitment to something that someone isn’t completely sold on will dissuade potential customers.
MDG can get ahead by making solutions which are simply objectively better than the competition. Take Galaxy for example, instead of configuring everything on an Infrastructure as a Service, let’s say that it had everything immediately set up for you. It also provided a simple way to set up s3 buckets and all of that.
If that were true, why not use Galaxy if its comparable in price? So much more worth it.
1 Like
If they had broken out LiveData / pub-sub / the Meteor.collections API stuff into it’s own NPM module(s) (probably two: a server-side one and client-side one), that would have been awesome. I guess they’ll sort of be getting there, at least with Apollo.
It’s certainly unique, and they tried that, but it didn’t catch on (most likely to do lack of flexibility, like no initial NPM support was a huge drag). Maybe you could still have that ‘copy-and-paste’ experience if, from the group up Meteor originally was a vanilla nodeJS app with NPM packages. It wasn’t that the old stack was bad per-se, but the biggest challenge I faced as a developer was I couldn’t use the pieces that I wanted and discard those I didn’t need. The entire stack was very much all-or-nothing in its infancy, which proved with the community to be a weak architecture idea.
I’m not certain the ‘new stack’ is necessary – the bigger problem was the way the old stack was structured. Since adopting all this facebook tech, like GraphQL, they’re losing the value prop of the copy-and-paste app. I loved how fast I could iterate on a Meteor app when it was around v0.8. I just needed more flexibility with what I could choose to bring in.
2 Likes
You’ve strong points here…
I don’t think Meteor not catching on had much to do with lack of flexibility. Some things may have not played in favor of it catching on (like no npm). But I think it was just a marketing thing along with the “hype fest” nature of programming these days… this hype fest is evident if you look at the history of turn over:
2010: OMG WE HAVE TO REWRITE OUR APP IN BACKBONE SO IT IS MORE MAINTAINABLE
2012: OMG WE HAVE TO REWRITE OUR APP IN ANGULAR SO IT IS MORE MAINTAINABLE
2014: OMG WE HAVE TO REWRITE OUR APP IN REACT SO IT IS MORE MAINTAINABLE
Meanwhile, you’ve re-written your app 3 times for the sake of making maintaining it easier… but you never actually got around to maintaining it… and all that investment in learning and laying down the new library was basically worthless.
Then on a more micro-level you have stuff going on like flux/redux/reflux/ducks/shucks/nux/mobx
where the influx of this massive amount of libraries is a mix of
(a) the huge incentive to get famous the dan abramov way
Everybody wants their little library to catch on like wildfire so they can become the next messaih. So you have guys popping out new libraries every 20 minutes, and dudes like Staltz on the verge of loosing his mind trying to get people to drop react and use cycle.js.
(b) the fact many programmers are totally okay tearing their app apart and spending weeks learning new libraries for basically no material (read: $) reason.
This plays into a monsoon of blog posts about how you must use this right now or you company may die (even though, ironically, it is more likely you waste time on XYZ and your company dies).
© many decisions being made by the programmers
…usually without the best interest of the overall company in mind, or without the knowledge/skillset to make the cost-benefit analysis. Most places, when the sr developer isl ike “we need this”, the business side is just going to be like “okay. we need this.”.
The Result
The result is it was harder for Meteor to appease and get into the hype fest. I think it had very little to do with the technology. I think in many cases it has little to do with the technology. There are probably tons of “better” libraries than redux, redux didn’t win out because it was the best, it won out because of a bevy of reasons.
As @maxhodges pointed out, you can build an app that is maintainable with old meteor. There are tons of examples… facebook and google used boring java and php… they got up and running without using haskel.
19 Likes
Everyone else in this space has way less lock-in that Meteor initially had, though admittedly Meteor is still probably more popular than these alternative frameworks. I’ve previously mentioned Feathers.js, but there’s also loopback.io – here’s a comparison with Meteor. But it’s great to see Meteor moving in this direction.
I think GraphQL actually has a lot of possible value to bring in the “copy-paste to success” direction. Once you define a graphql schema, then you can basically write a bunch of queries for your client (which you can edit in this nice, auto-completing query editor) and not worry about them anymore.
If you pair this with something like React Storybook from Arunoda, you could end up with a really nice workflow where you can develop all of the parts of your app, then stick them together and be done with it.
I think the biggest loss in the copy-paste department is with HTML - since you can’t easily copy-paste HTML templates from online themes into React or Angular, you need to learn some new syntax for that which is kind of a hassle. But perhaps Blaze or Ember, even though they are less trendy, could make a resurgence - there is steady progress being made today on decoupling Blaze from the rest of Meteor (even though the process has taken a very long time).
4 Likes