The State of Meteor Part 1: What Went Wrong
discovermeteor.com
discovermeteor.com
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...
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.
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. :)
"Blaze is threatened by React". You can use React or you can use Blaze. If React becomes so popular that Blaze is not longer used, that's OK... nothing to be threatened about. It's nice that Meteor can move with a trend.
"Tracker and Minimongo might eventually disappear as well". Tracker and Minimongo aren't giant stick bugs near Australia that need to be preserved. It's ok if they are replaced. They are internal tools for Meteor provide its "reactivity". I doubt reactivity is going away.
Other non-scary things: Routing is solved by community packages. Pagination, forms... really? Server-side rendering has the "spiderable" package, but the SEO / server-side rendering problem isn't unique to Meteor.
The database issue is valid. Meteor uses MongoDB. But, you shouldn't go down the Meteor road and try to shoe-horn a relational DB into non-relational DB, then say WTF. You knew from the beginning that non-relational DBs have their own set of problems. My limited understanding is that MongoDB was picked because it was the easiest way to get the reactivity that the MDG was looking for. Meteor road maps says SQL support is on its way.
I don't know where the OP is going with this. Maybe this is the part 1 of the late night TV commercial where they list all of our problems (think Slap Chop), then in Part 2 he'll solve all of our Meteor problems if we buy the next book he writes.
While there is no official core SQL support yet there are 3rd party add ons for PostgreSQL and MySQL available.
Its a bit awkward in places. Like if you want to receive a server-side web-hook, Iron Router is really the only way to go. But, lets say you have an Angular client, Iron Router can't be disabled on client when being used on the server. Now you have to hack for Iron Router and Angular UI router to play together nicely - using 2 routers on client because you want to receive server-side webhooks is obviously not ideal. But, at the same time both the community and the roadmap are coming together to make solutions workable before being fully 'solved', imo.
Except if you chose Blaze and that happened, you're stuck with a bunch of code written for a thing that is no longer used (by anyone except people like you, nothing new is happening with it), which is in fact a somewhat threatening place to be.
https://csci16.hellometeor.com/
It's incredible how accessible Meteor is for this purpose:
* One line complete local setup
* One line deployment (to Meteor servers, but still)
* Javascript only (no need to learn Python, Ruby, etc in addition)
* Out of the box User Accounts
* Simple templating engine with Blaze
I can think of no other framework/language combo where true beginners can deploy a live, database-driven website in a couple of hours. I really wish Meteor could focus more on this aspect: becoming THE entry-level framework for learning web development.
However Meteor's business model is around hosting, so it's inevitable they move further and further towards the needs of professional, rather than entry-level, developers. And this takes them further into the areas outlined in this article where they are currently weak.
But for a little higher level I always liked web2py[1] - it always felt like they managed to balance bundling/simplicity with proper documentation that build confidence in what is (and is not) included: like having a db schema accompanying the section on built-in auth[2].
But it certainly fails the test of "just one language". And it appears their chosen host (pythonanywhere) need to fresh up their SNI/SSL handling.
[2] http://web2py.com/books/default/chapter/29/09/access-control
However, I wonder about what exactly beginner students are learning. It's important to illustrate foundational concepts, and Meteor's foundational concepts are quite different in some places: no traditional CRUD API, but rather an entirely new protocol (DDP) for automagically syncing databases. It's wonderful for prototyping but is something of a black box unless you're really going to dive deep.
My current philosophy is to teach Meteor as a rapid prototyping tool, for which it absolutely excels, where the audience is actual more on the product designer end but with nontrivial javascript experience. When I taught an absolute beginner's workshop, I realized (as others have said here) that the complexity level really does ramp up rapidly.
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.
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 completely fail to understand why some developers seem to be allergic to learning about data structures and the means of query-ing them. It's not really that hard. If you can JS, you can SQL.
I'm not a fan of Meteor's dependency of Mongo either, but proper database architecture for a rDBMS is not an obvious skill. Even with an ORM (Rails/Django), it still takes care to set up PK/FK relationships and that's not necessarily taught in a CS curriculum.
Mongo would be sufficient if the data loss issues were resolved. (JSON in PostgreSQL may be a best-of-both-worlds scenario)
I don't know what gets taught in CS degree plans. But I will say that if I can learn how to model, query, and display data, then pretty much anyone can. Especially those with the benefit of a CS degree.
I don't use an ORM beyond certain limited functions. I use SQLAlchemy for a lightweight connection to the database and for migrations with Alembic. (apologies and accolades to zzzeek)
Beyond that I have a wrapper around database stored procedures that objectifies results from the proc. I wrote it once. It has worked really well many times.
It's not quite as easy as doing everything in your code. You have to support and maintain your SQL in addition to your web app code. But it is blazingly fast to do things this way, and in addition, you are going to have to do it this way eventually.
You must implement business rules in the database, or you will suffer at some point.
I disagree with you that Mongo will ever be sufficient, even if the Mongo team does manage the data loss problem (which, in my understanding, is that it's a feature--not a bug). I don't know of a method in the Mongo system that allows you to enforce business rules the way that SQL Server or PostgreSQL or Oracle does.
But I would happily be enlightened. This could be a case where I just don't know enough.
This isn't really true.
>This could be a case where I just don't know enough.
It sounds like you've picked up some very important things pretty well tbh. Better than a lot of people in the industry.
I mean, your code could be a complete mess for all I know. But what you're describing is a potentially very powerful and robust design. You're likely not giving yourself enough credit.
Hey, if you can navigate the tangled nightmare of conflicting redundancy that is music theory, modelling business objects and doing CRUD on them is surely a piece of cake ;)
As an example, a user can start updating a piece of data (eg: sales order, item, etc), with everyone able to see the changes as they happen (no hard need for locking, easy to support temporary network loss). Once they are done with changes, they are sent to SQL.
The advantage of doing it this way, is that the data stored in SQL Server can be completely optimized for reporting/storage and doesn't need the schema to support UI requirements. This makes things much simpler for people writing the UI as they don't have to change the SQL schema often to support the shinny new UI widget of the day and the report writers don't have to sift through a million useless to them tables/columns or partially entered rows to find the data they need.
If the Mongo data is flat, its very easy to go from Mongo->SQL, only a type mapper is needed.
The lumpy data case gets more complicated, as its dependent on the data. The complex data generally ends up translating into master/detail tables or similar ideas. Various pieces of data that is nice to have, but changes with the UI/customer needs, gets stuffed into several key/value tables (one for each type).
For the completely dynamic Mongo data we store in SQL, we alter the SQL table programmatically to meet the new schema (in part of our application, customers must be able to drive the schema). This way works in our specific application, but it requires a lot of work to make sure your users cant paint themselves into corners with their schema.
So far we haven't experienced any issues with the front-end people changing data structures, as the changes they generally make only impact fields that are not stored in SQL. Completely new features generally require the addition of new columns/tables to SQL, but every application has that issue. During startup of the server it double checks the schema of all of the tables used and updates as needed.
Reactive SQL in the Meteor style is tricky because who has time to reverse engineer DDA, and rolling it yourself would mean guaranteeing that you ended up doing it not the Meteor way.
Routing? Really? I am not an expert but I think if routing, of all things, is hard in to do in your web framework, you most likely have a problem. That's requirement zero!
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.
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?
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.
The big problem i see with meteor for the future, is that MDG has/will have to answer to its shareholders rather than its community.
Once you really get going, Heroku is expensive, but it might be worth the cost for teams (or individuals) that don't have the time (or expertise) to effectively manage a production deployment (security, up-time, backups, etc.).
Surely, there are many ways of deploying meteor apps, but no true simple way (which is why i expected a lot from galaxy). Like a single production line: create > develop > deploy w/ scalable infrastructure and cost. That was the whole meteor attractiveness for me.
There was a meteor based project where i spent 2 weeks developing a prototype and almost a month trying different deploy setups with the client. (heroku, digital ocean, linode, modulus, compose, aws, etc...)
Now, with ember or react + firebase, i can do the same stuff at a fraction of the cost and without having to learn devOps.
Appreciate your answer :)
Worth mentioning that there are many more solutions now than there were a year ago, when i was facing this challenge.
We currently have a meteor app in production and it has a few large clients running off of <$100/mo in server. A majority of our production costs are a large amount of redundancy and backups, not the actual server the clients connect to.
With docker it can be very simple to deploy meteor apps as release mode meteor is just a standard node.js app. It takes us about a minute to go from dev->staging (and less for stage->prod as the image is already built). Depending on your app, you can get away with a fairly tiny server (2 cores, 1-2gb ram is fine for demo/pilot).
Starter docker file (note: this is designed to be simple vs best):
FROM node:0.10 ADD meteor.tar.gz /meteor RUN (cd /meteor/bundle/programs/server && npm install) EXPOSE 80 CMD ["node", "/meteor/bundle/main.js"] #Put your meteor.tar.gz file in the same folder as this (name this as Dockerfile), then build and run. Will bind onto port 80 #Build Command: docker build -t meteor-prod ./ #Run command: docker run -d --restart=always -e MONGO_URL=YOUR_MONGO -e PORT=80 -e ROOT_URL=http://YOUR_EXTERNAL_HOST -p 80:80 meteor-prod
It appears that 2016 is the year when the hype from NodeJS died down and vendors/OSS-community must now deal with the hard, un-glamorous, work to clean up, maintain, prepare roadmap, and so on. Which is good!
Or it could also be the year where people realized that the use-case for NodeJS is fairly very very specific/niche (unless if they love JS so much that they're willing to absorb the pain using NodeJS + its ecosystem).
SailJS vs TrailJS, ExpressJS is dying, NodeJS vs io.js, StrongLoop+IBM fiasco (and SL reputation), now MeteorJS!. I had high hopes that MeteorJS can be one of the premier NodeJS frameworks (Rod Johnson, who created Spring Framework, invested in the company. I hope they listen to him...).
I love to see competition in NodeJS ecosystem and hopefully sooner than later, a few solid options emerged because right now, everything is not a good option except barebone NodeJS and roll-your-own-framework.
I disagree with this point... I think Node is very versatile and solid. I dont see anything niche about it. It does very few basic jobs well, 1) providing a good package system (NPM) and 2) giving us javascript on the backend. I feel like people think that just because Node is associated with Javascript that its inherently bad.
I've had a conversation with someone where I asked "how do you deal with Money in NodeJS" where the response was to farm it out to a services written in either C# or Java. No Money processing is done in JS (maybe because JS lack BigDecimal? or no standard Money library that deals with ISO-level currency?).
LinkedIN used NodeJS for their mobile app back-end if I recalled. I would assume that NodeJS is just a front-end appserver talking to myriad back-end microservices written in other languages.
So this is where I stand given the lack of good stable solid libraries provided by NodeJS: its place is just sitting as a gateway front-end appserver that pass processed request to a bunch of services in the back-end and get response back from those services, do minimum massaging, and spits JSON back to the front-end. This is why I kind of labelled NodeJS as a niche. Sure, Trello uses NodeJS all the way left and right but I suppose you can write web-app back-end using Go or C++ too. Painful but works.
My faith in JS for back-end is definitely pretty low given that working with either callback or promise isn't fun but that's personal preference more than anything else.
Anyhow... I'd love to see real production level NodeJS code that deals with complex business logic (as opposed to super-high-level presentations without insight to the actual code) before I feel comfortable choosing NodeJS in general.
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.
Routing in Meteor, for one, is trivial (esp. with Flow Router). Subscription management and caching are solvable problems too (esp. if you refrain from doing subscriptions during routing, but instead declare your dependencies where you are really are dependent on your data: in the UI components).
What’s the problem with using NPM packages inside Meteor, exactly? The fact that you must write a single additional line in a package? Well, if you’re not used to organize your code in re-usable Meteor packages, then, I guess, it’s more your problem, than it is a problem with Meteor.
Meteor does not scale well? How is that? Any Meteor app can scale, as can every application that has been set up with a well engineered architecture: implement you logic in micro-services and your Meteor app will scale smoothly, horizontally, until your database (and not your app layer, that is!) becomes the bottleneck.
Most of the comments here, seem to emanate from me the degree of freedom that comes with Meteor (platform vs. framework). If you can’t architect, then, obviously, Meteor won’t save your day and do your engineering for you.
I put up some slides with Meteor best-practices for building large-scale apps: http://meteor.redandivory.com/ The presentation is almost two years old, but most of the guidelines still hold.
tl;dr — It’s not the framework’s job to do your architecting. Don’t blame the tool if you don’t read the manual.
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.
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.
I just don't think it's as good as the other options technically (does not scale well as a server, which is a problem for most applications).
More importantly, as a developer, I do not believe VC money should be bringing opinions to the open source community (which is what this is) is a bad idea. The whole point of open source projects is to have natural selection happen. Meteor having VC money allows them to get it wrong but still market it etc... Which just seems like a poor idea.
I think open source should have a VC mechanism going on, but first you have to prove your worth to the community.
But, having said that, there is still a very bright future ahead for Meteor. The people at Meteor Development Group have identified these pain points and have plans to improve some of it. There are various tasks that they are working on now that will change Meteor a bit, but also make it a better platform (in my opinion). Things such as better NPM / module support, support for multiple different types of databases, faster build times, better testing support, etc.
The platform has been around for awhile and I still think that it can reach the goal of being the go-to JS platform for building cross-platform applications.
Eventually you might want to scale and then, as in any library/framework/platform things will get a little more complicated. I don't see it as a problem, really.
Meteor always was opinionated and maybe some opinions were unpopular from the beginning (MongoDB, for example). But when you start adding multiciplity (React/Blaze/Angular for the frontend, Iron Router/Flow Router/React Router for routing, Meteor Package System/NPM...) you can lose the track. I'm afraid this is happening now.
For experienced web developers, or people building bigger projects, easy start (and whole magics) is incompatible with high modularization and ability to easily tweak anything.
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.
But Meteor, it just made my move into Javascript webapps so easier. I'm seeing results instead of that paralysis of am I learning the right framework. I'm also almost 80% done with my niche Classified ads site.
Meteor JS is best thing I picked up In 2015.
Relational DBs exist for a reason.
Being stuck with Mongo is the major reason why I wouldn't use meteor again.
The other stuff was minor and had solutions. We also built an open source library that wrapped up collections well.
https://atmospherejs.com/patmoore/meteor-collection-manageme...
1. 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.
> This creates a bigger barrier to entry compared to front-end frameworks like React and Angular, or server languages like Go or Elixir.
Okay, Meteor has an arguably bigger barrier to entry than React or Angular (maybe), but definitely 100% not Go or Elixir. I think this is just disingenuous.
> I believe some of Meteor’s early choices may have ended up handicapping it. For example, Meteor’s focus on real-time applications makes them a lot easier to build compared to any other platform out there. But it does also come at the cost of hidden complexity, and potential performance problems down the road.
This is the #1 problem of every framework, ever. Mr. Greif is not saying much, if anything at all.
> Once a new Meteor user starts to go beyond the basics and look into things like routing, pagination, subscription caching & management, server-side rendering, or database joins, they realize that the difficulty curve quickly ramps up.
Here, he's conflating things that are easy (routing and pagination) with things that are hard (subscription caching), so it's hard to see exactly what the criticism is here. Not to mention that Iron Router are pretty mature. I haven't run into a routing issue yet that it couldn't solve. As far as joins and caching, etc., these are definitely difficult things. I don't think any framework out there completely (and in the general case) solves these out-of-the-box. Maybe someone could introduce me to one.
> The result of all this is that Meteor has ended up in an awkward place.
I think it just ended up where almost all other frameworks end up: useful, but not completely generalized. In fact, I think striving for a very high degree generality might be a mistake, lest we want to end up with something like Hibernate.
[1] http://www.amazon.com/Introducing-Meteor-Josh-Robinson/dp/14...
We bet on Meteor and it's doing phenomenal. The development experience is great. I haven't been this happy and impressed since rails .9 ripping me a new case of programming love.
Look, meteor has it's downfalls but so does any stack. There's nothing working against you, it's all just code. There's no magic. You don't understand subscriptions, merge box, and how to handle joins? Level up a little bit. It's not a hard thing to figure out. Open source code makes it easy to dig in.
Yes, mongo is looked at in bad light, it's also incredibly powerful when used right. The trick is to not be oblivious to the tools you use and work around it when it matters.
The most important thing for a product, startup, and company is the ability to make the right calls and grow at the right time and then be able to handle and accommodate problematic areas when you need to.
Does meteor scale? Yes. Does it have a theoretical limit? Yes. The trick there is to be cognizant of the limit and plan around it when you are approaching.
It's all just JavaScript at the end of the day.
Oh you want to scale out your processing? Easy. Fan out some back end nodes in whatever language you want. Pull from mongo, do your crunching, and then feed it back in. Then meteor will sync it to all clients. This is pretty powerful. You can completely swap out and fan pieces out with meteor.
We have a massive app in meteor. It's also architected to be modular if we have to break it up.
The isomorphic nature of the code base has created pleasant APIs on both the front end and back end and has drastically simplified a real time app experience. Meteor sets a new standard for web applications and demands new perspectives. When you embrace it you get an ecosystem that is quite revolutionary to work with. Everything from the web-app, latency compensation, pub/sub, down to Cordova builds.
Overall, we are very happy. Yes things can be better, and we are looking forward to seeing meteor evolve.
Meteor shouldn't focus on supporting new view frameworks like blaze vs react. Just focus on adopting the tools out there and making it better. That's why meteor doesn't need blaze. Meteor doesn't need a router. Meteor should pick the best open source versions of that in the Js community and make it easy to work with inline with the "vision". Meteor should focus on the developer UX. This is their power. An opinionated framework that removes the stress of configuration and has tools that fit really well together to allow an individual, team, and company to focus on building what matters: features.
The vision is grand and I believe it in and I'm also not worried about scale. People said the same shit about rails, and x, y, z. Scale is a good problem to have and when you have that problem you'll figure out what you have to do.
If anyone has any questions about meteor architecture feel free to ping me.
---
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.
Can someone point to the backstory here?
[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.
I personally enjoy seeing people voice their mistakes in a honest way so the rest of us can learn.
Edit *your
Also it's "your", not "you're."
The same place you saw the negativity, which is why you prefaced the sentence with "I'm sorry."
One should not assume someone's technical prowess based on one poor decision (a decision they've recognized as suboptimal). Also, they still shipped.
You most definitely can judge someone's technical prowess as well based on their decisions. I am not sure how you're going to grey-wash this into some kind of innocent mistake. The decision that was made reeks of novice motivations and perspectives.
I asked a very blatant question, if one is going to go off of titles, how does a CTO and lead engineer (or anyone leading any kind of project) make such a novice mistake, together nonetheless. My apologies for not echoing commendations.
Your original comment suggested this person mis-understood a foundational principle of software development. I, and I suppose many others, have been reading Hacker news since before we were senior engineers. So its not being "perceived" as having value; by your own admission, it is full of value (for a large portion of hacker news). While criticism is indeed tolerated, it must provide some value to the discussion. your original comment effectively read: "You are so incompetent, how did you ever get hired". That is not conducive to discussion; hence the down votes.
My comment then was meet with trivialities, outlandish statements, and generally nitpicking of tiny parts of my posts. And it appears that because they simply took a position seemingly contradictory (in the lightest sense of the word) to mine, they have been spared any amount of criticism despite significantly diminishing any hope of constructive conversation. Quite honestly, if I had simply ignored these responses there'd be far less noise and general non-sense. My question was not a top level post, it was specific to what was stated and based on one other comment the OP made in the same thread. It's not complicated to respond to nor to understand the motivations of.
Based on his comments, both the lead of the project and the CTO chose an entire stack for their product after seemingly one hackathon, maybe even hosted by Meteor itself.
I am sure the industry doesn't need to have a conversation about how huge amounts of capital are being used at various companies, with people who lack the experience (or sometimes, and not necessarily in this case, intelligence) to make such decisions, all while giving marching orders to who knows how many engineers under them. And again, this type of problem and others like it are something that the industry as a whole has plenty of talent do deal with and appropriately handle. So, how did this non-sense of picking this shiny new toy come about? How did he become lead? Which is why my question was asked. This isn't some isolated incident. I see it far too often, especially professionally.
Oh and let's not forget this is all on a post about the schism between development motivations in the Meteor community.
Calling me a troll for not using an endearing tone and having a question that is part of a larger conversation on the state of the tech industry is maddening. That being said, this is clearly not the right audience, especially using the responses as benchmark, so I'm dropping it and sticking with "just ignore everyone but OP" after this.
It's a really rather silly situation -- but as far as startups go it seems par for the course. It's quite irritating.
i'm not a moderator here.
We detached this subthread from https://news.ycombinator.com/item?id=10937969 and marked it off-topic.