Hi,
I did a write up on what are the top 5 predictions for Meteor in 2016 and why they are.
And, this is the way it should be.
Read It: Top 5 Predictions for Meteor in 2016
Hi,
I did a write up on what are the top 5 predictions for Meteor in 2016 and why they are.
And, this is the way it should be.
Read It: Top 5 Predictions for Meteor in 2016
Excited about Mantra
So basicallyâŚ
MDG = modulus
Meteor = webpack
Mantra = undefined
React + React native with a node api + webpack.
Sounds about right. Definitely agree with #2 that weâre going to start seeing stacks and distros built on Meteor. And while I agree with #4 that the meaning of isomorphism will change, Iâm not in complete in agreement with what that means (e.g GitHub and Chrome may be more responsible for driving that changing definition than NPM).
What do you mean by
GitHub and Chrome may be more responsible for driving that changing definition than NPM
I like to hear more.
In the blog, I added a sentence like this:
But thatâs history. Right now, Meteor is a mess. Frankly, this is a really bad time to start a new Meteor app.
This is not because, there are much better ways to get started and build an app quickly. But there are lot of moving parts right now. Thatâs why I say so. For an example,
How about the backend part?
Very much agree with this one. I have put my plans on hold as I wait for a future proof way of doing things. Spending my free time reading documentation and familiarizing myself with the 10âs of techs that hook onto the platform each week. Quite disheartening to say the least.
Everything has changed and is still changing; yet its about the same thing:
https://github.com/skybreak/skybreak
Skybreak is an ultra-simple environment for building modern web applications.
With Skybreak you write apps:
- in pure Javascript
- that send data over the wire, rather than HTML
- using your choice of popular open-source libraries
Please, do not share or blog about Skybreak yet. It is experimental, pre-release software. We hope it shows the direction of our thinking, and much of it will to change. Weâd love to hear your feedback.
Documentation is available at http://preview.skybreakplatform.com/
My predictions:
1 â Fibers get removed. It filled a missing gap. ES2016 has built-in async, promises, generators, etc.
2 â Blaze dies, tracker dies, and even DDP may see revision (likely backward compatible)
NOTE: 1 and 2, maybe not so much âdieâ as become just another stack setup on Meteor. The old way.
3 â RethinkDB. Low hanging fruit.
4 â Cordova integration will NOT die. There are indeed a class of apps that can run cross-platform.
5 â A simple, efficient, and popular micro-framework stack for Meteor will emerge (maybe 2017).
Excellent post. Couldnât agree more.
Adding to this, I think cordova will be (or at least should be) removed from Meteor, in favor of react-native.
Cordova was an attempt to carry the isomorphism banner, but isomorphism is not that serious on Meteor from the beginning, and Cordova support is not that different.
I think the prediction about meteor being something on top of which js based infrastructure will be built is spot on!
Meteor based micro services communicating via ddp to others in other stacks is what im concentrating on right now.
Meteor for authenticated api and golang based services to handle plain old REST(Boring Coz golang will handle it better) is something that could work !(Actually looking for advice here
)
care for some thoughts? @arunoda
meteor = node,
node is the server that runs meteor, but now you can use any NPM package anyway, therefore backend = node
from my understanding React-native isnât that mature. I wish React-native and Native Script would somehow combine to provide a truly âJS firstâ cross platform programming environment.
I feel like the last year has been nothing but blog posts and forum topic devoted to how Meteor is dying or how X is better than Meteor etc. Itâs very concerning especially for those of us who have projects in progress. Am I supposed to tell my company âhey you know that project weâve pumped a lot of time and resources into? Well we need to re-write most of it now after only a couple months because Meteor decided to become something else.â
Maybe Iâm missing something but I donât feel like I see this much division with other frameworks in regards to whether or not the process will still be around in six months. As much fun as I have with Meteor the constant speculation is tiresome and it feels like its just not worth the stress to worry about whether Meteor will be around a year from now or how now I have to refactor an app because thatâs the way the wind blows.
Iâm curious why you think Rethink is much superior to Mongo. I heard Rethink is working on a more granular oplog feature, but then I heard Mongo is working on that too. How do I know Rethink is not the âshiny new thingâ that everyone is attaching to?
I wonder because I (and many people) have many apps in Mongo. I think I can figure out how to run minimongo and graphQL in the same app, making it easy to gradually upgrade my app⌠but DB is different, you have to fully commit to one or the other. So why take a big risk unless itâs way better!
This is because Meteor is no longer the opinionated framework it once was! Meteor=npm now.
Donât worry, Blaze, livedata, etc. will be supported for a long time (no, Iâm not affiliated with MDG, but I suspect theyâre committed to providing backwards compatibility for a long time for all their big corporate clients). It just wonât be top choice for building large, scalable appsâŚ
âŚwhich it never was, anyway! Meteor was always best for small apps used by a limited number of users, it was never meant for building the next Instagram or Facebook. (Whether you draw that line at 100, 1000⌠100000 users, it depends on how much $ you want to spend on hardware/memory â and time optimizing your app).
So, while I get your nervousness about whatâs going on, rest assured your project is built on fine technology, things are just changing very quickly, for everyone. I bet you will be better off upgrading an old Meteor app than upgrading an Angular 1.x app.
Working on the bleeding edge means sometimes you will get cut. I recommend being upfront about the state of Meteor before suggesting it as the main stack for a project, then you can deflect potential blame down the road when things change.
I have apps in Mongo too. The problem is that when the solution calls for a relational database and other frameworks offer better built in support.
There are many relational vs non-relational debates already. RethinkDB offers much better relational support than Mongo.
I donât have a ton of experience with RethinkDB (only 3 prod apps using it for ~6mo) but hereâs my take:
TL;DR RethinkDB seems to be Mongo done right, plus realtime specific features. The entire architecture is based on a push philosophy rather than a request/response philosophy.
How do I know Rethink is not the âshiny new thingâ that everyone is attaching to?
A lot of the hype probably probably is. However, it does solve a lot of problems well (mainly Realtime and joins).
I heard Rethink is working on a more granular oplog feature,
I havenât heard this yet but their mechanism for realtime is using a âchangefeedâ that watches queries. The entire database was designed around this in mind so that the DB knows at a very low level when a changefeed has changed. From what I hear itâs a lot more efficient. Unlike the raw oplog, this allows anyone to get realtime updates without the livequery system like Meteor. You just need some kind of pubsub to send results to a client.
Theyâre also working on a software layer that sits in front of RethinkDB to give you basic Firebase like auth/permission things and eventually GraphQL.
⌠making it easy to gradually upgrade my app⌠but DB is different, you have to fully commit to one or the other.
It was actually fairly easy to migrate an app from MongoDB to Rethink. I had a client that was scared by the recent bad press of Mongo and wanted to switch to something else. Rethink was one of the ones that made migratio easy (compose even has a converter). If youâre app level code is using a facade like Post.update(docId, data)
then itâs easy to swap it over. Making the primary key _id
instead of id
prevents a lot of headaches.
To be fair, I donât understand the critiscim of Mongo design decisions to make a great decision. Iâm only using RethinkDB in new client apps to prevent future issues. This Quora post is a great summary of complaints (valid or invalid).
This is a great podcast explaining what Rethink does and how it differs from other noSQL/SQL databases:
http://softwareengineeringdaily.com/2015/08/19/push-databases-with-rethinkdb-ceo-slava-akhmechet/
I truly hope Meteor becomes the foundation on which to build JavaScript apps on. Having to reinvent the wheel, gather parts, compile, and everything else with build tools or use boilerplates is currently a nightmare. I would love to see Meteor take care of installing NPM packages, compiling, connecting databases, models, views, view refreshes, deploying and minifying, and everything else. The JS community really needs a standardized way of doing all of this that makes sense and is easy to get going.