Meteor was/and is a fantastic community of very generous JavaScript developers. This is great news.
When it arrived and so important to me professionally. I used it to build my first web apps. I can't tell you how many times I struggled to get started with Rails, Meteor was a foothold beyond compare, they were incredibly focused on keeping the stack accessible to beginners.
They had free command line deployments – meant I could ship projects to friends, before I knew anything about hosting a web server, which was so exciting and really kept me motivated.
The way I do full-stack now, with declarative UI, apollo, Node.js – it's all pretty much the same idea as Meteor apps, just with even bigger communities that really out competed the meteor strack. You could say they're victims of JS explosion/success.
Now I have fantastic job as a full-stack dev, and I doubt I would of made it without Meteor and Discover Meteor PDF. So many cool projects like Apollo, Vue and Storybook came from people involved in the Meteor community.
There's still a huge gap in making accessible full-stack frameworks for web apps. This project is worth a look https://github.com/VulcanJS/Vulcan if you know I mean.
I'm in exactly the same position as you. I was overwhelmed with building web applications (coming from a self taught design and then web development background). I found Meteor and quickly started building increasingly complex applications (without having to learn things like webpack etc).
Now, a good few years later I'm a full stack developer with a great job building some really cool and cutting edge software. I've learned all the things that Meteor did for me, but I wouldn't have got here without it.
I really think that with the right decisions, Meteor can rise to be a top tier JS framework. Very hopeful to see where it goes.
It is part of the article but in case anyone else is mainly wondering about it:
This doesn't include Apollo (the GraphQL tools).
Seems like this is maybe Apollo "shedding" it's older, non-related parts. As a user of a technology, aquisitions usually sound like bad news, but the pitch / website of tiny (https://www.tinycapital.com) sounds refreshingly straightforward. Seems like this kind of shedding, without screwing over your users, is exactly what they focus on.
I am a part of a team that uses Meteor in production. We’ve seen that their DDP / reactivity primitives require thought and effort to scale correctly, but they definitely do scale gracefully. And having a UI automatically respond to data changes in mongo can be quite valuable for the right applications.
Like everything in engineering: trade-offs abound. With meteor and the Meteor Guide pattern book, you get a very standardized set of software modules (user authentication, roles, schema enforcement, etc) that cover the entirety of what’s required to maintain a modern, production web application, and all the modules are guaranteed to work well together. But on the flipside: there is far less to choose. It is convention over configuration, to the extreme.
There was a time in my career when I would have appreciated more configuration, but — not entirely sure why — I now get negative joy from that part of the process. For me, Meteor allows me to focus exclusively on the value producing part of the job: the app itself (vs tooling). Fingers crossed that the Tiny team keeps this great system on a path forward!
Neat, I've been following Tiny and Meteor for years and I didn't see this coming at all. My first (and one of very few) blog post was about Meteor [1]. It got a stunning number of visits (by my standards) and at the time I thought Meteor was going to have major traction if I was seeing so much traffic. In retrospect it was probably more so that I was one of few people who wrote about customizing authentication at the time, and it was something I had to do on most projects I built in Meteor. I'm guessing others did too.
I very quickly lost interest in Meteor because it seemed so efficient for very basic applications, but ridiculously inefficient for heavily custom logical and ux flows. That's usually what I needed to build. I've come to dislike intimately learning my frameworks' guts - it suggests to me they could be too complex, and there's too much potential for technical debt from working around things. I think it's important to know how your framework works, but... There are limitations to how deeply I want to know these things.
I'm curious to see where this goes, anyway. I feel like I should give Meteor another chance soon.
I still don't understand where the money exchanges hands, here. To my understanding, GraphQL is just a query specification. If the money is in hosting, and it becomes moderately successful, they risk becoming Amazon'd.
Discover Meteor was promoted by MDG because they thought it was a good resource, but it was never part of MDG itself, it was wholly independent even if one of the authors did go on to work for MDG afterwards.
I wonder what this sale means. It's MIT licensed, so they're just buying the brand name? Is a development team (mostly just benjamin newman these days) moving with it? Benjamin has been absolutely fundamental for Meteor and I think the success of this acquisition largely depends on what he will do.
Used meteor to try and build a production ready project management app in a company I was employed at years ago. We never got it off the ground and this is one of those rare times that technology was the direct reason we couldn't make the product work.
Meteor was great for quick and dirty apps but beyond that meteor never made it past the feeling that it was a prototype itself.
Everything about data management was painful the moment you started to deal with production related use cases. Unrelated changes to nested fields would propagate changes up the chain which would in turn trigger data refreshes of entire collections. And the documentation never helped here. The documentation was only about the minimum needed to perform a task, but for all their talk of opinionated frameworks, the community had to come up with their own opinions on how to actually use the framework efficiently.
Overall it was a dumpster fire but it had a positive effect on me since I was early in my career. I learnt how to better evaluate technology to actually understand whether the tools were truly production stable ready and more importantly if the documentation and community were also "production ready". So I guess I'm kind of grateful that meteor happened to me. ¯\_(ツ)_/¯
Very much agree with you on this. I picked up a live Meteor app that felt very much like it had been built as a prototype that had been built upon into a production app. It was a mess, it had clearly evolved over time and over multiple Meteor releases, there was no obvious structure at all - just felt like a bunch of files that were all loaded into some soup that became the app.
I don't think Meteor ever had decent docs on going from the prototype stage to a fully fledged application and how you'd evolve the structure over the time.
I could name a lot of problems I've had with Meteor, and I definitely agree with having a proper evaluation of tech before using it - knowing the limits of the stack you choose and if it's going to lock you in in the long term.
It's felt like a framework that hasn't been given time needed recently to keep it up to date, improving docs etc as MDG have shifted their focus on Apollo.
Meteor was restrictive and opinionated in the beginning. MDG was ambitious about how comprehensive they wanted Meteor to be and were successful at providing quick project setup, sockets out of the box, and easy mobile development for iOS and Android before Nativescript was around.
As other frameworks like React came on the scene, many developers jumped ship and left Atmosphere packages unmaintained. It felt somewhat backward and out of touch with the Javascript community. After dropping the Meteor repository Atmosphere in favor of npm, opening up to other databases than MongoDB, and adding integrations for Angular, React and Vue in lieu of Blaze, it felt reintegrated. Now it's mostly stable and configurable.
Hopefully the Tiny team can continue in this direction by bringing Meteor up to date with the current versions of node and Mongo, continuing to support the front end rendering libraries to integrate with their respective communities and improving Typescript support.
We have multiple Meteor production apps. It's by far the best developer experience I know about in the JS world. Zero config build tooling. Easy reactive queries. Saying it got steamrolled by npm, mongo and react doesn't make sense. In the end it's a node application and so you can use any npm package. It's preferred view layer is react and you kinda have to use mongo.
I guess I was referring to earlier Meteor where it used its own package manager (Atmosphere?) and front-end/templating (Blaze?) solutions. And actually that MySQL/Postgres might have been preferable to Mongo.
I love meteor for small scale project - personal / utility apps and such. I haven't found anything that compares to the efficiency of spinning up a POC app; that being said, in its current form it is horrible for making anything other than that. Real-world products need a more robust solution, and it's my experience that anything written with meteor will likely need to be re-written when it picks up traction
A few years ago, we used Meteor to prototype WorkGrades [1]. It was my first and last web app built with Meteor (mostly because it didn't seem to be catching on in the JS ecosystem, despite all of the initial hype).
No kidding! It was mind-blowing to me to be able to create realtime webapp demos w/ so little effort. Inspiring and exciting stuff. Frameworks come and go, but for many, meteor heralded the reactive paradigm in a jaw-droppingly impressive way.
Am I the only one who is starting to find this sort of company names confusing? I guessed meteor was probably meteor.js (though didn't know there was an associated comapny), but had to think pretty hard about it first. It was clearer when calling things "foo.com" or some such was in fashion, but not now. Even "Meteor, Inc." would have made it clearer, but then you have to check which legal structure a company has. There's also the question of whether such common words in such widespread use for so long can be reasonably trade-marked.
Another issue is odd spelling. Not here, but many valley companies will name themselves, say, "suni" (pronounced "sunny") because that domain name is available. Problem is, if I hear that in conversation, I will google "sunny".
The best example, of course, is the we company. Significant grammatical nail-biting ensued when I saw repeated instances of "we is". I wonder, did Adam Neumann consider that such a name change would lead to articles concerning his company sounding like gollum wrote them? Joking aside, I hope people who name such things start considering how the name will sound, write, and be perceived by most people who read it.
By “this sort of company names” do you mean using common nouns with little to no relation to the company’s line of business? If so, that’s not exactly new: Apple, Amazon, Alphabet, Intel, Oracle, etc.
The difference here is just that Meteor isn’t as popular as the above. But the above weren’t popular at their origins either (with the exception of Alphabet, perhaps).
Seems like the real issue here is that Meteor does not have instant brand name recognition... which isn’t really an issue.
Weren't Apple and Amazon usually referred to as "Apple Computers" and "Amazon.com" at some point? Also, Alphabet is definitely "new", and someone else already pointed out the origin of "Intel"
EDIT: Wikipedia confirms Apple originally being in corporated as Apple Computer, Inc. and Amazon as Amazon.com, Inc.
Since it's sparked some conversation, I have a foggy recollection of reading somewhere that Paul Graham originally recommended that Meteor be called "Octograph" or something along that line.
Maybe one of the founders can chime in on this bit of trivia. Congrats to the whole team!
I'm not sure if this really warrants a reply, but I did want to correct the record. Even if you think Meteor "crashed and burned", it was definitely not a flash in the pan. It was launched in 2012 and seven years later there's still a small but active community. Many successful companies have used Meteor at some point, and many still do.
I think that the fact you think it was a "framework du jour" just highlights how much potential –and yes, hype– it had in its heyday. It may not quite have lived up to that hype, but it certainly accomplished more than the vast majority of web frameworks.
Maybe you could try giving arguments. Their tracker reactivity system is much like what react hooks now is. They had zero config build tool, much like what parcel now tries to be. They had a package system that because of it's SAT solver is way better for frontend code, something that took NPM years (and still isn't great). It's still the most convenient way to have a type of reactive queries I knoe about... And all of they basically already had in 2011 and all changes thry introduced since then were mostly backwards compatible.
Any technology that had success like Meteor cannot, in good faith, be called bad. All technology have their pros and cons, and Meteor was the appropriate choice in a number of ways, especially a few years ago.
Hey, I've been competing against Meteor for years now (http://gun.eco), is this good or bad news for me? Is Meteor going into maintenance mode / shut down or will Tiny continue to expand its feature set?
It's in the first sentence of the article: "Canadian technology holding company Tiny, home to companies like Dribble, Flow and Unicorn Hunt, today announced that it has acquired Meteor, the JavaScript-centric open-source app platform."
When it arrived and so important to me professionally. I used it to build my first web apps. I can't tell you how many times I struggled to get started with Rails, Meteor was a foothold beyond compare, they were incredibly focused on keeping the stack accessible to beginners.
They had free command line deployments – meant I could ship projects to friends, before I knew anything about hosting a web server, which was so exciting and really kept me motivated.
The way I do full-stack now, with declarative UI, apollo, Node.js – it's all pretty much the same idea as Meteor apps, just with even bigger communities that really out competed the meteor strack. You could say they're victims of JS explosion/success.
Now I have fantastic job as a full-stack dev, and I doubt I would of made it without Meteor and Discover Meteor PDF. So many cool projects like Apollo, Vue and Storybook came from people involved in the Meteor community.
There's still a huge gap in making accessible full-stack frameworks for web apps. This project is worth a look https://github.com/VulcanJS/Vulcan if you know I mean.