Wow, that’s exactly what I need. I’m in.
Likewise. This would be awesome!
What happens when there is a breaking API change in React in the next 3 years? I feel like there have already been several just in the last year.
5 Likes
The React team has been great about putting console warnings for several versions to give people way advance notice of breaking changes.
2 Likes
Yes, I agree they have been great about that, but the claim of not having to change your app for 3 years seems physically impossible. It seems to me that app maintenance will hopefully require a minimum of changes, but it will never be absolutely none.
4 Likes
And why is not changing your app at all a good thing? If you are actively trying to improve it thats defintely not the way to go. I agree there is a limit to this tho.
1 Like
I didn’t said absolutely none. I mean in the architecture. There won’t be big changes to the react core.
Specially there won’t be feature removals. React is the only hardest dependency in Mantra. We could change the state management layer without breaking the app architecture.
In mantra things are laid out into smaller pieces while with solid integration points. So,
- UI designers can develop the app without worrying about the app.
- Developers can write UI tests to ensure designers are not breaking the UI.
- Developers can write tests for business logic without worrying about UI.
- Integration devs can write tests to see whether UI and business logic mixed together.
I know data later can be changed. I predict in late 2017 meteor will be all GraphQL and you guys will drop Tracker. I bet you will go with something like Rx.js
So Mantra is ready for all.
Three years is superbly doable.
I don’t wanna change my apps for next 3 years.
5 Likes
When do you think it’ll be ready on a more official level? That is, full documentation, tutorial, bugs squashed, etc?
I am more interested into that “Mantra-Tutor”
3 Likes
Base is ready.
I think we can do it soon.
7 Likes
MDG probably feels the frustration too… we are still stuck on version 0.10.x of Node.js, which was first released on 2013-03-11.
The current stable version 5 was first released on 2015-10-29, and version 4 LTS first released on 2015-09-08.
You can see the Node.js release history here: https://nodejs.org/en/download/releases/
The official Meteor 1.3 release will be big news. However, if it doesn’t come with an upgrade of its essential foundation, presenting it to the world as cutting-edge technology would be disingenuous.
We are all feeling constant pressure in this ever-shifting JavaScript ecosystem, including myself. But I think we need this core upgrade (even if it’s largely for marketing purposes).
3 Likes
Thanks for writing this @ffxsam! Just getting into Meteor, coming from a PHP environment (Yii framework). The need for a development platform that can build mobile apps is becoming eminent for our company, and Meteor seemed to fit perfectly.
But probably my timing could not be worse, landing here while a turbulent repositioning is going on!
My decision to start using Meteor was because of the thin boilerplate and Just Works feeling. Having a great package repository (atmosphere), strong and friendly community. Be able to use techniques to keep my lines of code to a minimum with Coffeescript, Stylus et al.
And of course a development platform with one of the best slogans:
Meteor is a full stack, opinionated, batteries included application development framework. It gives you a radically simpler way to build realtime mobile and web apps, entirely in JavaScript, from a single code base. Meteor has it’s own package manager with nearly 10,000 packages, an active community, and a whole new approach to dealing with data over the wire. All of that comes with no loss in access to the broader javascript community and toolset.
Since I knew (know) virtually nothing about the inner workings and to help getting things going with Meteor I started lurking on the forums, Medium and so forth. Not wanting to start with the soon to be replaced Blaze, React seemed to be the preferred UI layer. But most of the docs and packages use Blaze, and because of the turmoil most development on these great community packages appear to come to a grinding halt… So that was a bit of disappointment, but very understandable.
Anyway @ccorcos wrote several great articles about the use of Coffeescript with React, no JSX needed. React UI templates that are clever, perfectly readable, no bloat, but for a n00b like me in a new environment just not enough insight to continue like that. So back to square one again…
Now I see one of the top contributors @arunoda coming up with Mantra, probably advisable for all advanced
Javascript developers, but for me it seems to take away all the magic Meteor offers, with all the imports, exports, injectables and so on…
Reading that Atmosphere might die soon is also one of the things I can’t understand, this is very valuable for the Meteor environment!
So all in all currently I’m not productive at all! Probably the best advice to myself would be: Stay away from the forums for a while, use the Meteor guide and start getting productive… But that seems hard as well 
if you want to be involved!
5 Likes
Well, you don’t need to change any Meteor app for the next 3 years… as long as you don’t want to change your app for the next 3 years. In 3 years time you’ll still be able to run Meteor 1.2 and build apps as you do today. People are changing their apps because they want to use new technologies like GraphQL and JS Modules. So basically your guarantee is the same thing as saying: “You will not want to change to new technologies for the next 3 years.” That’s a promise you just can’t make. Remember a year ago nobody had even heard about GraphQL.
2 Likes
Meteor provided nice transition for me as self-learning individual with half a year of PHP experience learning Wordpress’s best practices.
The initial style of 1 big blob of JS with E2E reactivity was nice experience how to learn basic principles of Blaze reactivity.
But that beauty can fast degrade into unmaintainable product if we dont focus on proven maintainable patterns.
And it is not just Meteor thing, JS is very well known that there is no handholding nor enforcing of architecture.
You need to learn the correct ways of architecting systems and then apply it to Meteor. The template level subscriptions were 1 huge step for Blaze enabling us to break apps into self-sustaining components. We can say it is kinda React-like, but in Blaze what you pass to child is not just prop, but it is fully reactive => it is more like state.
That’s why Blaze+ was created I think, so you can differentiate between prop and state usage in Blaze.
All towards granularity and maintainability. Same with package architecture - it is nice way how to at least somehow gain control of load order etc. But still behind ES imports. Which are now coming. So I am looking forward to kinda abandon meteor packages as containers of actual JS and maybe move towards them working as umbrella packages - naming groups of JS code so we can just add/remove various package combination to easily break our apps to microservices without need to rewrite actual code, just by adding and removing packages.
Regarding various Flux/Redux/RxJS technologies, I feel like currently Tracker is kinda close to RxJS, but I am not sure what is the actual representation of local store I would like to use or what would be best.
-
If we are going with mmutable Redux, that seems as nice way how to keep 1 big Atom state. If there are some standards created so the Atom is divided into Collections/ReactiveDict/ReactiveVar/Custom blocks and used as central store for client state, it could be interesting. But that would require from MDG to provide some kind of abstraction on DDP client side which would let us easily connect to events received over DDP and add direct Redux integration. The added/changed/removed events should not be problem for merging Immutable state. Also it comes with Redux basic reactivity of listeners.
Than the work to rewrite current ReactiveVar/ReactiveDict to use this new store instead of their own. And write some abstraction so current Collection.Cursors methods will have their Redux pairs with same name for 1:1 replacement. But than some facade would need to be done for all Blaze used collection API calls, or Blaze updated to use listeners instead of tracker stuff etc.
But for React it would feel really native and I think most performant. Especially if we prepare some nicely documented easy call to put into ShouldComponentUpdate which would describe what given component needs. So it diffs current and previous immutable state to know if this child needs to re-render too (Blaze have this functionality kinda built in when you use Cursors find/forEach/map - so it does not re-calculate every item in iteration, just the one affected by change at least for top level). -
RxJS seems like community maintained kinda Tracker way, so it can be nice choice to write just some abstraction layer and replace Tracker by it, so MDG does not need to maintain another custom blob.
I kinda hope MDG abandon most of their custom solutions and replace them with external well supported libraries so they can focus on tuning deployment, customer service and write abstractions/integrations of 3rd party libraries.
Result should be E2E framework/platform with possibility to swap various pieces based on our app needs while using the same API - some kind of Meteor standard ORM.
And Mantra seems to be good starting point for new developers who wanna learn how to architect their systems.
React is doing 1 thing right - teaching/enforcing people to write encapsulated modules/components.
Blaze learned from it and now we can also write components with data management in them and compose them as we want, but it is not very well documented and far from enforced. Well these patterns are not there for long but they are quite powerful.
It would take a lot of resources to teach people how to use them in Blaze and it would be kinda copying the work React is already doing.
I am myself still using Blaze, but our take on Blaze is not the one from Todo example, but quite few rules and controller level pattern we have to use, to get our app into kinda maintainable state.
Back to Mantra - that is kinda direction I would like whole MDG to take - easy replaceability and well defined APIs/patterns to be maintained between multiple areas - so we can easily replace every part without other subsystems noticing.
And from maintainable point of view it is gold, if you are planning to develop something what need to be changed in future.
Better managers in IT already know that BDD/TDD heavy environment does not feel like it from start, but it is much more time efficient for medium and big projects. Every piece/module need to be testable so you can make changes without throwing away big $$ for army of testers every time you make commit. So not only with every new functionality, but also bugfix etc…
Same goes with DRY principle - which in other words mean - abstract every functionality to nice little testable module and documented API, so you can reuse it in whole project and change will be reflected everywhere. Module easily tested and also whole project easily tested by integration tests to check if you did not break something by changing this little module.
You should be able to create umbrella package to group few modules which always need to be together so you can easily add/remove them from actual app instance to deconstruct it into microservices when you start to get some load per functionality. For example you need some worker style jobs, but still in Meteor, so you can remove these packages from main app, add to main app some meta-package which define related Meteor.calls to do ClusterService.call.
And create separate service from these removed packages to scale the microservice independently of main app.
I dont know if meteor packages would be best for this, or we would be doing npm umbrella packages. But I think this is Mantra trying to discover - the good balance.
So for me, highly volatile library environment is nice, but the framework high level API should be stable and should enable us to swap libraries without much efforts if it is possible.
Still I would like to see fix for DDP removing documents to become somehow signalled for end user on client side - when is the time to safely re-render view knowing that there are no more document artefacts from the set before re-subscribe. Currently subscription isReady when new documents arrive and old ones are still in the collection.
Other thing I would like to see is a nice explained way how to do non-reactivity in Meteor - how to describe it - user initiated refresh of publication server side. When I was reading Medium article from @ccorcos how he is doing anydb custom refresh and it feels like this is the way I would want my non-reactive subscriptions to work.
User subscribe to publication. And than when he want to refresh, he call method which would initiate refresh:
- No need to keep cursors open for observe when we just fetch() them once in low level publish api, sync with mergebox help and throw away to empty resources if they are highly user related
- If they are kinda shared, it would be maybe wise to keep them open and just somehow re-fetch if it is possible.
More patterns I seem as very valuable for the future:
- current Meteor oplog issue suggest breaking not only application to instances, but also Mongo to multiple databases - as it would enable us to lower the load of parsing all that unnecessary oplog traffic which is not used in our application instance. That would kinda require/suggest possibility to connect to more DBs with oplog enabled.
- or 1 step deeper - Template level DDP connections - so we can on the fly connect to external apps by simple rendering template which use data from external app. As a workaround for not being able to oplog more DBs (I remember something like this way it is not so “realtime”, but for most uses enough)
- somehow enable us supported way to create kinda static pages, which will not be using DDP or any “expensive” resources by default, so we can create Meteor static pages using Blaze/React which will be just rendered by default client side (optionally server side) so we can do native landing pages.
And opt-in connect to DDP after we request it from client. Currently I can think of just some hacky way how to do that maybe with Picker server side routes, but something official or documented would be nice. I think that would be huge business value so businesses can develop anonymous (resource cheap) pages in Meteor natively. As it is not so easy to send all needed libs/scripts to render even basic Spacebars site.
Or just simply enable us to toggle DDP off and bootstrap page without already initiated DDP connection.
Maybe even some basic practice/principle to disconnect DDP after Meteor.startup on client so it would connect to start than turn off and connect when needed. Something like this but not hack way http://stackoverflow.com/questions/23780110/how-to-turn-off-and-on-ddp-requests-in-meteor (@faceyspacey - how it ended up ? ). In the link is described how it should be possible to set invalid DDP URL, bootstrap from server and than change it when needed. This could be the way how to do static page which subscribe only when user perform some action which need reactivity so we can programatically turn on DDP - when it is really needed.
TLDR 
1 Like
The sentiments expressed by @ffxsam are exactly why I’ve decided to use Meteor with Angular2 for my apps.
@Urigo (and other’s) are doing a fantastic job over at angular-meteor.com and now that Angular2 is in beta and the docs are pretty solid, I feel reasonably comfortable moving forward with it. Google hasn’t given me a “3 year guarantee,” as per @arunoda with Mantra, but I’ve had three solid years of use (and counting) out of Angular 1.x, so I’m hopeful.
What I like is that now I can just focus on building apps with a relatively stable framework while utilizing all the goodness that everyone came to love with Meteor from the start – build ecosystem (which is even better in 1.3)/Isobuild, DDP, accounts, meteor tool, etc. These keep getting better while the front-end – read: where I spend the majority of my time – is more fragmented than ever.
1 Like
But that would require from MDG to provide some kind of abstraction on
DDP client side which would let us easily connect to events received
over DDP and add direct Redux integration.
we’re working on this idea here in this thread. There is a basic proof of concept, and @lai is working on a way to leverage Meteor’s own optimistic UI, let us know what you think.
1 Like
I was going to write a lengthy response here, but I don’t have the time because I am reading this instead:
Someone told me that I need time-travel debugging.
6 Likes
Was it your future self?
7 Likes
This is one of the killer features of Redux and I’m looking forward to checking it out!
There is a free course on egghead https://egghead.io/series/getting-started-with-redux by dan himself