Why worry? Does it solve your problem today? Don't fall into the same trap that so many people fall into who worry far too much about how popular the tools they use today will be 3 years from now. Focus on what makes you productive now. Your startup has a far greater chance of failing than Meteor.
Understandable-- but if you are productive on Meteor today, or you and your team have already committed to learning about it, I would suggest that you should see that through. This kind of uncertainty/doubt around open source frameworks is par for the course, unfortunately, and I think it would be a real shame to stop before you've at least built a prototype with the technology you've already invested time with (particularly since so much of a v1 is figuring out the interface/interaction design anyways, y'know?) Just my 2¢.
I work for a startup that has grown our team and product over the past two years, building a major application on Meteor. It's been great seeing the platform grow, and we've been able to benefit from many of Meteor's components from the very beginning. We can add new features very quickly because of the base Meteor provides.
If Meteor is a fit for your project, definitely use it. Real-time, isomorphism, and more can be of big benefits to rapid development.
The big mistake was trying to provide anything beyond Minimongo on the client side. People are very picky about what front-end frameworks they use on the front end, and typically people who have strong opinions about that are less opinionated about what they use on the back end. I'm firmly in that camp, for instance. I've been a huge fan of Firebase for a while because it frees me from the tedium of having to create another REST application just to talk to a database. If Meteor had, from the beginning, focused on simply being a kick-ass open-source alternative to Firebase they would be killing it right now.
It was a monumental task to try to create something that would please both front-end and back-end web engineers. Another issue with Meteor is that it was envisioned, not extracted. [1] From Rail's creator, DHH: "First, Rails is not my job. I don't want it to be my job. The best frameworks are in my opinion extracted, not envisioned. And the best way to extract is first to actually do."
Meteor was the goal, not an actual, real-world application. Often when this is the case the software ends up solving a bunch of problems that seem logical to solve, but in practice are not actually practical (another framework like this that comes to mind is the notorious famo.us project). Compare this to Rails and React which were forged in the crucible of real, day-to-day development and problem solving.
Let's avoid turning this into a "Meteor is doomed" or "Meteor failed" comment thread; Meteor is and has been growing consistently since it launched (see: https://twitter.com/Rahul/status/673992512768507905). The title of Sacha's post reads a bit inflammatory, suggesting something "went" wrong and that it's too late now. Rather, as his post explains, the community is currently in a bit of an identity crisis as two groups with disparate sets of opinions on where Meteor should go from here collide.
As someone who's been building with Meteor since 2012, I see all of this as a good thing. It's a sign more and more people are lending their voices and opinions to Meteor's direction. As NPM support arrives with 1.3, and as a more agnostic approach to view frameworks becomes part of core, we'll continue to see more people join, because the platform will be more open towards them.
Meteor was a new platform. It's now a mature, growing platform. And it will be a successful platform if we all keep contributing.
The post's title is "What Went Wrong". What kind of comments were you expecting here? Running an OSS project is no different than running a startup in a lot of respects – marketing and PR matters. It's great to write candid posts like this, but you can't jump into other forums where the post has been linked and try to manage the conversation after the cat's out of the bag. It ends up sounding like damage control.
Instead, you should welcome further observations about some of the perceived mistakes the Meteor team made and point out specific examples where they're being addressed.
About the tweet: It's not a graph, rather some neat bars, until it has some numbers. It is suggested that it shows relative growth, make it relative to point zero and you get undefined-ly long bars, or compress it to make it look like the product is stagnating: http://i.imgur.com/TOBLaSa.png
Also, consistent growth isn't really enough, usually, to capture a market and exponential growth is usually expected from startups.
This seems to be the same issue with other frameworks when they get to a point where they have enough adaptation and find out they need to change/update parts of their framework to get it to the next level.
Same thing is happening right now with AngularJS. Been around for a while, had massive adaptation, then they realized they needed to make major changes. Enter pivot to 2.0 which pissed a lot of people off, but the heat is dying down now and people are coming to their senses.
I'm pretty sure at some point React and other frameworks will hit their wall too.
Rails didn't hit that wall. Neither will Ember. FYI Ember is introducing new ideas by the second (pods, composable components, components over controllers, DDAU, etc) but the community eagerly awaits and embraces them. I don't know why that is.
This is really a fantastic point. It's sometimes as if people think these type of projects exist in isolation and any perceived flaws are permanent. They often fail to appreciate how much the flaws will invoke a response to address them, making them better than they would have been had the flaws never been strongly felt by the community in the first place.
> Another issue with Meteor is that it was envisioned, not extracted.
This has been the Achilles heel, in my opinion.
On what might be the bright side, this sort of thing is starting to happen, albeit from the outside (e.g. not from Meteor, but from a company who hitched their wagon to Meteor):
> First, Rails is not my job. I don't want it to be my job. The best frameworks are in my opinion extracted, not envisioned. And the best way to extract is first to actually do.
You are slightly wrong in your history of Meteor. It was extract from an app they built. Unlike Basecamp or Facebook, the app died off and they focused on just building the framework. So while it was extracted, I think MDG has missed a lot of the learnings that something like Rails gets from core contributors that are building applications and the framework together.
MDG has actually talked about taking one week twice a year to build 'apps' with the framework, but that just hasn't been enough. I am glad they are finally working with Meteor itself to build Galaxy and supporting Galaxy customers as well, that really gets some skin back in the game.
Imo, this post is just a manifestation of the deeper issue around profitability and the fact that MDG will need to jettison some of it's development costs and pick up a much larger base of customers if they want to be profitable.
Which PaaS also builds it's own programming framework...
Personally, the one thing I don't like about Meteor is that it insist on using MongoDb. That along makes me NOT want to use it, despite other cool features.
The thing which prevented me to use meteor for big projects is it looks really monolithic from the outside.
What happens if suddenly I want to rewrite part of the back-end or part of the front-end with something else for various reasons ? What happens if I want to switch from MongoDb to RethinkDb or Postgres for some reason ? It's good to have default choices but it looks from the outside that the default choices with meteor are pretty fixed.
But maybe I'm wrong, that's just how it looks like from the outside.
I think the big problem with isomorphism is that there's a fundamental disconnect between the lifetimes of front and back end systems. Well written back end code (hell, badly written back end code) could be left running for decades with better front ends bolted on. A front end system written even a couple of years ago starts to be less maintainable as developer skill sets move on, best practice evolves etc.
I think it's interesting to consider the reasons why that is. Why are backends typically slowly upgraded while maintaining a compatible API, while front-ends undergo big re-designs and re-writes from scratch just about every year? At commercial, successful startups?
One obvious reason is that the appearance of looking "modern" and "up-to-date" is a strong signal of vitality for many consumers, and this is awfully similar to the yearly fashion cycle. But are there other reasons?
Front-end systems have more room for creative expression, drawing in more of those who want to express themselves with a major overhaul. Furthermore, the base skills of front-end developers are more of "understanding how humans interact with user interfaces" and managing complex state. Back-end developers tend to need more understanding of the problem domain and communication skills, so the developers that do better at back-end work tend to build things that need less updating.
Basically, I'm asserting that front-end and back-end work attracts different kinds of developers. Back-end developers are less likely to write things that need replacing, and front-end developers are more likely to want to replace things.
If you've got a working model (and system) for Users, Widgets, Gizmos and Sprockets, then there's little reason to change.
New client devices come and go though, and users expectations of a good interaction experience change, and once your backend is solid you can quickly throw a new skin over it and view/interact with it in a new way.
> What happens if I want to switch from MongoDb to.. Postgres.. The default choices with meteor are pretty fixed
This is exactly the reason I'm not using meteor - and it's not so much wanting the ability to switch backends as knowing in advance I want to use an SQL database like Postgres, and not Mongo. With meteor, it's Mongo or nothing.
I believe SQL integration is on their roadmap, but I think now it's too late.
You can in fact use React as the view layer with meteor, so for an app using React, the remaining killer feature of meteor 6 months ago was optimistic updates, with database sync all handled. But, there was still the hard limitation that you must use it with Mongo, which simply made it a no go. I commented about this here, a couple of times, and others did too. I even asked a few months ago if there was a library that just provided the optimistic updates feature. Well, now there is one that looks promising, though it's still early days and I've not used it yet - Facebook's Relay - with complete React integration, caching, request management and optimisation, and yes, optimistic updates and sync. The difference though, is that it talks to a graphql server, which can be written over any database at all - with Relay the frontend is entirely agnostic about the database used, by design, because it talks to it through a middle tier. There's no reason for me to wait for meteor to implement SQL integration any more, because now another solution has come along.
I still don't understand why meteor made the choice of a hard dependency on Mongo if they ever wanted to become mainstream. Had they not, it's very likely that many developers, myself included, would have picked up meteor over the past year and would be hooked on it. Now though, that train is rapidly leaving the station, at least for devs on the React stack. I think they missed their window.
Query subscription is the reason. You can add a monitor to the equivalent of "select * from docs" in mongodb and get notified by the db when a docs row is inserted. Some RDBMS:es can solve the same task ad-hoc using triggers, but it is not the same and is much more resource intensive. That makes it hard to achieve Meteor's goal of "any data change is immediately reflected in all clients" with any db other than mongodb.
Then Meteor does not meet your use case. Some people actually like opinionated, monolithic frameworks because it reduces decision fatigue and boilerplate coding. For small teams with outsized requirements, it's a perfect fit. I've built a couple (internal) apps with Meteor and got a tremendous amount done in a short time.
Maybe someday I will need to replace 'x' with 'y' and have a hard time (or maybe not), but the time savings earned now are worth the technical debt that I might face in the future.
> but the time savings now are worth the technical debt that I might face in the future
Oh, man that statement makes me cringe. Have you ever replaced a piece of proprietary technology with a different one before? I promise you, you will consider this decision up front much more closely next time.
Yes. I'm replacing a legacy PHP app with Meteor right now. However, instead of building a huge, monolithic app, I'm replacing sections of it piecemeal with small Meteor apps that use npm modules (or meteor packages) for shared functionality. So if one app doesn't work out, then yes, it'll be more work to replace it with some new fancy future thing, but hopefully it'll have paid for itself by then.
Most apps that become successful have to be rewritten multiple times as they grow. One of Jeff Dean's rules of thumb [1, p. 11] is that a system will generally need to be completely rewritten every 1-2 orders of magnitude growth.
Yes, this sucks, as anyone who's gone through a rewrite can tell you. But the broader perspective is that this is what software engineers are paid for. If you could just build a system and let it grow with minimal tweaks, the only people the software industry would employ would be technical founders.
Your rewrite doesn't need to be on a completely new platform or language, and depending on the use case you'd still benefit greatly from using some of the original functionality of the current code base to do things until you're in a position to replace them.
In my experience, you often iterate towards a replacement instead of pulling the rug out from the current platform and replacing it with another. This isn't always true, but in the case of CRUD based web apps, it's a lot smoother in my experience.
Agreed, but the first step in a major rewrite that's necessary because the product has outgrown its original purpose is to draw up appropriate system boundaries. These could be in-process libraries, webservices, RPCs, data protocols, database schemas, or whatever, but if they're out-of-process, there's nothing preventing you from using a different language or platform to rewrite that subsystem. You can decide to continue using the original proprietary platform based on whether it's still appropriate for your needs, and you're not locked into it just because all the existing code is in it.
It's easier to rewrite something than it is to produce an MVP that consumers and investors want to buy into. I'm 150% into the anti-monolith approach for serious scale, but meteor is like Rails in the respect that small teams can accomplish rapid prototyping and fast iterations early on.
Yup. When I was researching front-end / back-end stuff three years ago for the project I'm still working on, meteor was on the list. It's neat for sure, but I didn't want to be stuck with mongo as a forever thing.
I ended up in a more fragmented place - node on the back-end with a lot of libraries (hapi.js, knex.js as two major ones) and angular plus a lot of extra code on the front. On the plus side, everything in my project works well, smoothly and exactly how I want it to work. Plus: referential integrity in the data model, since it's postgres back there. I even get live updates from the server to the frontend using postgres listen/notify and websockets. It took more time getting there, but ultimately I'm one of those Other kinds of devs - I don't want one big opinionated framework, I want a lot of littler pluggable bits.
But that's okay, there's room in the world for both.
In my experience, the best part of Meteor is its tightly couple stack so that I can developer very smoothly. But the worst part is also its tightly couple stack when my web/app grows. Really hope that it would be easier to decouple some important package like tracker or minimongo
I tried out Meteor this past spring. I started with a simple Trello clone, which I got working in a couple hours, including learning time. It was good enough at that point that my brother started using it at work. I was pretty impressed.
So I got to work on some more advanced features I'd been thinking about. And at some point, Meteor started throwing an error from somewhere in its innards, and for the life of me I couldn't figure it out. Some kind of problem mapping data to UI, I don't remember the exact message.
I decided I needed to know the guts of Meteor to be able to debug problems like this, and put the whole project aside to wait for the Meteor in Action book. But now I'm onto other things.
Another place I'd love to see Meteor move towards the (future) standards would be an eventual replacement of Fibers with async/await throughout, which to me is more explicit and intuitive.
> Meteor has yet to establish itself as a mainstream development technology on the same level as Rails or even vanilla Node.js... almost four years after Meteor first launched, I have to admit I thought the framework would be more widespread by now. So what happened?
A more general answer, I feel like the web programming world doesn't really need new frameworks, does it? Rails or Django got mainstream adoption because there was a need at the time, likewise with frontend JS frameworks (which seems to be consolidating around just 2 - React and Angular), and likewise with Node as filling a need for easy async. I'm not that knowledgeable on Meteor [1], however I think by default it's reasonable to expect no new frameworks to have mainstream adoption without a major change to the web.
[1] I don't know if Meteor's x-platform appeal is enough to convert users from other x-platform, native and/or hybrid solutions (Ionic, Titanium, RubyMotion, etc.).
jQuery is not a framework, though (neither is react but people usually mean using it with a flux or flux-like library, like baobab, when they say react. jQuery has no such go-to companion).
I believe this is correct to the point where jQuery is synonymous with javascript and thus doesn't need to be even mentioned. Plus jQuery isn't really a framework.
I strongly disagree, there are many people (myself included) who strongly discourage the use of jQuery. There are much better solutions out there that follow the "do one thing well" philosophy.
I'm far from being an Ember-fan, but it's still going well too, even if it doesn't have as much hype as the two poster boys.
As for Angular, I feel like it's still too early to tell how it will end up - I loved Angular 1.X but eventually switched to React because it was much more convenient and only required minimal boilerplate. Angular 2 doesn't really make we want to switch back in its current state.
>I feel like the web programming world doesn't really need new frameworks, does it? Rails or Django got mainstream adoption because there was a need at the time
Of course we do. Those frameworks appeared because what was available at the time wasn't perfect. Rails/ Django addressed a number of pain points and made more rapid development possible. But development still takes time and creates bugs, so there's still room to improve.
Plus coders are always going to reinvent the wheel, so frameworks will continue to appear.
The startup I'm with right now just finished a meteor/react project that I led. This article really touched on our major pain-point with the learning cliff that you hit after a certain point. We used FlowRouter since it has React support, but managing subscriptions correctly (let alone caching them) took way more time than we had anticipated. It wasn't until near the end of the project that we realized none of us actually had a total mastery of what was going on under the hood in meteor, which was a terrifying realization. All things considered, though, I think our biggest mistake was biting off more than we could chew in using React and Meteor, when we had never made an app using either before. On the other hand, blaze is pretty rough...
> I think our biggest mistake was biting off more than we could chew in using React and Meteor, when we had never made an app using either before.
I see people make this mistake over and over again. It's so easy to underestimate the cost of learning something new. Often times it's best to just go with what you already know until you've done enough non-mission critical in the shiny new thing to be confident in it.
It's really not very rich and up-to-date, in my opinion. In my experience, the vast majority of oss PHP projects started a decade ago, and they all keep certain back-compat, so they run with the drag of old paradigms. Actual new contribution to the ecosystem seems almost impossible to find, and there's a lot of areas that simply aren't great.
E.g try to find a sane way to work with PostgreSQL json,jsonb columns in a safe way in php. There's no even halfway decent solution. Half-supported, roll-your-own in doctrine is the best you can get
> It's really not very rich and up-to-date, in my opinion. In my experience, the vast majority of oss PHP projects started a decade ago, and they all keep certain back-compat, so they run with the drag of old paradigms. Actual new contribution to the ecosystem seems almost impossible to find, and there's a lot of areas that simply aren't great.
So why did you pick a tech stack for this project, given that you had not used it before, sounds like no-one in your team had either, nor is this stack widely used (afaik)?
It seemed to fit our use-case really well. The CTO and I did a Meteor hackathon to get a feel for the tech, and thought that it would be a lay-up. Alas, it was quite an error.
It's good to realize the mistake here, so good job. Never jump on the new thing. Always lean toward the simple thing. Always prefer tools closer to your core competencies. Meteor is really fun to play with and the community is very good, but Meteor creates complexity over time.
It's also worth mentioning that unless you have a real-time app whose data model fits nicely with schema-less document storage, Meteor is almost never the right tool for the job. And even if your project has those requirements, there are plenty of high-quality alternatives to Meteor.
I've experienced this pain point (exceedingly complex systems) over and over again, and it's something I'm pretty passionate about. There's a lot of experimentation in JavaScriptLand that involves doing something cool or novel while totally forgetting about managing complexity. This is exactly why I built Nodal [1], I just wanted a fast, easy solution to build API servers.
We're a new thing, but the focus is on simplicity and how easy the system is to grok. The goal is to reduce complexity via separation of concerns as related to systems, not just programming modules (actually, Nodal itself is opinionated and some parts are tightly coupled. The argument there is consistency within the service to keep it easy to reason about. There's no DSL outside of the ORM, which reads like Django's. Just ES6 JavaScript.) We're not trying to compete in the space of "real-time apps" at all, because microservice architectures are tried, tested, and much easier to reason about (at the expense of having separate codebases - which I actually view as a positive).
I did a write-up about it this week [2] and we're focused on trying to tackle pain points re: web app complexity as best we can.
>Always prefer tools closer to your core competencies.
This is basically the reasoning behind my recent choice to not use an API documentation framework. Our application framework already has the ability to introspect and render templates, so there's minimal advantage in adding yet more tooling surface area.
> Never jump on the new thing. Always lean toward the simple thing. Always prefer tools closer to your core competencies.
This is correct, but it is also a balancing act. Sometimes the new thing is better. Sometimes it is simpler in important ways that provide leverage in the long run, despite being complex in other ways that create confusion in the present. Sometimes you need to learn new tools and shift your core competencies toward them.
An analogy: Nobody writes directly in machine code anymore. Symbolic assemblers were new technology that was better. The early ones may have been buggy, and it may have been simpler to just write it by hand instead of debugging your own code and the assembler, but eventually it paid off. Your core competency may have been writing machine code, but once the assemblers became good enough, it made more sense to be competent at using them.
Very few new technologies represent such a massive and obvious level-up as that, and it is unwise to chase everything in hopes that it will be one of those paradigm-shifters, but it is equally unwise to hide your head in the sand, believing that all new things are necessarily complex and unworthy.
I have been, and remain, skeptical of Meteor itself, but the problems it is targeting are real, and I think it and other projects are circling in on good approaches to solving them, which is worth paying attention to.
> Never jump on the new thing. Always lean toward the simple thing. Always prefer tools closer to your core competencies.
You can attack this problem from different angles. You can either refrain from using new tools OR you can widen your core competencies.
I work ~30h a week. The next 50h I spend doing my hobby thing, which is learning and using new - and old, as there are many forgotten tools which give you an edge over whatever is considered mainstream - tools in various areas. I'm a pathological case of a generalist, but even I have one or two things I specialize in.
Now, I did this for the last 10 years. The ratio of work vs. tech exploration was not always that favourable, but I kept doing this basically throughout the last decade. What I ended with is a skill that lets me very easily learn, understand and modify or fix new tools, be it languages, frameworks or libraries (among other things, ofc). So, in principle, I should have a vast choice of tools accessible to me.
But it doesn't work at all, because even if my project is currently being written by me only, it will be maintained by some other person in the future. And that person is almost guaranteed not to know any of the tools I decided to use, despite them being the best tools for the job.
Well, it looks like I'm just venting my frustration here, so please don't mind me. :)
Meteor has been perfect for the single page web apps I've been making as side projects. I don't know any other frameworks where I could have completed an encrypted chat application as fast and painless as I did with meteor.
All the things mentioned as "going beyond basics" seem like things that meteor was never designed for and that we have other tools to handle.
I really feel like the problem is with the people behind meteor trying to make it THE framework, instead of just being a framework that excels at a single purpose.
I was turned off to Meteor when one of the initial releases was touting being able to use the browser console as a Mongo shell. Never took it seriously since.
The intended use doesn't matter. That's a huge potential exploit. I would never deploy an application based on a framework where database access from the browser is baked in.
Database access from the browser is not baked in. This is a misunderstanding. Meteor has a browser cache that mimics a subset of Mongo commands, and auto-syncs with the back-end based on security rules you define.
Seems like a good analysis of Meteor's shortcomings.
I did some research on related areas a few months ago.
My ideal stack at the moment would involve:
* redux or cerebral with immutable model
* react
* css modules
* webpack
* a realtime-enabled version of falcor, which doesn't exist yet.
The last bit is still the missing piece for realtime, as far as i'm aware. Neither GraphQL not Falcor seem to been designed with realtime model updates (via websocket) in mind.
Aside from Falcor, this is exactly my current stack and my preferred as well. React + Redux + Webpack + Immutablejs + Bootstrap/Less. I'd be interested to hear your thoughts on Falcor or Relay/GraphQL and see what it can offer. For my backend I run some minimal node webservices. I've recently started making all my stuff "pre-rendered" by statically generating my files (react renderToString -> Mustache -> create a file) , with all my needed data in a json file, and only access the webservices when absolutely needed.
Have you tried Elm? I always found the default mutability of JavaScript to be somewhat hostile to immutable data structures. Elm is very different - but feels very integrated and the functional nature of the language really makes a lot of things simple and easy to debug/test, while being able to still do react-style dom diffing.
I did a little project with meteor in its early (pre 0.5) days. At some point internal errors I could not understand started cropping up. Nobody in the community at the time could help. In the end I wrote the app in go and angular. The idea of meteor seemed nice at the time but in practice it wasn't fun. The all in approach means you should also understand what goes on under the hood because when the engine fails and nobody knows why, you are stuck.
I like Meteor and am using it for my current project, but I architected it in a way to stay away from their pub/sub model where you publish partial data sets to the client. I believe this only has utility where you have a feed of data that you want to filter or sort on a lot of different attributes.
Instead, I just utilize `Meteor.Methods` for all client/server interaction. I actually think it's pretty nice because you define the method on the client as a "stub" that gets called as it waits on the server response. I think the tutorials and guides focus too heavily on their fancy client/server mongo magic.
Though something that is a bit frustrating reading this is that I left React. I found it overly-complicated for my product and preferred architecting everything in terms of templates. Blaze is threatened by React? How? I like React, but I can't exactly get behind writing HTML components in javascript because whoa man, a diff engine & "look ma! I'm being functional!" I realize the benefits of uni-directional flow, but all it really did was add a lot more conceptual weight to a pretty simple interface.
So I said, this is pointless let's just simplify things with Meteor + Blaze. Now Meteor says, it's "threatened" by React?
I built an app with Meteor right around when 1.0 was released. The absolute worst part for me was attempting to shim what should have been a relational database design into the default NOSQL mongoDb (you pretty much had no choice).
Anything that implies the lock-up unless everything is rewritten completely is not a viable choice for me.
I'm wary of anything (especially JavaScript as trends change there faster than one can read the articles) no matter how praised it is. Sometimes things just do break in the most bizarre manner when you already have everything set up. If components are modular enough, you can swap them, or at least patch a completely new piece over the old one, to handle the problematic cases.
When I once had to replace a very old legacy system (non-web, but it still holds) I've just slapped a dummy do-nothing proxy-like system in the front and gradually did stuff piece-by-piece. Then threw out the old garbage when it wasn't doing anything anymore.
But from what little I understood about Meteor from the tutorials and examples, there's one single giant system, that you either use or don't. This means, if one hits some bug or - worse - architectural limitation, they're going to have really tough time.
'All happy families are alike; each unhappy family is unhappy in its own way.' -Tolstoy
It seems that many people are unhappy with Meteor in its own way. It takes 375 factors to make a 'Rails' and Meteor has 370 for each person, but each person is missing a different five.
Give me a box of boards and nails any day. All my ikea furniture is rickety and much of it is starting to look dated.
I just spent a good amount of time over the last few months building a prototype for an application in Meteor and it has been a joy.
Out of the box I got happy, grokable app/server communication, I got sane user account tools and I got a build process that works well enough that I haven't thought about it at all. I almost never need to look at documentation, I just build features. I've only needed a few community packages, and the ones I have used have been working pretty well for me.
I feel like I've been living the dream. So much ceremony and overhead just melted away.
I'd be curious to hear what kind of issues people have hit with blaze/meteor package management/etc that make them want to swap in react/npm/etc. (I spent the better part of 2015 with react/flux and it would take a lot to get me to switch back).
> Give me a box of boards and nails any day. All my ikea furniture is rickety and much of it is starting to look dated.
This seems to contradict the rest of your post where you go on to talk up the plug and playness of meteor. That's much more like ikea furniture than a board and nails. The board and nails approach requires you to do all the planning that meteor gives you out of the box.
I guess I think those things to be the building materials, and folder structure/routing/etc to be the stuff I don't mind making my self. I get how this might be opposite for others though.
Meteor is different. It's been over 4 years. It's not going anywhere. It has more stars on GitHub than Rails.
If you haven't looked into it, and you're in a remotely adjacent field, you're behind. Even if you don't decide to use it. The ideas underpinning the framework are very progressive and sure to continue in some form even if Meteor itself ultimately doesn't.
With all that said, I think Meteor is simply going through some growing pains. Given how ambitious its vision is, it simply can't avoid them. I look forward to Sacha's next, hopefully more optimistic, post!
I'd disagree--a lot of the JS folks I've met are like magpies and will star anything that looks remotely interesting on Github. It is exactly chasing shiny.
I normally treat stars as a bookmark, rather than as a declaration that I believe this is High Quality Work. Rather it's more along the lines of "I want to be able to find this easily at home when I have spare time next week".
There are too many JS frameworks/platforms/libraries to keep up with. I can't spend my time investigating them all. I've heard of Meteor several times but in my mind it was associated with (a) real-time apps, and (b) not free. I'm guessing that was because it is the free alternative to a paid thing? Anyway, that's what stuck in my head so I've ignored this one.
Is looking at GitHub stars a recommended way to find the best frameworks? Or what would you suggest for that?
I recently started looking at Nodal since it was mentioned here on HN a couple weeks ago. It looks pretty cool at first glance but I haven't tried building anything with it yet. (I don't have infinite time.)
I remember when there was Prototype.js vs jQuery vs Yahoo's library vs MooTools vs fill-in-the-blank. I only switched to jQuery when virtually everyone else had. Until then I stuck with Prototype because its the one I already knew (because I tried it first), even though I had played with jQuery a little bit.
So, again I say there are just too many frameworks to keep up with. (And ask if anyone has a good site / method for dealing with this.)
There's nothing (I know of) with a more radical approach to the full-stack web than Meteor.
No one's saying you need to keep up with all the JS frameworks, but if I were hiring a JS dev, I'd expect the person to understand the pros and cons of the most important ones. Meteor is categorically one of the most important JS frameworks out there.
I'm not sure about a way to determine the "best" or "most important" frameworks. Perhaps number of appearance on the HN front page could be a heuristic?
"Not free" is not quite right. The software is open-source & MIT licensed. The entity is for-profit, as it intends to sell services adjacent to the software, not unlike Acquia & Drupal.
I can sympathize greatly. I played around a bit creating an isomorphic "framework for frameworks" to explore some techniques I didn't get to use in my day-to-day. There is a constant tension between leaky abstractions and expressing functionality meant to run in very different environments that I personally am taking years to fully grok [0]. Of course, unlike the meteor folks, I'm doing it for fun, so there is no pressure to make any money doing it on my end.
[0] for instance, I made it trivial to invoke client functions asynchronously from server code using normal call syntax. Now how to deal with timeouts? The syntax doesn't permit much without leaking, destroying the original point.
Off topic but is there a reason I keep seeing this word 'grok' used all over HN? Just say 'understand' unless there's a reason to sound like you have aspergers.
And 'fully grok' is redundant anyhow - grok implies a full and deep low level understanding with no lapses, you cannot partially grok something. It's dissapointing to see uncommon words used in poor ways, I'm seeing this word misused all over HN as if its now a cult jargon.
"Grok" in is original use is something more like a deep and complete understanding. Here is Heinlein's explanation from "Stranger in a Strange Land":
"Grok means to understand so thoroughly that the observer becomes a part of the observed—to merge, blend, intermarry, lose identity in group experience. It means almost everything that we mean by religion, philosophy, and science—and it means as little to us (because of our Earthling assumptions) as color means to a blind man."
But 'grok' is supposed to mean something more like understand various arbitrary things at a low and intimate level, not at a high level.
The more correct way to say "fully grok" would be "grok in fullness," anyhow. It is possible to grok but not in fullness; Valentine Michael Smith said this once in the book ("I grok but not in fullness").
I'd say it's been live jargon ever since Stranger came out, jumping from SF to the tech world as things often do, and I'm pleased to see it survive despite the modern distaste for Heinlein in many (but not all) SF circles.
It took me a long time to realize this and in some ways I'm still realizing it.
"Isomorphic" or "Universal" are fancy terms for dual execution. Your code is run on the client and server. It has technically been possible ever since Node came out, but the problem is that client-side and server-side code interact with different APIs and carry out different tasks with them. The inputs and outputs are different so the code ends up different, even if written in the same language and even with the same design patterns.
TL;DR: JS on Client + JS on server != JS everywhere.
188 comments
[ 3.0 ms ] story [ 255 ms ] thread1. https://kadirahq.github.io/mantra/ 2. http://guide.meteor.com/
If Meteor is a fit for your project, definitely use it. Real-time, isomorphism, and more can be of big benefits to rapid development.
It was a monumental task to try to create something that would please both front-end and back-end web engineers. Another issue with Meteor is that it was envisioned, not extracted. [1] From Rail's creator, DHH: "First, Rails is not my job. I don't want it to be my job. The best frameworks are in my opinion extracted, not envisioned. And the best way to extract is first to actually do."
Meteor was the goal, not an actual, real-world application. Often when this is the case the software ends up solving a bunch of problems that seem logical to solve, but in practice are not actually practical (another framework like this that comes to mind is the notorious famo.us project). Compare this to Rails and React which were forged in the crucible of real, day-to-day development and problem solving.
[1] - http://david.heinemeierhansson.com/posts/6-why-theres-no-rai...
As someone who's been building with Meteor since 2012, I see all of this as a good thing. It's a sign more and more people are lending their voices and opinions to Meteor's direction. As NPM support arrives with 1.3, and as a more agnostic approach to view frameworks becomes part of core, we'll continue to see more people join, because the platform will be more open towards them.
Meteor was a new platform. It's now a mature, growing platform. And it will be a successful platform if we all keep contributing.
Instead, you should welcome further observations about some of the perceived mistakes the Meteor team made and point out specific examples where they're being addressed.
Also, consistent growth isn't really enough, usually, to capture a market and exponential growth is usually expected from startups.
This seems to be the same issue with other frameworks when they get to a point where they have enough adaptation and find out they need to change/update parts of their framework to get it to the next level.
Same thing is happening right now with AngularJS. Been around for a while, had massive adaptation, then they realized they needed to make major changes. Enter pivot to 2.0 which pissed a lot of people off, but the heat is dying down now and people are coming to their senses.
I'm pretty sure at some point React and other frameworks will hit their wall too.
Similarly Node forked into io.js then later back into Node 4.
This has been the Achilles heel, in my opinion.
On what might be the bright side, this sort of thing is starting to happen, albeit from the outside (e.g. not from Meteor, but from a company who hitched their wagon to Meteor):
https://kadirahq.github.io/mantra/
This is great, but the envision/extraction disconnect persists within Meteor itself, where it matters most.
You are slightly wrong in your history of Meteor. It was extract from an app they built. Unlike Basecamp or Facebook, the app died off and they focused on just building the framework. So while it was extracted, I think MDG has missed a lot of the learnings that something like Rails gets from core contributors that are building applications and the framework together.
MDG has actually talked about taking one week twice a year to build 'apps' with the framework, but that just hasn't been enough. I am glad they are finally working with Meteor itself to build Galaxy and supporting Galaxy customers as well, that really gets some skin back in the game.
Imo, this post is just a manifestation of the deeper issue around profitability and the fact that MDG will need to jettison some of it's development costs and pick up a much larger base of customers if they want to be profitable.
Which PaaS also builds it's own programming framework...
What happens if suddenly I want to rewrite part of the back-end or part of the front-end with something else for various reasons ? What happens if I want to switch from MongoDb to RethinkDb or Postgres for some reason ? It's good to have default choices but it looks from the outside that the default choices with meteor are pretty fixed.
But maybe I'm wrong, that's just how it looks like from the outside.
Welding the frontend to the backend is a definite no-go for me, regardless of the supposed benefits of this isomorphism.
One obvious reason is that the appearance of looking "modern" and "up-to-date" is a strong signal of vitality for many consumers, and this is awfully similar to the yearly fashion cycle. But are there other reasons?
Basically, I'm asserting that front-end and back-end work attracts different kinds of developers. Back-end developers are less likely to write things that need replacing, and front-end developers are more likely to want to replace things.
If you've got a working model (and system) for Users, Widgets, Gizmos and Sprockets, then there's little reason to change.
New client devices come and go though, and users expectations of a good interaction experience change, and once your backend is solid you can quickly throw a new skin over it and view/interact with it in a new way.
The issue that you raise is less important with meteor because updating the server code updates the client code.
Which is likely what is happening right now to detriment to all those that have already adopted meteor. But you sort of have to need to do this.
This is exactly the reason I'm not using meteor - and it's not so much wanting the ability to switch backends as knowing in advance I want to use an SQL database like Postgres, and not Mongo. With meteor, it's Mongo or nothing.
I believe SQL integration is on their roadmap, but I think now it's too late.
You can in fact use React as the view layer with meteor, so for an app using React, the remaining killer feature of meteor 6 months ago was optimistic updates, with database sync all handled. But, there was still the hard limitation that you must use it with Mongo, which simply made it a no go. I commented about this here, a couple of times, and others did too. I even asked a few months ago if there was a library that just provided the optimistic updates feature. Well, now there is one that looks promising, though it's still early days and I've not used it yet - Facebook's Relay - with complete React integration, caching, request management and optimisation, and yes, optimistic updates and sync. The difference though, is that it talks to a graphql server, which can be written over any database at all - with Relay the frontend is entirely agnostic about the database used, by design, because it talks to it through a middle tier. There's no reason for me to wait for meteor to implement SQL integration any more, because now another solution has come along.
I still don't understand why meteor made the choice of a hard dependency on Mongo if they ever wanted to become mainstream. Had they not, it's very likely that many developers, myself included, would have picked up meteor over the past year and would be hooked on it. Now though, that train is rapidly leaving the station, at least for devs on the React stack. I think they missed their window.
Maybe someday I will need to replace 'x' with 'y' and have a hard time (or maybe not), but the time savings earned now are worth the technical debt that I might face in the future.
Oh, man that statement makes me cringe. Have you ever replaced a piece of proprietary technology with a different one before? I promise you, you will consider this decision up front much more closely next time.
Yes, this sucks, as anyone who's gone through a rewrite can tell you. But the broader perspective is that this is what software engineers are paid for. If you could just build a system and let it grow with minimal tweaks, the only people the software industry would employ would be technical founders.
[1] http://static.googleusercontent.com/media/research.google.co...
In my experience, you often iterate towards a replacement instead of pulling the rug out from the current platform and replacing it with another. This isn't always true, but in the case of CRUD based web apps, it's a lot smoother in my experience.
I ended up in a more fragmented place - node on the back-end with a lot of libraries (hapi.js, knex.js as two major ones) and angular plus a lot of extra code on the front. On the plus side, everything in my project works well, smoothly and exactly how I want it to work. Plus: referential integrity in the data model, since it's postgres back there. I even get live updates from the server to the frontend using postgres listen/notify and websockets. It took more time getting there, but ultimately I'm one of those Other kinds of devs - I don't want one big opinionated framework, I want a lot of littler pluggable bits.
But that's okay, there's room in the world for both.
So I got to work on some more advanced features I'd been thinking about. And at some point, Meteor started throwing an error from somewhere in its innards, and for the life of me I couldn't figure it out. Some kind of problem mapping data to UI, I don't remember the exact message.
I decided I needed to know the guts of Meteor to be able to debug problems like this, and put the whole project aside to wait for the Meteor in Action book. But now I'm onto other things.
A more general answer, I feel like the web programming world doesn't really need new frameworks, does it? Rails or Django got mainstream adoption because there was a need at the time, likewise with frontend JS frameworks (which seems to be consolidating around just 2 - React and Angular), and likewise with Node as filling a need for easy async. I'm not that knowledgeable on Meteor [1], however I think by default it's reasonable to expect no new frameworks to have mainstream adoption without a major change to the web.
[1] I don't know if Meteor's x-platform appeal is enough to convert users from other x-platform, native and/or hybrid solutions (Ionic, Titanium, RubyMotion, etc.).
And jQuery. Probabil still the most used JS library.
As for Angular, I feel like it's still too early to tell how it will end up - I loved Angular 1.X but eventually switched to React because it was much more convenient and only required minimal boilerplate. Angular 2 doesn't really make we want to switch back in its current state.
Of course we do. Those frameworks appeared because what was available at the time wasn't perfect. Rails/ Django addressed a number of pain points and made more rapid development possible. But development still takes time and creates bugs, so there's still room to improve.
Plus coders are always going to reinvent the wheel, so frameworks will continue to appear.
I see people make this mistake over and over again. It's so easy to underestimate the cost of learning something new. Often times it's best to just go with what you already know until you've done enough non-mission critical in the shiny new thing to be confident in it.
E.g try to find a sane way to work with PostgreSQL json,jsonb columns in a safe way in php. There's no even halfway decent solution. Half-supported, roll-your-own in doctrine is the best you can get
100% false.
It's also worth mentioning that unless you have a real-time app whose data model fits nicely with schema-less document storage, Meteor is almost never the right tool for the job. And even if your project has those requirements, there are plenty of high-quality alternatives to Meteor.
We're a new thing, but the focus is on simplicity and how easy the system is to grok. The goal is to reduce complexity via separation of concerns as related to systems, not just programming modules (actually, Nodal itself is opinionated and some parts are tightly coupled. The argument there is consistency within the service to keep it easy to reason about. There's no DSL outside of the ORM, which reads like Django's. Just ES6 JavaScript.) We're not trying to compete in the space of "real-time apps" at all, because microservice architectures are tried, tested, and much easier to reason about (at the expense of having separate codebases - which I actually view as a positive).
I did a write-up about it this week [2] and we're focused on trying to tackle pain points re: web app complexity as best we can.
1. http://nodaljs.com/
2. https://medium.com/@keithwhor/hello-nodal-why-we-re-building...
This is basically the reasoning behind my recent choice to not use an API documentation framework. Our application framework already has the ability to introspect and render templates, so there's minimal advantage in adding yet more tooling surface area.
This is correct, but it is also a balancing act. Sometimes the new thing is better. Sometimes it is simpler in important ways that provide leverage in the long run, despite being complex in other ways that create confusion in the present. Sometimes you need to learn new tools and shift your core competencies toward them.
An analogy: Nobody writes directly in machine code anymore. Symbolic assemblers were new technology that was better. The early ones may have been buggy, and it may have been simpler to just write it by hand instead of debugging your own code and the assembler, but eventually it paid off. Your core competency may have been writing machine code, but once the assemblers became good enough, it made more sense to be competent at using them.
Very few new technologies represent such a massive and obvious level-up as that, and it is unwise to chase everything in hopes that it will be one of those paradigm-shifters, but it is equally unwise to hide your head in the sand, believing that all new things are necessarily complex and unworthy.
I have been, and remain, skeptical of Meteor itself, but the problems it is targeting are real, and I think it and other projects are circling in on good approaches to solving them, which is worth paying attention to.
You can attack this problem from different angles. You can either refrain from using new tools OR you can widen your core competencies.
I work ~30h a week. The next 50h I spend doing my hobby thing, which is learning and using new - and old, as there are many forgotten tools which give you an edge over whatever is considered mainstream - tools in various areas. I'm a pathological case of a generalist, but even I have one or two things I specialize in.
Now, I did this for the last 10 years. The ratio of work vs. tech exploration was not always that favourable, but I kept doing this basically throughout the last decade. What I ended with is a skill that lets me very easily learn, understand and modify or fix new tools, be it languages, frameworks or libraries (among other things, ofc). So, in principle, I should have a vast choice of tools accessible to me.
But it doesn't work at all, because even if my project is currently being written by me only, it will be maintained by some other person in the future. And that person is almost guaranteed not to know any of the tools I decided to use, despite them being the best tools for the job.
Well, it looks like I'm just venting my frustration here, so please don't mind me. :)
All the things mentioned as "going beyond basics" seem like things that meteor was never designed for and that we have other tools to handle.
I really feel like the problem is with the people behind meteor trying to make it THE framework, instead of just being a framework that excels at a single purpose.
I feel like Meteor fulfills two niches in the Node world
* Experimental Javascript full stack framework
* Providing a foundation for full stack apps instead of having the developer do it.
I did some research on related areas a few months ago. My ideal stack at the moment would involve:
* redux or cerebral with immutable model
* react
* css modules
* webpack
* a realtime-enabled version of falcor, which doesn't exist yet.
The last bit is still the missing piece for realtime, as far as i'm aware. Neither GraphQL not Falcor seem to been designed with realtime model updates (via websocket) in mind.
Instead, I just utilize `Meteor.Methods` for all client/server interaction. I actually think it's pretty nice because you define the method on the client as a "stub" that gets called as it waits on the server response. I think the tutorials and guides focus too heavily on their fancy client/server mongo magic.
Though something that is a bit frustrating reading this is that I left React. I found it overly-complicated for my product and preferred architecting everything in terms of templates. Blaze is threatened by React? How? I like React, but I can't exactly get behind writing HTML components in javascript because whoa man, a diff engine & "look ma! I'm being functional!" I realize the benefits of uni-directional flow, but all it really did was add a lot more conceptual weight to a pretty simple interface.
So I said, this is pointless let's just simplify things with Meteor + Blaze. Now Meteor says, it's "threatened" by React?
I'm wary of anything (especially JavaScript as trends change there faster than one can read the articles) no matter how praised it is. Sometimes things just do break in the most bizarre manner when you already have everything set up. If components are modular enough, you can swap them, or at least patch a completely new piece over the old one, to handle the problematic cases.
When I once had to replace a very old legacy system (non-web, but it still holds) I've just slapped a dummy do-nothing proxy-like system in the front and gradually did stuff piece-by-piece. Then threw out the old garbage when it wasn't doing anything anymore.
But from what little I understood about Meteor from the tutorials and examples, there's one single giant system, that you either use or don't. This means, if one hits some bug or - worse - architectural limitation, they're going to have really tough time.
It seems that many people are unhappy with Meteor in its own way. It takes 375 factors to make a 'Rails' and Meteor has 370 for each person, but each person is missing a different five.
I just spent a good amount of time over the last few months building a prototype for an application in Meteor and it has been a joy.
Out of the box I got happy, grokable app/server communication, I got sane user account tools and I got a build process that works well enough that I haven't thought about it at all. I almost never need to look at documentation, I just build features. I've only needed a few community packages, and the ones I have used have been working pretty well for me.
I feel like I've been living the dream. So much ceremony and overhead just melted away.
I'd be curious to hear what kind of issues people have hit with blaze/meteor package management/etc that make them want to swap in react/npm/etc. (I spent the better part of 2015 with react/flux and it would take a lot to get me to switch back).
We've used npm for a server-only component of our architecture built in Meteor, but happily mix npm and atmosphere packages together with ease.
This seems to contradict the rest of your post where you go on to talk up the plug and playness of meteor. That's much more like ikea furniture than a board and nails. The board and nails approach requires you to do all the planning that meteor gives you out of the box.
A year or two later. "Project Foo: Total Crap". Glad I didn't look into that.
If you haven't looked into it, and you're in a remotely adjacent field, you're behind. Even if you don't decide to use it. The ideas underpinning the framework are very progressive and sure to continue in some form even if Meteor itself ultimately doesn't.
With all that said, I think Meteor is simply going through some growing pains. Given how ambitious its vision is, it simply can't avoid them. I look forward to Sacha's next, hopefully more optimistic, post!
Nope. Nope. GitHub stars was never a good reason to choose a framework. How about we compare real businesses out there?
Airbnb, Square, Twitter, GitHub, Basecamp, etc for Rails. What's there for Meteor?
But it is an indicator of it being something more than not-just-another-stupid-shiny framework that cannot be immediately dismissed.
Is looking at GitHub stars a recommended way to find the best frameworks? Or what would you suggest for that?
I recently started looking at Nodal since it was mentioned here on HN a couple weeks ago. It looks pretty cool at first glance but I haven't tried building anything with it yet. (I don't have infinite time.)
I remember when there was Prototype.js vs jQuery vs Yahoo's library vs MooTools vs fill-in-the-blank. I only switched to jQuery when virtually everyone else had. Until then I stuck with Prototype because its the one I already knew (because I tried it first), even though I had played with jQuery a little bit.
So, again I say there are just too many frameworks to keep up with. (And ask if anyone has a good site / method for dealing with this.)
No one's saying you need to keep up with all the JS frameworks, but if I were hiring a JS dev, I'd expect the person to understand the pros and cons of the most important ones. Meteor is categorically one of the most important JS frameworks out there.
I'm not sure about a way to determine the "best" or "most important" frameworks. Perhaps number of appearance on the HN front page could be a heuristic?
"Not free" is not quite right. The software is open-source & MIT licensed. The entity is for-profit, as it intends to sell services adjacent to the software, not unlike Acquia & Drupal.
[0] for instance, I made it trivial to invoke client functions asynchronously from server code using normal call syntax. Now how to deal with timeouts? The syntax doesn't permit much without leaking, destroying the original point.
And 'fully grok' is redundant anyhow - grok implies a full and deep low level understanding with no lapses, you cannot partially grok something. It's dissapointing to see uncommon words used in poor ways, I'm seeing this word misused all over HN as if its now a cult jargon.
There's nothing wrong with saying "grok."
But 'grok' is supposed to mean something more like understand various arbitrary things at a low and intimate level, not at a high level.
I do not appreciate you using "Aspergers" with an insulting tone.
I'd say it's been live jargon ever since Stranger came out, jumping from SF to the tech world as things often do, and I'm pleased to see it survive despite the modern distaste for Heinlein in many (but not all) SF circles.
"Isomorphic" or "Universal" are fancy terms for dual execution. Your code is run on the client and server. It has technically been possible ever since Node came out, but the problem is that client-side and server-side code interact with different APIs and carry out different tasks with them. The inputs and outputs are different so the code ends up different, even if written in the same language and even with the same design patterns.
TL;DR: JS on Client + JS on server != JS everywhere.
It's hard to understand this.