My first post! I have been using Meteor since last September and I have already built 2 apps with it. I am currently building an app with Mantra. However, over the last month or so, I have been looking into React, Redux, and all that jazz. My concern is with all these changes coming to Meteor land from JS land, what would actually be left of the Meteor framework in the whole stack.
We have already replaced Blaze with React
Meteor calls / Publications will probably get replaced with GraphQL
Client-side state management could be done with Redux or Rx.js Observables
Webpack for bundling too could be done
The only thing I see is the DDP layer for reactive / real-time data pushing from the server. What I am hoping is that there should be something exclusive to Meteor which will attract more people to it.
Just curious. Maybe there is something that I am not aware of. Would love to know.
Imho the biggest asset of Meteor is the promise of better developer experience than in the rest of Node.js environment. As long as these new parts of the stack are managed by Meteor to cooperate with each other this way, Meteor will be fine.
Imho all that brings you far away from the quick start with meteor. For instance, meteor replaced for me Ruby on Rails for this reason and it feels as these frameworks have one human approach to build apps and when you replace it with react, redux, webpack etc it seems as you dive in pure programming, where you really don’t need any frameworks and I guess it’s a good for the hight performance apps. But I personally prefer, when frameworks take away from me all the routine tasks and make me free just to build my app.
I prefer if MDG will continue to keep meteor path as simply as possible, but of course left backdoors for advanced user to dive in all this node.js stuff to set up their apps for the hight performance and scale.
But you don’t have to use any of those things (React, Redux, Webpack etc), you can still build using Blaze and atmosphere packages.
However, as apps get more complex and your requirements get more specific, React, Redux etc. make your app easier to write and maintain - you can get exactly the behaviour you want rather than trying to bully say autoforms into doing something it isn’t built for. I’ve wasted way too much time in other stacks trying to make them do things they don’t want to!
TL;DR old-school Blaze DDP Meteor for prototypes, MVPs, weekend projects. React/Angular, Redux, Apollo for bigger apps and things that you know you’ll be maintaining for years.
Meteor can’t be called a framework if all it does is bring various technologies together. Anyone could do that with webpack without being tied to Meteor then. For it to be called a Framework, it has to provide something that will bring people to it. Over the last one month, I have come to realize that most of the initial parts of Meteor are being moved out. Except DDP!
I’d suggest listening to the recent Transmission podcasts to get an understanding of what the Meteor framework offers going forward. Particularly the episode that talks about Apollo and the episodes with Geoff Schidt and Matt DeBergalis where they discuss all of this in detail.
I’m thinking Meteor eventually will provide clear abstractions for putting all these technologies together, thereby reducing complexity & making development quicker.
As of this post, in approximately 52 issues (give or take a few issues, late additions, changes, features cut, marketing decisions, weather outside, etc.)
True. The world of Web-development is CRAZY. Even its core parts ( HTML5, CSS(SASS, LESS) and Javascript (ESxxxx)) are constantly changing. The same is true for popular libs and templates (Bootstrap, JQuery, Underscore). And there are thousands of other frameworks and libraries evolving all the time. So no need for another closed architecture right now.
IMHO, Meteor is really evolved into true open architecture for web development like IBM PC many years ago was for computing. So, if Meteor is motherboard, NPM comes as PCI board in the 1.3 release. It had to be wrapped with PCI-to-Meteor adapter before
Apple way (we will do everything in-house) would not work well here.
That said, I would truly vote for keeping all Beginner path resources (Blaze, etc.) available in the future.
Meteor is a way to quickly build modern web/mobile applications. Think about this and let it sink in. This means the individual technologies don’t necessarily matter (they do, of course, it’s just not completely about them).
Meteor will flourish as long as you can continue to 1) rapidly prototype and 2) reliably scale-up realtime, reactive applications (as @tomRedox describes), and as long as there’s an active community (as @vonwao onwao correctly points out).
Thats what I want to see without the fuzz of Webpack etc :
LiveReload
HotReload
Splitting project into Separate files which are loaded when they are needed
SSR
IDE Support with full code completion let it be based as you would get with TypeScript. That way you just define variables once and after that you simply have to choose. THAT is a great developer experience. Just define a module with public members and leave it alone. You can reuse it after month without knowing how you named the members Thats how it was years ago with Flex btw.
