The State of Meteor Part 1: What Went Wrong(discovermeteor.com)
discovermeteor.com
The State of Meteor Part 1: What Went Wrong
https://www.discovermeteor.com/blog/the-state-of-meteor-part-1-what-went-wrong/
188 コメント
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.
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.
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.
Also, consistent growth isn't really enough, usually, to capture a market and exponential growth is usually expected from startups.
Agreed.
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.
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.
Rails forked sometime ago (around 2.0) into Merb then later on merged back into Rails 3.
Similarly Node forked into io.js then later back into Node 4.
Similarly Node forked into io.js then later back into Node 4.
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.
> 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...
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...
> 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):
https://kadirahq.github.io/mantra/
This is great, but the envision/extraction disconnect persists within Meteor itself, where it matters most.
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.
[deleted]
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...
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.
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.
1. http://nodaljs.com/
2. https://medium.com/@keithwhor/hello-nodal-why-we-re-building...
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...
> 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.
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. :)
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. :)
>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.
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.
> 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.
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 why PHP still thrives.
Or because it's a mature language, with a robust, very rich and up-to-date ecosystem.
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
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.
100% false.
100% false.
Yep, lesson learned big time :)
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)?
If you had to do it all over again what would have been your choice(s)?
This article does a disservice to Meteor. The article feels drama filled and says many things are broken when they are not.
"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.
"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.
RethinkDB is still a strong possibility as an alternative, it's similar enough to MongoDb.
While there is no official core SQL support yet there are 3rd party add ons for PostgreSQL and MySQL available.
While there is no official core SQL support yet there are 3rd party add ons for PostgreSQL and MySQL available.
There are no Postgres or Mysql add-ons for Meteor that are actively maintained or even close to production ready. Hopefully you can prove me wrong on this, but I've looked and have only found preview releases and alpha quality packages.
This looks promising https://github.com/jordangarside/Meteor-GraphQL-PostgreSQL-D...
Today, there are 0 add-ons that support MySQL, that are actively maintained or worked on, that you can download through atmosphere, the package manager.
> If React becomes so popular that Blaze is not longer used, that's OK... nothing to be threatened about
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.
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.
> Routing is solved by community packages
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.
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.
There are separate server-only routers. Here's a tutorial I whipped up: https://themeteorchef.com/snippets/server-side-routing-with-.... This would remove the need for a dependency on Iron Router on the client.
If there had been an official router, what's to say it wouldn't have had the same problem?
I'm currently using Meteor to teach a college-level course on Web Development for beginners.
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.
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.
I'm biased as the co-teacher, but I've been hugely impressed by progress our students have made in just three weeks. Meteor really does fit in well to the beginner curriculum.
Looking at the course page, it does indeed look like meteor is a good fit; it appears that if the course was from the late 90s it would be 2 parts html, 1 part css and 1 part cgi.
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.
[1] http://www.web2py.com
[2] http://web2py.com/books/default/chapter/29/09/access-control
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.
[1] http://www.web2py.com
[2] http://web2py.com/books/default/chapter/29/09/access-control
I like web2py too though there don't seem to be too many people using it. Comparing to things like Meteor and Rails it's striking how it's remained backward compatible and much the same since it was launched 8 years ago.
I always ask myself in these cases, what do you mean by "progress"?
I've taught using Meteor as well, and I agree that it's incredibly wonderful for getting a real, live, modern web app off the ground in minutes. I plan to do more workshops with Meteor.
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.
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.
[deleted]
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.
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.
> 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.
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.
It's actually even easier in CouchDB than Mongo. One of the smaller mysteries to me has always been why Meteor went all-in on Mongo rather than Couch.
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.
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.
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.
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.
So why wouldn't you use rails and benefit from a matured platform and more proven scalability?
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.
[1] http://static.googleusercontent.com/media/research.google.co...
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...
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.
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.
Same.
Welding the frontend to the backend is a definite no-go for me, regardless of the supposed benefits of this isomorphism.
Welding the frontend to the backend is a definite no-go for me, regardless of the supposed benefits of this isomorphism.
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?
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?
Data is forever.
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.
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.
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.
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.
I used meteor for 2 years professionally.
The issue that you raise is less important with meteor because updating the server code updates the client code.
The issue that you raise is less important with meteor because updating the server code updates the client code.
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.
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.
Not to argue your point about the options being limited, but support for rethinkdb is in progress.
> What happens if suddenly I want to rewrite part of the back-end or part of the front-end
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.
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.
> 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.).
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.).
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.
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.
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 don't see evidence for consolidation around front end JS (http://trends.builtwith.com/javascript/javascript-library). We'll probably be stuck with yet another framework syndrome for a while...
backbone.marionette, anyone? its maintainers are kicking around incremental-dom ideas..
"likewise with frontend JS frameworks"
And jQuery. Probabil still the most used JS library.
And jQuery. Probabil still the most used JS library.
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 see jQuery mainly as a library to eliminate browser differences.
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).
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.
I was never able to get on board with Meteor because of the Mongo dependency. Not to get too far off topic, but Mongo is guaranteed to lose data under certain well-defined conditions.
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 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 currently use Meteor for a production app, but only use Mongo as a scratch pad (holding data until the user is mostly done changing their mind and other minor UI state). Data is then packaged and sent to MS SQL Server for long term storage and reporting.
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.
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.
This is very interesting. Could you give a little more details on how you accomplish this? How do you serialize unstructured Mongo data into MS SQL? Does this system break down when front-end people change the data structures in Mongo? I'm not familiar with Meteor but maybe you could explain in broad strokes
There are several ways we go about it depending on the needs of the data to be stored in SQL. All of our data in SQL and Mongo has a uuid as the primary key and effectively lets us use merge-style replication techniques, and support temporary offline use of our application.
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.
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.
thanks very much for the explanation. That sounds like interesting work and a great solution
> I completely fail to understand why some developers seem to be allergic to learning about data structures and the means of query-ing them
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'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 might be speaking to a sparse audience here, but I don't come from a CS curriculum. I'm a violinist and a music theorist who happens to have learned enough to make a better living by writing code.
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.
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.
>But I will say that if I can learn how to model, query, and display data, then pretty much anyone can.
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 ;)
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 ;)
I have no use for a dev stack that is tied firmly to a db that is incapable of handling relational data properly. Many, many devs agree.
The latest version of Mongo added support for document validation on insert/update.
https://docs.mongodb.org/manual/core/document-validation/
https://docs.mongodb.org/manual/core/document-validation/
> If you can JS, you can SQL
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.
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.
> 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.
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!
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!
Yeah I don't get this part and it has nothing to do with Meteor, just that new users find it hard to do anything beyond Todos. But that also makes no sense. So it's hard for the user to not do something very simple? Maybe the user should take the time to learn what they don't understand.
Routing in Meteor is non-trivial if you want it to behave how a single-page app should behave. The defaults provide the bare minimum of usability and arguably worse than what we had with server-side rendering. It's exasperated by the fact that the routing libraries are not part of the core framework.
Its not even true either because there is the iron-router package. Yes it is not "core" meteor but it is a very popular package.
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).
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.
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.
I can echo your positives regarding using the platform. It's been mostly a joy and learning it has been fun.
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.
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.
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?
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?
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.
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 resonate with your comment the most.
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 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 loved meteor. Was committed to it for 6/7 months while still learning JS (and working on ember and rails projects with others). I knew it was a risky decision, but it seemed like a good choice for making it as a one-man dev agency.
For me, there's no stack selection problem, for me, the main problem is the co$t of launching a working demo-app or a prototype. The only thing i wanted was a simpler/cheaper way of deploying apps.
I knew there was something coming, since the beginning i heard about galaxy, an MDG developed deploying solution, which i thought was the solution for all my problems. But then, then came the galaxy launch and its price ($495/mo). At that price I felt betrayed, misrepresented. (still waiting for the individual price several months after)
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.
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.
In regards to cost of launching a working demo-app or prototype my solutions was a Digital Ocean $5/month box + Dokku
https://github.com/dokku/dokku
https://github.com/dokku/dokku
Didn't know about Dokku, thanks!
Worth mentioning that there are many more solutions now than there were a year ago, when i was facing this challenge.
Worth mentioning that there are many more solutions now than there were a year ago, when i was facing this challenge.
The biggest downside to meteor for me is that nobody has settled on a good way to use it in production.
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
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
You must have missed it, the individual developer galaxy hosting is out. I am using it, its amazing. $13 per month per container. Its not the cheapest ($5 D/O wins there) however so far I have found it to be fantastic! They take care of all the nuts and bolts behind the curtain. You just deploy with a single command in console and it uploads, builds a new container, migrates active sessions, tears down the old container.
Isn't Galaxy Developer Edition still invitation-only? The only official information I can find on it is this blogpost, http://info.meteor.com/blog/galaxy-developer-edition
To address your "co$t of launching a working demo-app or a prototype" issue, Heroku offers a free app / database for demo purposes[1].
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.).
1. https://www.heroku.com/pricing
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.).
1. https://www.heroku.com/pricing
You are right, i've used heroku (haven't seen it in a while though, so thanks for the link). Maybe now it's simpler, but at this time last year, it wasn't.
Also, main problem with free-tiers is that meteor is CPU/RAM-intensive and they do not handle that very well. I'll have to check it up again though.
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 :)
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 :)
As long as there is no direct PostgreSQL support, Meteor is no viable option anyways.
There does not seem a day to go by without a NodeJS-based framework/library get the heat from the community ever since December 2015.
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.
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.
> 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).
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 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 see BigCo who uses NodeJS only use it for their front-end appserver that farms the actual work to microservices _that are not written in NodeJS_ behind the scene.
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'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.
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.
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.
When I saw MongoDB, Meteor got put on a "check back some day" list. Phoenix is way more interesting: it's built on some very solid foundations.
The challenges discussed by the OP apply to any large-scale complex project and are not limited to developing in Meteor. True, some are specific to Meteor (besides the challenges that go with all NoSQL architectures), as is the case with any tech stack. IMO it’s quite unfair to obsess about the cons only (especially if they are the kind of “problems” you can’t tackle), and to take the pros for granted.
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.
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.
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).
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.
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.
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.
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.
Honestly, I used meteor and tried pretty hard, I went to their hackathons, etc...
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 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 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.
This article is really great. Yes, Meteor is still one of my favorite platforms, but every library / framework / platform always comes with its pain points. I have had a great experience with it so far and I have to admit, I did get to a point recently where I was having trouble recommending it to other people and companies due to the various points stated in the post.
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.
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.
The major benefit of Meteor (at least for me) always was its quick bootstrap. So you want start coding or work on a mock-up? Just meteor create myapp and start. No boilerplate. No script and style tags. Heck, add bootstrap with a single line of command and you start with fine-grained classes! Sure you might need a database... don't worry! No need for schema, modeling, whatever, the server is already there and so the database.
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.
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.
I concur. The strong part of Meteor is its easy way start (both a project and diving in web dev).
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.
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.
'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.
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.
As a newcomer to Javascript frameworks I totally love Meteor JS. I come from Java backend programming and My Job/Client always worked on proven not so recent frameworks like Spring etc. I always wanted to learn the Javascript frameworks but the vast options there are made it very difficult. Too many JS frameworks, Too many choices. I started learning Angular and they decided to do a makeover which requires learning from start. Even React isn't something quick to master.
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.
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.
So, Meteor is going to turn into what SocketStream was, five years ago, before it was completely eclipsed by Meteor's marketing steamroller.
Meteor is easily the most productive webstack I've ever tried (couple of years ago) including learning, app setup, configuration etc vs some of other popular choices. I hope at least some of that carries over to what ever is coming out next.
We used meteor at my last company. By far and away the biggest issue was being stuck with Mongo. NoSQL databases have their place. But they are not a universal solution to everything (or even most things).
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...
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...
[deleted]
The reason I picked firebase over meteor was ember support. Ember and ember data on top of meteor would be a killer combo for me.
This is a little worrying; after much research I'm starting a new project for a startup using the meteor stack.
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.
and if it takes longer to get what you need to do done with meteor your startup might have a far greater chance of failing because of meteor.
Author here. Hopefully part 2 will answer your worries a little bit. In the meantime, check out Mantra [1] and the Meteor Guide [2].
1. https://kadirahq.github.io/mantra/ 2. http://guide.meteor.com/
1. https://kadirahq.github.io/mantra/ 2. http://guide.meteor.com/
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.
If Meteor is a fit for your project, definitely use it. Real-time, isomorphism, and more can be of big benefits to rapid development.
So, full disclosure: I recently co-authored a book on Meteor which comes out in a few months[1]. I don't think Meteor is a cure-all panacea or that it's the Best Framework Ever®. I've come to Meteor with a fair bit of experience (Play 1.0/2.0, Sails.js, Flask, etc.) and a fair bit of skepticism. However, I really don't think much went wrong with Meteor. In fact, it treads some of the same ground as its predecessors. As far as OP's article is concerned, I have some very specific squabbles with it:
> 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...
> 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...
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
Lots of fear mongering here and as you'll notice, a lot of voice from inexperience with meteor itself.
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.
---
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.
---
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.
I think the problem with Meteor is that it's not meaty enough...
https://github.com/mattkrick/meatier
https://github.com/mattkrick/meatier
"Project Foo: The Greatest Thing Ever". What is that? I should look into that.
A year or two later. "Project Foo: Total Crap". Glad I didn't look into that.
A year or two later. "Project Foo: Total Crap". Glad I didn't look into that.
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!
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!
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.)
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.
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.
> It has more stars on GitHub than Rails.
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?
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?
I'm not saying the # of GitHub stars is a good reason to choose a framework.
But it is an indicator of it being something more than not-just-another-stupid-shiny framework that cannot be immediately dismissed.
But it is an indicator of it being something more than not-just-another-stupid-shiny framework that cannot be immediately dismissed.
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".
> The recent Blaze/React debate
Can someone point to the backstory here?
Can someone point to the backstory here?
I was curious too, found this:
https://www.discovermeteor.com/blog/blaze-react-meteor/
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.
I think it is for development only.
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.
Thanks for the clarity. That will teach about commenting during the morning commute.
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.
[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.
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.
It's hard to understand this.
"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.
See also Martin Fowler's "First Law of Distributed Objects" - "Don't distribute your objects". The reasoning is exactly as you described.
[deleted]
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.
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.
I apologize for the redundancy in my phrasing. Hopefully you can get over it.
I do not appreciate you using "Aspergers" with an insulting tone.
I do not appreciate you using "Aspergers" with an insulting tone.
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.
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.
jargonfile or gtfo
There's nothing wrong with saying "grok."
There's nothing wrong with saying "grok."
"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.
But 'grok' is supposed to mean something more like understand various arbitrary things at a low and intimate level, not at a high level.
Meteor is great and Im optimistic what 1.3 will bring with better NPM support.
I'm sorry, but how are you in a lead position but somehow didn't understand a timeless principle of software development?
This comment breaks the HN guidelines. Substantive criticism is fine, but potshots—like rubbing someone's nose in a mistake—are not. The signs of a substantive criticism are that it is respectful and teaches the reader something.
We detached this subthread from https://news.ycombinator.com/item?id=10937969 and marked it off-topic.
We detached this subthread from https://news.ycombinator.com/item?id=10937969 and marked it off-topic.
I'm sorry... Literally your entire posting history is negative without adding any value. Why is that?
I personally enjoy seeing people voice their mistakes in a honest way so the rest of us can learn.
Edit *your
I personally enjoy seeing people voice their mistakes in a honest way so the rest of us can learn.
Edit *your
Where do you see negativity? How is his comment adding any value? "We chose a stack we didn't fully understand after trying it for less than a week and it turns out we didn't know everything about it!"
Also it's "your", not "you're."
Also it's "your", not "you're."
> Where do you see negativity?
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.
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.
That's a ridiculous statement. "I'm sorry" is not an indication of negativity. Nor is it indicative of my posting history. Apparently criticism is simply not allowed. Sorry to poke the fluff that is somehow being perceived as value.
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.
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.
> Apparently criticism is simply not allowed. Sorry to poke the fluff that is somehow being perceived as value.
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.
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.
I like how a very forthright question has been met with utterly ridiculous characterizations of what was stated. I didn't say "how did you ever get hired." I specifically mentioned the lead/CTO aspect. It's a crudely constructed sentence that should result in a struggle to interpret any other way.
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.
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.
Every title is made up. There are all kinds.
Apology accepted.
How do you suppose those "timeless principles of software development" were born? People sharing only their success stories?
Not only was it not much of a story, in fact it's so generic that can be applied to almost any field, but I never said he shouldn't have shared it. I asked how he was a lead on a project, when it's kind of clear that he probably shouldn't have been. I'd also be inclined to ask how is CTO is, well, a CTO.
It's a really rather silly situation -- but as far as startups go it seems par for the course. It's quite irritating.
It's a really rather silly situation -- but as far as startups go it seems par for the course. It's quite irritating.
It IS NOT clear that s/he should not have been a lead, it IS clear that they made a poor decision, and are humble enough to admit to it and share it to the community. It is no surprise EVERY one of your comments is flagged. Your tone is continuously condescending rather than inquisitive.
your replies here are completely trollish, you're likely to be shadow-banned from this forum (meaning nobody would sees what you write). if you write a contact here I'll explain why in a personal email.
i'm not a moderator here.
i'm not a moderator here.
Everyone makes mistakes, and this one's more common than one might think :)
It's definitely a common mistake. It is not a mistake I would tolerate with a CTO or someone leading a project.
[deleted]
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...