Is it time to leave Meteor & MDG?

[velistar]

I would like to add my 2 cents here from a completely different perspective. Currently I am a FileMaker Developer for some time now. If you don’t know FileMaker it’s Apple’s equivalent of MS Access but much much better. It’s a fantastic tool to build custom apps for businesses but it comes with a few caveats. First of all its proprietary and Apple related so you pay quite a hefty price. Second development has been fairly slow (once a year update) and always a couple or three years behind current tech trends. Third is if you want to scale you are kinda screwed as everything is locked in its specific language that you need to start from scratch on another platform/language.

Regardless of the above and a few other stuff, it’s a great way for anyone and I literally mean anyone to start building an app to do something. It won’t be the next FB or Google but it will be something to serve their need for their business. Now I am not here to promote FileMaker but to give another view. As I need to serve my clients best, some of them want to make their apps available on larger scale and sell it as a SaaS. As I have said, this is very difficult and very costly of FileMaker as you need to buy the proprietary licenses which in the recent past have inflated quite a bit thus a business model could easily go bust with the next update. So I have been looking at what is out there to learn and use. I learned Swift for iOS and RoR for the web. Still it felt to me that RoR, although would do the job, it was getting a bit old and the language is very specific, etc. etc. Swift on the otherhand is (yet) only for Mac and iOS so very very specific given the size of the Android market as well. So I came across Meteor!!

Wow, web and cross-platform mobile ready with even a small chance for desktop as well and all in one simple language…JS. For me it was spot on! Learning it will be a challenge for me and learning MongoDB as well will be difficult as FileMaker is RDBMS but already I started getting the hang of it and love it. Certainly nothing out there is the perfect language and framework but for my purpose Meteor just fits.

Now, I am also a Risk Management expert and I tend to analyse risks in my work as much as possible. Sticking just with FileMaker like some folks do, for me its a very very bad idea. Your entire livelihood is tied to a single corporation without any alternatives. Although the likelihood of FileMaker in shutting down is very very remote the impact on our business is just catastrophic. As a Risk expert this is a “no-go”! Meteor on the other hand has much larger likelihood of failing, I would say just south of medium. But the impact wouldn’t be that bad. You already have a large community to back-up for some time, re-writetable code, use of NodeJS and MongoDB which have far less odds of failing. So in that respect its a pretty solid risk to take with Meteor even if they change to something else or fail altogether!

Edit:: Given some of the comments below I am editing this post to make a clarification and a correction. The sentence “Meteor on the other hand has much larger likelihood of failing, I would say just south of medium.” should have better be written as “Meteor on the other hand has much larger likelihood of failing compare to FileMaker, I would say just south of medium that is around 20-30%.”. That’s a still a low probability but a sizeable. To make things even more clear, FileMaker has been in business for 31 years with the last 74 quarters profitable and a backing by Apple, so I think an estimate of <10% likelihood of failure is justified. On the other hand MDG is still a startup and so far has relied on external investment JavaScript framework startup Meteor Development Group takes on $20M with revenues only now being made from Galaxy. Its not yet a solid proven business model that has endured over the years. Still I do give such a low likelihood of 20-30% of failure. This is not in comparison with just startups but any company for that matter due to the size of the investment it has got, a good mix of open-source and paid services.

One more factor that pushed me to Meteor was Galaxy, a way for Meteor to make some money and keep developing the platform while also having an easy deployment and scalability. I still don’t understand what GraphQL is all about or Apollo or how it all fits together and the imminent changes but we live in the tech world and the tech world is evolving all the time. Especially the open-source world of the web is changing in a blazing fast manner. If you want the comfort of developing on something solid that is not changing as fast as Meteor or shifting course, then just go to the big guys of Microsoft, Oracle, etc. These guys take ages to move!

A final thing to add here. Last year a well known FileMaker developer suddenly “dropped out” of the FileMaker world and focused on these other platforms called Xojo, Airtable and iOS dev on Swift. He kinda left in “bang” by making a long blog post which shocked quite a few people. It almost got me very scared at the moment and he was talking about the direction that FileMaker was going and that it was all bad, blah blah blah. This year I went to my very first FileMaker DevCon and realised that the guy was totally full of it. Nothing he said made sense to me anymore. I am not dropping FileMaker anytime soon and that’s for sure but I am investing on a new platform such as the lovely Meteor

I hope at least my words mean something to someone.

[comerc]

A: Yes! I learn Clojure with Om.Next & Datomic.

[maxhodges]

As a risk management expert can you share the data you have on this conclusion about Meteor? also what kind of timeframe do you put on this estimate?

@velistar

I am also a Risk Management expert. . .
Meteor on the other hand has much larger likelihood of failing, I would say just south of medium.

As someone who has invested well over $200K into Meteor app development over her past couple years, it’s alarming to hear your expert opinion that Meteor has less than a coin toss’ chance of survival. What was your methodology for coming to this conclusion? Maybe we could reduce those risks if we had access to your analysis. And what timeframes are we talking about? 50% chance over the next year? 70% chance over the next 2 years? Does your dataset include Galaxy’s P/L statement and cash flow projections?

Finally, a risk management expert who can reliably estimate the success of startups like MDG could make a lot of money consulting for venture capital firms and other investors.

[maxhodges]

@velistar

I still don’t understand what GraphQL is all about or Apollo or how it all fits together

Now I’m confused. You are a self-proclaimed “Risk Management expert” and you believe Meteor has more than a 50% chance of failing, yet you don’t actually understand the significance of MDG initiatives like Apollo?

[maxhodges]

so, we’re moving to Webpack, which works great with React and not Blaze

What makes Webpack incompatible with Blaze?

[ramez]

While I don’t subscribe to @velistar’s thinking and don’t find his post written in the language I am used to for Risk Management experts (too many certain messages for someone whose livelihood is in the probabilistic world), but Apollo and Meteor are indeed two separate products (albeit with upcoming tight integration).

But, I do like your sarcasm in the prior post:

Finally, a risk management expert who can reliably estimate the success of startups like MDG could make a lot of money consulting for venture capital firms and other investors.

[velistar]

Please see my edit above for further clarification.

[kani]

I am new to Meteor. This post scared me. I am confused if I should continue Meteor (ReactJS) or move to ReactJS + GraphQL + Relay.

[ignl]

Short answer I use meteor for what it was (which currently is being deprecated).
I use it because I started my project on it some time ago and I work alone on it so its productivity is great for me. Meteor stack fits my project requirements like a glove. I can still use it the same way as before and try to avoid unmaintained packages. It’s OK for now. However it’s pretty clear that I will have to rewrite it in the future so I am going to wait and see if it will be “new” meteor or something else.

[kani]

it concerned at the lack of new features coming in that build upon my existing code instead of making me refactor, and also the seeming lack of priority in improving Meteor-specific issues (i.e. build times). MDG could perhaps make some efforts to focus somewhat on existing users rather than solely finding new ones with future framework iterations.

I am sticking with Meteor because I feel like these things are probably comin

I think UserAccounts is one of the important meteor features

[mrzafod]

@kani

I think UserAccounts is one of the important meteor features

Pfffff, passport does it too and its better in some cases)

[aadams]

Brilliant post mate, the entire post.

Love this paragraph:

@a.com

(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).

I have a business to build with software that works on Meteor-classic. It’s really hard for me to attempt to rewrite my app in React/Apollo. It will cost me time and money. But I hear it will be more maintainable, more scaleable, easier to reason about. I don’t know about you-all, but I have what amounts to a large application at this point: it’s a dream to maintain and reason about. I don’t know about scaleable, I don’t think I’ve really pushed the limits, because my clients never have more than 100 concurrent users.

But at the same time, I don’t want to be stuck at version 1.2 or 1.3 forever. Yet since MDG is going to replacing Meteor-classic with the Facebook stack, an upgrade path is a path to React/Apollo, and therefore for me a path to a rewrite.

Now that the deployment story has broken down after 1.3, with mup and mupx broken for the most part, even my so far small attempts to move to the newer versions of Meteor in oder to prepare for a future React/Apollo upgrade have been stymied for now.

MDG if you’re listening, and you want legacy/classic users of Meteor to migrate to Apollo, please help fix the deployment story as mup is broken and therefore I cannot move to 1.3 (and I can’t use mupx aka docker containers because of my file system requirements).

---

UPDATE:

I got 1.3.5.1 working with meteor-up-classic. The project basically picks up where meteor-up version 0.11.3 stopped – adds support for Meteor 1.3 – and no docker!

[Ben]

reading all these kind of threads, reminds me that lately I have only one big questionmark (that feels recurring in this thread as well), which might help prevent confusion for a lot of people… it is, “what is Meteor today”. As in, what should we ‘forget’ about the past what it was and what should we know what it will be in the future.

[pal]

Perhaps much of this is legacy talk, so for those coming into Meteor now, theres not going to be much difference. Even Telescope is now a “React and Meteor app platform”. This means that your path is clearer than if you had a meteor app to maintain or now rewrite.

I also don’t understand the need for condescension towards velistar above:
-ad hominem is a logical fallacy

• it’s neither persuasive nor productive
• if his guesstimate includes FB aquihire and platform termination among ‘failure’ outcomes, it’s not so contentious. We are all aware of the stakes VC money spins on

[advany]

In was a real fan of meteor untill I found feathers.js. Finally an open source and modular alternative to meteor that builds really fast and is eazy to learn. It works on express and other popular technologies so its really nice! You should try it and maybe be saved from the meteor storm thats gonna give you a lot of headake

[captainn]

Flash, Flex, CakePHP

It’s super hard for me to say Flex is good code - it was written in AS1, ported to AS2, then badly ported to AS3 in a way that never matched any of the AS3 best practices, now it’s even cross compiled to JS - it was bloated and slow, and hard to deal with.

Flash was Okay, but had a TON of technical debt, it’s scripting engine is based on a fork of Mozilla’s Spidermonkey, a fork that Mozilla doesn’t have a hand in (because the JS community largely dumped ES4 on which AS3 is based), and as a result has none of the most important optimizations from the last few years, and so has fallen way behind the other JS engines, and was mostly private source and proprietary (much of it licensed to Adobe from obscure third party sources). I loved Flash back in the day (my name was in the Flash Pro about box as a top beta tester in one of the CS versions), and I have a lot of respect for what the engineers at Adobe tried to do, but it died for a reason.

[swiftmaster]

My opinions that choosing Javascript frameworks should be the students’ choice/preference and should be self-taught/online courses. I don’t recommend MeteorJS to be taught in schools where they can’t risk learning full stack framework when the frontend technology change year by year, will there be a new frameworks pop up?

MeteorJS is overly complicate and lack of communications was surface some time ago, indeed, without a proper working modules and plugins, it’s an expensive to maintain and time-consuming to debug problem during productions.

Why not teach FP, OO and POP using Swift 3? We have a great time communicating on the development with the Apple team and developers from all walk of life are extremely valuable and improve language clarity year by year better than sticking to Javascript.

Functional programming with Protocol Oriented Programming is a valuable and easy to master than Scala and Ruby On Rails.

Web framework similar to Laravel

vapor/vapor

Building Pokedex, it!

[swiftmaster]

Well, we know a few high profile developers never posted Adobe Flex anymore, switching to any languages that supported functional programming. This paradigm helps a lot for every projects reduce complexity. Mediator patterns in Flex is crazy complicated, that not the way developers should write.

[denodaeus]

1. In software, the ability to change, adapt and innovate is critical
2. Since the core parts of the stack apollo is designed to address are abstracted away from the meteor developer, as long as a clear migration path is provided for those who have bought in to the current ecosystem is provided – it should be a good thing*
3. I’m not excited that the view portion of the stack is so sharded – blaze is great, react is where the community wants to go, angular2 is what I want to use – But a path to getting there is not clear, as it renders a lot of the current atmosphere based packages useless
4. Javascript (the community) in of itself changes every six months, so I’m just not surprised

I’m happy that MDG is moving to the future but the communication of their endgame kinda sucks

• I put a star by this one, because I hope the MDG realizes that not a lot of “full stack” meteor developers have operations experience, so managing a graphql/relay server/stack is not easy

[dcworldwide]

I don’t think so.

The product is still improving. It is well funded and has great individuals working on it.