Actually, I took a look at these boilerplate before writing my post. The documentation is really great, but I miss the automation stuff in this package, as e. g. the form is written manually.
I’ve been working more than ten years on a project, where the automatic generation of forms was crucial for the product to deliver in time and to ensure consistency. Therefore, I’d generate even the simplest form automatically 
And I don’t like to write repeating HTML code 
That’s where https://github.com/vazco/uniforms comes in - it’s AutoForm for react, works really well, and is very well supported. Just drop it in, configure your forms to build from your schema, and you’re all set!
In my opinion it has to do with tradeoffs, it’s hard to build a framework that fits every use case. You try to please the new comers and make it highly opinionated and few years down the road advanced users will claim it’s tightly coupled and not flexible. you make flexible and the new comers will say there are many ways of doing this and that. So it’s about tradeoffs and balance, and I personally think Meteor has a nice balance, try starting a node.js project without a framework and watch the numbers of decisions you need to make before even hitting the hello world url!
Furthermore, it takes considerable about resources to create and maintain the scaffolding you envision given the churn within the node.js ecosystem, you start a project today and you never know which NPM package will make it to the next year! the amount of thoughts, work and documentation that went into creating and maintaining something like the Pup project is admirable and if you observe their documentation you can see how much of their previous work is considered outdated less then two years down the road!
With that said, my approach is that if I want a simple app or a POC then I’d go with Blaze and if I want something that could span multiple months and involves multiple developers, then I’d go with React and follow the Meteor Guide and use Pup as a starting point.
@hwilson uniforms is absolutely cool. In combination with a (yet unknown) unitable component, it would form a prominent part of my vision.
You’re right, it has to do with tradeoffs, and it’s impossible to build a framework for every use case.
But I’ve seen mechanisms in Django and Rails more than a decade ago, which I’d like in my preferred world, namely the Meteor universe.
And the churn in this ecosystem is horrible, it’s a full-time job to stay reasonably current. It might be my vision of Meteor (or a product based on it) to be more opinionated – just like VulcanJS, where you don’t have to think about lots of the questions that arise, when you start a Meteor project from scratch.
Yes, I think it was possible to build and maintain a scaffolding project in Django and Rails but near impossible to do today with JS and Node.js ecosystem due to the rapid change, in fact it’s hard to even keep a simple project up to date.
Let me give you some specific examples from my own experience with the react/npm and node.js ecosystem. If you started a project last year, this year you’d probably need to:
And there are many more, notice that these are all core libraries, routing, view rendering, data grid, forms, and UI components, they all required major rewrite within a year. If you go back one more year, you’ll probably need to rewrite your entire project since now we’re using imports and ES6. And frankly, out of all those libraries Meteor has been the most backward compatible, I had a project written in Blaze few years back and I just run meteor update to 1.6.1 added few nm packages and it worked again!
So I’m not sure how anyone could create and maintain a scaffolding project under so much churn.
I see the point. Thanks for sharing your experience. Fortunately, most of my projects use Blaze, so updating to Meteor 1.6 was a lot easier
I’m a big fan of creating “templates”, even though every organization will end up requiring their own version because every organization’s library needs are slightly different.
I agree that there is a fair amount of churn, and you will be updating your template significantly every six months to a year. The good news is that your updated template will be more functional and/or performant!
I think the Pup Meteor template is pretty good.
I based my meteor-application-template-react on pieces of it, though I wanted Semantic UI rather than Bootstrap.
@qnipp I just realized that VulcanJS created by @sacha might be the closest thing to what you envision.
Check the docs, Vulcan is also using schema to generate most of what you looking for!
@alawi VulcanJS made by @sacha is great. According to my research it is the most complete “product” I’m looking for.
It currently misses the following points of my wishlist:
But it would be worth to extend them there
Thanks! That’s some good feedback. Actually, there is a scaffolding tool WIP but it just needs that last 10% of work to update it, test it, write more docs, etc. I agree it’ll be a great addition to the platform, but in the meantime since you usually only create 3-4 collections per project anyway I get by with copy/pasting and adapting existing projects.
As for the table component, it’s true the current Datatable doesn’t have sorting, but it wouldn’t be that hard to add. I’d say one afternoon’s worth of work maybe, if you’re not too familiar with the codebase? And it does have built-in search, pagination, smart content cells (it’ll display objects, strings, links, images, etc. automatically) and can be customized as much as you want:
And it’s true that Vulcan doesn’t really have real-time updates but 1) it’s still Meteor so it actually does have real-time as long as you use it like any other regular Meteor app and 2) I can probably count on the fingers of one hand the number of Meteor projects I’ve seen where real-time was actually needed, as opposed to just an optional nice-to-have.
Definitely use Vue! It’s simpler than React, has better performance for large pages, and has great documentation and tooling.
Oh, I see, scaffolding is on the way. That’s nice.
I’ll take a deeper look into VulcanJS, and maybe – I don’t want to promise it – I’ll take a look into the sorting capabilities of the table.
You’re absolutely right about the real-time updates. As Meteor developer I’m used to have them, even if the applications don’t need them. I was expecting them in VulcanJS, as it is based on Meteor, but after digging a little bit deeper into VulcanJS, the absence of this feature is obvious, as VulcanJS doesn’t use the Meteor data layer but Apollo/GraphQL.
@sacha Thanks for the great work!
Sounds good! We actually have a new getting started tutorial that makes everything much easier in the beginning: https://github.com/VulcanJS/Vulcan-Starter/
And for the table, you can always start using the Datatable component without sorting now, and whenever sorting is added it should just work automatically when you update Vulcan
@qnipp I came to the same conclusion myself, it is too hard (and thus costly) to start a Meteor/React project from scratch without some kind of framework. For the past year, I’ve been trying to address this issue by creating a starter framework that I’m calling VXFrame. This is a set of over 200 Meteor/React/Bootstrap components, third-party packages and back-end support that addresses everything you mentioned. There is no generator per se, but the components are designed to be selectively overridden and extended.
We did something similar with react and bootstrap internally. I think it’s largely has to do with the react ecosystem, you need to get a router, grid, forms, state management, and many other third party components etc and also you need to maintain those as I mentioned above and ensure they’re working well together… or you can go with something like AntD.
Do you’ve the VXFrame open sourced by any chance so I can compare it to what we did?
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.
