YMMD. That summarises it very well. Strange thing is that many hipsters left despite of that, since it was too easy to drop the rest of Meteor once a lot of tech was replaced by the latest and greatest anyways.
IKR! For real⌠letâs see.
âWe have this awesome real-time front-end back-end magical tool!â
âEveryone is loving it!â
âOh no, there is a new tool that FB made so it must be the One True Way now!â
âOMG the bloggers arenât talking about us anymore theyâre talking about the New Thing!â
âWe better get that new thing working with our thing!â
âOh yea for sure! I havenât had a Twitter mention in 3 hours!! D: D:â
âŚ6 months later
"Hey now we made a bunch of breaking changes and the shiny things kinda play together!"
âYea this is awesome!â
âWhat about our shiny blaze thingâ
âWhatever, everyone is blogging about this shiny turd pile now!â
âŚ
âHey⌠what happened? Everyone is gone?â
âI think they realized that with the new shiny thing they donât actually need our shiny thing which we messed all up just for the other shiny thing but it seems to be shining so brightly that our thing now is just a thing no one cares about because the other thing does the magic and doesnât even have a frigginâ backend to code!!! WAA WAAAAAAAâ
âŚ
âWe better start a new database shiny thing like theirs thenâŚâ
âHey, you wanna go to bar volleyball?â
âNah, all the hipsters play Reactball now, donât drink and say prayers to the original FB icon so Iâm going over there tonight.â
I wished there was a roadmap for Blaze, but there is not
On the other hand, many of those abandoned Blaze packages were over ambitious (thus hard to maintain - there was burn out), and contained weird corner cases that were hard to work around (Iron Router, CFS, Simple Schema/Autoform, etc.). The interdependency and tight coupling between specific packages and versions has also been a problem. I think thereâs a reason Reactâs more in-your-face positions on business and core logic, and cleaner (almost redefined) separation of concerns, makes a lot more sense for any project you may wish to scale. Vue.js is probably just as good, uses some similar higher level concepts, and is catching on (I havenât used it yet, but given the React patent issue itâs on my radar).
CFS was a real mess, but I still love SimpleSchema. In most cases when I faced a supposed edge case, it was always my fault. The only thing I am missing is a way to replace the whole content of a document on an update. This just doesnât work, you have to use $set.
I donât dare to use VueJS yet, since its adoption isnât as good as Reactâs. It was a pity that Meteor didnât take the chance to make a tight integration with Vue when the creator was still on board.
ok but no time line maybe we have to wait for that to see what the future is of blaze, any way i like blaze
Mobile and Animation
Blaze will cater to the needs of the mobile web, including enhanced performance and patterns for touch and other mobile interaction.
Weâll also improve the ease with which developers can integrate animated transitions into their apps.
I give up .React all the way!
i would not go into panic about FB and react it is the same As Oracle with mysql, FB is not interesed in the one man shop
My main problem with SimpleSchema is just the transition to the new version - so many older packages are hard linked to the old version that upgrading is tricky (I created a dummy local package that uses the new npm based simpl-schema and exposes it as if it was the old on).
As far as updating whole documents - I have a trick for you!
updateTileInGrid (id, data) {
check(id, String)
check(data, Object)
MySchema.validate(data)
MyCollection.update({_id: id}, MySchema.clean(grid), {bypassCollection2: true})
}
There are of course some edge cases where it doesnât validate certain nested props (within an array) and clean removes those same values. There is a bug, but its actually starting to look like SimpleSchema is abandoned.
(None of my criticisms of SimpleSchema or any other package are meant to disparage - these packages have saved me a ton of time, and I could not appreciate the work and dedication of the authors more than I do.)
Thanks for the info. I guess you mean the Meteor package? The npm version seems to be maintained. But I didnât know yet that aldeed has deprecated the Meteor version. Sad thing is that the new npm version has a lot of breaking changes. Man, I had so many breaking changes in packages already when upgrading my app from 1.2 to 1.5, I just canât count them. Upgrading a Meteor app is really a nightmare.
thatâs just it: it works. Replacing it not a priority; so why spend resources on frivolous activities when we could instead spend that time delighting our customers in ways they care about?
Actually IronRouter pre-dates Arunodaâs FlowRouter, but yes, community developed packages have long played an important role in the evolution of Meteor as a framework.
Meteor didnât make their own router because the community created Iron Router, and later the community created FlowRouter, and now you can use react-router too. All of these solutions still work fine in productionâwe have two large commercial apps built with IronRouter and we have absolutely no issues with routing. We use react-router with our latest app, and we were to create a new app Blaze app (unlikely) we probably use FlowRouter.
Why should MDG waste resources creating a router then we already have three?
And it still works fine! Believe it or not, this stuff just doesnât need continually babysitting to do what it was designed to do.
And the good thing about open source software is that if a package breaks, you donât have to submit a ticket and wait weeks for a fix, just fix it yourself! And the smaller the package is, the easier to find the bug.
and often, if itâs used actively by a large enough group, someone else might beat you to it!
Iâve been doing this a lot recently with older autoform packages.
Hey,
For router part, I was not happy with Flowrouter, Ironrouter and react router.
So I was looking for something more declarative, more simple, and I saw https://github.com/kriasoft/universal-router
Iâm not in production yet but this one is really simple to use (a delight)
See how I used it with server-render package here: https://github.com/antoninadert/proto-starter
I appreciate the offer, but Iâm not sure youâd get along with our team.
Clearly you have no real understanding of why some people prefer React. Why donât you just ask instead of imagining they must have no good reasons at all? Have you ever thought you could be offending a large number of devs by underestimating their intelligence like that?