I love this talk, I’ve watched it few years back, I think it hits the nail on the head!
But perhaps they need to add a sequel…The Paradox of boredom that is when advanced users get bored and want more choices 
. Thus we’ve the real paradox, the yin/yang between freedom/choice and limitation/opinionation!
I believe that Meteor is still easy, you can still have an app running with only 1 file. The problem with Meteor was that it was for hackers not enterprise level applications, and while it was good to develop something in a weekend or 2, what happened when you had a team of 10 people working on it. This is why they had to ditch their data layer to GraphQL.
But this is what we loved about Meteor in the first place, this is why people with very less programming experience could catch it and do wonderful apps, because it was easy, it was that magical feeling I thought I lost in the world of enterprise PHP apps.
I’m working for over 2 months on a boilerplate that would keep the same simplicity of Meteor, have a powerful scaffolding tool, powerful debugging tools and self-documentation abilities.
I am now torn between using GraphQL or not, while I understand it’s beauty, it’s immense advantages, it’s still something that most applications will not need, most apps communicate with one database, and maybe some other external API’s and that’s it, something Grapher can handle with ease.
I’m also debating whether to use GraphQL or not. First it’s over-hyped and rational decision making usually decline when it comes to the adoption of hyped tech. GraphQL is designed to build a flexible and maintainable API gateway, that’s because large platforms with several teams require that level of flexibility. But for smaller apps/teams it might introduce unnecessary complexity.
One of the beauties of developing within the node.js ecosystem is that you can take a JS object all the way from the UI to the DB without having to do type conversations, in Java for example, the object needs to converted to Java bean then using ORM abstractions converted to a SQL table, and in-between you’ve to do a lot mapping back and forth. GraphQL is re-introducing this specific problem, a lot of boilerplate code is just doing this mapping and implementing CRUD resolvers, that’s why a lot of backend tools are being reinvented just to automate these kind of tasks. Here is a project (GraphQL Prisma) that’s doing exactly what hibernate in java was doing, which is basically creating an ORM layer. To justify the added complexity it has to solve a real problem and the only problem I see is building something similar to the API gateway that Netflix/Facebook have, it’s no surprise that both companies wanted to improve on rest. But for the rest, methods RPC with JS objects all the way are much simpler and practical in my opinion.
Thanks for sharing Pup @borntodev. Also thanks to @philipmjohnson and @alawi for sharing your thoughts on the kit 
@qnipp Can I ask what you’re trying to build (and at what speed)? It may help to shed some light on what’s missing in something like Pup and others. From what I’ve gathered forms, tables, and admin are missing at the moment…anything else?
I have a prototyping boilerplate I use to get projects started. I posted it here: https://github.com/robertdavid010/meteor_boilerplate
VXFrame isn’t open source yet but we’re considering it. I have a meeting planned with a colleague of mine and we’re going to discuss the pros/cons.
A couple of things to consider, most of which will make sense. First, VXFrame is very opinionated because it is trying to simplify development through conventions. It well-suited for multitenant SaaS and it has a lot of emphasis on account management, user profiles and domains.
But really key is that this set of components is very tightly related to the CSS so that they lay out correctly (repsonsively) on different devices. For example one of the components is called a SlidePair, a list of elements with images on the left side and the “body” of a record on the right side. SlidePair behaves differently on phones and tablets, so the developer doesn’t have to worry so much about responsive design as long as the components are used as intended. This aspect of it, layout and animations, has been a big cost in the development.
Another key is that there is a lot of emphasis on input controls, select fields, date widgets and so on. They all work together when contained within VXForm controls, and they can either work dynamically (i.e., update MongoDB as data is entered) or traditionally, with save/cancel buttons at the bottom of a panel or modal. Validation rules apply either on client or server.
Finally, there are very strong standards for how Meteor methods create results. All VXFrame server-side functions construct a standard result object that has certain mandatory fields, including a international message key, variables, the name of an icon, a severity and so on. This information is meant to trigger a push-notification, via the stupendous PNotify package, to communicate with the user.
You could try my meteor scaffolding tool: maka-cli
You can specify if you want to use graphql, material-ui, restivus, reflux, server side rendering, and a bunch more. It’s super geared towards react at the moment.
It’ll scaffold out your routes, templates, components, api concepts, etc.
Wow this looks great!!!
Why do you think it’s overhyped ? I honestly think it solves most of the problems of a BIG APP, self-documentation, has support with the most popular languages out there, can be used for mobile devices and others.
But since it’s a Facade/Gateway/Front Layer not an Implementation Layer, it can be put at any time and you can migrate to it iteratively, I digged into it and it can be used hand-in-hand with Grapher beautifully, Grapher will query the database efficiently for you, and GraphQL can use it’s field resolvers to access data provided by Grapher. This would mean that Grapher will be split in more packages, since it does many things that may not be needed by these scenario, such as exposures, and client communication, but that’s another story.
What is truly missing in meteor is a good scaffolding tool, thanks to @maka and @sacha we already have some good starting points.
I agree it solves most API problems for big apps, in fact I was the first to advocate it for an app we had with many clients integrating to it (consuming it’s public API). I say it’s hyped because like all other technologies it’s going through the hype cycle. At the early stages of the hype cycle the technology potential, value and use cases are all inflated to encourage adoption. In addition the excitement of trying new stuff, there is also the fear of being left behind, so higher emotions and biased info result in growth. I’m running a small shop and I don’t have the luxury to fiddle a lot with new tech or add any unnecessary complexity, so what I look for is clear assessment of the tech, what problems it’s solving, what are the pros/cons, do we’ve that problem, how costly it is to adopting it, etc.
Here is what I think is a manifestation of a hype:
So all I’m looking for is an unbiased objective view of when this tech should be incrementally added to an app and I think that’s a fair ask.
@themeteorchef What I currently miss most is something like an administration interface to manage my data. In all of my apps I’ve some data to handle (like shop articles, event registrations, etc.). I’d like to define a schema and have the ability to insert and edit some test data. I’ve used yogiben:admin with success, but it relies on some out-dated packages like iron:router as well as on global everything (AFAIK), like it used to be with Meteor < 1.3.
Thanks! I’m always working on it so let me know if you find a bug or have a suggestion.
I know this feeling. Once you just take the leap to react, it get’s much better. I don’t see any reason why you have to use vulcan or apollo or astronomey. Why can’t you just do React + vanilla meteor back-end? The only real difference would be react instead of blaze.
Pup is probably the best supported option and won’t make you use graphql. Everything else non-graphql seems abandoned.
@qnipp Is this similar to what you are looking for? https://github.com/msavin/Mongol-meteor-devtools
@rd010 I know this, it’s part of the Meteor Toys by @msavin. And it’s not the kind of tool, I’m looking for. It doesn’t consider the scheme and has no tabular list view. But the Meteor toys are a great tool for lots of other tasks, like impersonation
I am learning Meteor. Using Windows 10. I’ve been learning the React flavor (skipped Blaze, but that may have been a mistake!)
Your comments above inspired me to try the maka-cli scaffolding tool.
I encountered a problem installing maka-cli:
meteor npm install -g maka-cli
At first, that appeared to be working perfectly, but then the following error was returned:
C:\Users\e4tless\AppData\Local.meteor\packages\meteor-tool\1.6.0_1\mt-os.windows.x86_64\dev_bundle\node_modules\maka-c
li\node_modules\fibers\build\fibers.vcxproj(20,3): error MSB4019: The imported project "C:\Microsoft.Cpp.Default.props"
was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
I do not know what this file is, or what it should contain. I assume it was supposed to be obtained automatically from the NPM site. I don’t know how to grab it directly.
Anyone know how to resolve this?
Thanks in advance for your help!
Incidentally, the free version of Meteor Toys is awesome.
The down side is that it only works if something renders to the browser, and frankly, I create so many bugs in components that crash the program build that it doesn’t help me much. Anyone know of other debug tools that reveal clues to bugs prior to render? The error messages in command window help if it is a javascript error, but the components mistakes seem less precisely reported.