Tiny Acquires Meteor
techcrunch.com
techcrunch.com
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.
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.
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.
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!
Wekan, a self-hosted kanban board similar to Trello: https://github.com/wekan/wekan
Rocket.Chat, a team chat platform similar to Slack: https://github.com/RocketChat/Rocket.Chat
These two applications made good use of Meteor's reactive capabilities.
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.
1. http://steve-adams.me/practical-examples-of-authentication-i...
Source: I wrote that book.
Edit: Looks like it's called Graph Manager now: https://www.apollographql.com/docs/graph-manager/
I guess some people pay the $49/mo?
I like to be more thoughtful about my QPS and payload sizes.
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. ¯\_(ツ)_/¯
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.
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.
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.
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.
EDIT: Wikipedia confirms Apple originally being in corporated as Apple Computer, Inc. and Amazon as Amazon.com, Inc.
Can common words in widespread use be trade-marked? Yes, but it can be annoying sometimes (see for example the legal troubles Apple encountered).
Maybe one of the founders can chime in on this bit of trivia. Congrats to the whole team!
the suggestion was “orthocode”.