What do you mean by
GitHub and Chrome may be more responsible for driving that changing definition than NPM
I like to hear more.
1 Like
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,
- Meteor 1.3 change how we structure and and build it. But we can’t jump into right now. It’s still a preview.
- Flux about Blaze, React and Blaze 2.
- Are we gonna use Angular of React.
- How do we use Redux with Meteor or the best practices of the React world.
- Which router I should use.
12 Likes
How about the backend part?
1 Like
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.
4 Likes
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).
8 Likes
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.
2 Likes
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
1 Like
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.
1 Like
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.
2 Likes
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!
1 Like
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.
1 Like
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.
> I'm curious why you think Rethink is much superior to Mongo.
- Joins between tables at the DB level (one of the first for noSQL DBs)
- Changefeeds make realtime easy and more efficient
- Easier for devops to maintain
- Really nice ‘functional’ API shines with comples queries (mongo is nice too but complex queries are a mess)
- Hindsight allows them to fix mistakes made by other noSQL databases
- They run Jepson tests against each release while in development
- The company seems to be very forward thinking while MongoDB… not so much
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/
2 Likes
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.
6 Likes
Joins, ok, I guess I worked with noSQL long enough I don’t miss joins that much. But it does make me wonder, is Rethink fundamentally different from every other DB? If not, what makes it fundamentally better? Or, on the flip side, does their implementation contain "leaky abstraction” that will encourage me to write bad/inefficient code? Like if I try to combine SQL and noSQL paradigm, will I just shoot myself in the foot?
I’m just playing devil’s advocate, I guess I need to listen to that podcast to give an educated answer.
But, so far aside from joins and “Changefeeds make realtime easy and more efficient” which sounds like the same as oplog+livequery… it smells like a lot of hype.
1 Like
As always, i think Arunoda is spot on.
MDG started as a full stack framework who wanted to fund his work trough hosting.
They developed the framework, it was brillant (albeit a few problems), but then they had to start making money, and so they put 90% steam on the hosting solution development. It took them loooong time, during which there was no progress on the JS framework and the JS world moved on.
At a point, i guess they decided that it was not worth it to continue to develop a framework that was not ubiquitous enough (remember their goal is to become the new Java EE !), and which was starting to lag behind the Facebook and Google offerings.
So i think they have changed their plan completely and that the JS framework is pretty much abandonned.
MDG then becomes an hosting company, which offers some sort of “distribution” of up to date JS technologies, presented in a “batteries included”, easy to manage, one line install.
I understand their move, but i’m not sure i’m sold on that.
13 Likes
I see Meteor as the low level OS for rapid web development, which offers hosting and support as a revenue stream for MDG. Not a hosting company with one click installs. I’d much rather develop a react app on Meteor, than build it from scratch with build tools.
3 Likes
DDP is good. Microservices is nice. But I don’t think that’ll be a trend in 2016 for Meteor.
We may not see much use of DDP servers in other languages.
1 Like