Why will it be any different this time compared to last time with GWT, Dojo or SproutCore?
Server - client binding javascript widget frameworks are nothing new, and they have, historically, failed to be capture broad adoption because they require a very specific backend.
If you had an excellent series of react components with data binding done via an open server specification and meteor just happened to be one implementation that backend; people would really dig that!
...but there would be a lot of people who didn't use meteor at all; and just wrote their own server implementation for it.
“but wait, if we end up using React, Relay, and GraphQL,
what do we even need Meteor for anymore?”.
...
This all boils down to one key fact: Meteor is the only
framework that controls the whole stack.
So what? Who cares? Controlling the whole stack isn't even remotely interesting unless there's some tangible benefit from it.
This is by far the weakest and least compelling part of this article.
So this is my vision of the future of web development
for 2016. React as a common front-end standard, and
Meteor starting out as one of many possible back-end
choices, but slowly becoming the one that just makes
sense.
You really need to try harder to explain why Meteor would be a compelling choice for people then.
If the front-end component api is well defined and backend agnostic, meteor seems to offer literally no particular benefit over any other backend someone might choose.
Server - client binding javascript widget frameworks are nothing new, and they have, historically, failed to be capture broad adoption because they require a very specific backend.
If you had an excellent series of react components with data binding done via an open server specification and meteor just happened to be one implementation that backend; people would really dig that!
...but there would be a lot of people who didn't use meteor at all; and just wrote their own server implementation for it.
So what? Who cares? Controlling the whole stack isn't even remotely interesting unless there's some tangible benefit from it.This is by far the weakest and least compelling part of this article.
You really need to try harder to explain why Meteor would be a compelling choice for people then.If the front-end component api is well defined and backend agnostic, meteor seems to offer literally no particular benefit over any other backend someone might choose.