This summer we took time to familiarize with Meteor. We intend to start building an app in January. However, Meteor seems toe be going down hill fast as it looses its elegance and focus. In past we could start with just following the core decisions, and now we don’t know… big confusing. What choice to take now that is robust in future?
Coffeescript / js ?
Blaze/React/Angular?
Bootstrap / … ?
Folder structure?
Iron/Flow router?
Oh, And please dont say things like “do what is best for you” , because when you start with a platform, knowing “what is best”, is the last thing one does …
Clarifying the source of confusion:
The point of the above is that each non-decision or change reduce the viability of a platform. Take these two for example:
coffeescript versus js, assume 50/50 for this argument
Flow/Iron 50/50
Each of these non-decisions divide the eco-system such as Google, Stackoverflow, by half: So the inability to choose unnecessary translated 100% into 25% already ! And now, lets confuse even more by going Blaze/React/Anglular: 33% each? … .what is that of 25%? … 8% ?
What MDG is doing, is with open eyes reducing their impact to the world to 8% of what it could be! The most worrying part of it, is that MDG’s top management defends these choices… with… ahhh… technical arguments… !! Geeks always say: more choice the better. But:
Beginners say: keep it easy please. , we are confused enough with our own application
Corporations say: make up your mind and focus on the things that matter really to us: security, quality, cost, maintainability over time.
So my question boils down to this: MDG shows clearly who they do not care to support… but do they really?
Some of these questions are easy, I would say (although perhaps I’m just opinionated).
Coffeescript / js ?
With almost full support for ES2015 out of the box, I don’t see the point of using Coffeescript.
Iron / Flow router ?
Flow Router is better maintained, simpler, and works well for us. I think a lot of the Iron Router user base is legacy, and will eventually switch.
Folder structure ?
There are competing paradigms, but this really shouldn’t make a big difference to you as long as you choose something sensible (there are plenty of blog posts). They all work well enough.
Bootstrap / …
This isn’t really a Meteor question. We use Bootstrap, not because of any particular love, but because a front-end framework that you understand makes prototyping so much easier, and it just has so much bigger an ecosystem than Foundation, Semantic-UI, etc.
Blaze / React / Angular ?
Now that is a good question. We find Blaze to work very well indeed if you learn how to use it correctly, and believe that only minor improvements are required. But the whole world suddenly loves writing HTML inside the JS, so who knows.
I personally come from a Ruby world and CoffeeScript feels natural if you choose to use Jade and Stylus for your HTML/CSS templating. Choosing CoffeeScript surely won’t make you popular - so that is really a matter of taste.
If you have read the big post on how MDG stands on things, I would advice you to go for React - at least the upcoming 6 months. I’ve been a bigger fan of Blaze. Vue, might be another option for you.
Bootstrap and Fontawesome make live easier. CSS frameworks are also a matter of taste.
Folderstructure is entirely free, you should understand the load order. Basically, I use this:
client
_init.js
– layouts
– lib
– templates
lib
– routes.js
– helpers
– models
server
– collections
– lib
– publications
– methods
tests
– cucumber
– fixtures
packages
FlowRouter. The guys from Kadira maintain it excellently and it does what a good router should do - route.
I can recommend you to use Cucumber for testing (xolvio:cucumber) and Simple Schema (aldeed:simple-schema). The Cucumber package works beautifully with Chimp under the hood and with Jasmine (sanjo:jasmine) it will give you just that bit extra to make sane Meteor projects. The Simple Schema package depending on collection2, made my life easy - and autoforms are just package away.
Thank you. This is indeed the road we are going. The last one being our major concern: we lean towards Blaze and will struggle to avoid the stampede of the day
Short answer: JS, React, Pure, Packages?, Flow Router
Coffeescript / js ?
This one is easy: just use the language you already know.
If you have more experience with Coffeescript than with JS, then why not use Coffeescript?
Otherwise, just use JS.
Also, note than by default, your meteor project supports ES2015, with Babel.
Personally, I use JS.
Blaze/React/Angular?
First, you should read this: Next steps on Blaze and the view layer
Then, personally, I would recommend React.
Having the JS code and HTML in 1 file is convenient, and JS is a more powerful language than any template engine.
You can also have a look at http://riotjs.com, but then you have no official support from the meteor team.
Bootstrap / … ?
I have no opinion about this one, I never used Bootstrap.
But again, just use the one you already know.
I use http://purecss.io
Folder structure?
This is the most tricky one, especially if your project is big and complex.
I heard that making Packages can help.
Have a look at the source code of Telescope: https://github.com/TelescopeJS/Telescope
Iron/Flow router?
Any router you want, as long as it is NOT reactive (so Flow router, NOT Iron Router)
A reactive router looks convenient at the beginning, but then you keep refreshing the complete page for any little change in your data.
Read this: https://kadira.io/academy/meteor-routing-guide
@lorinthe Definitely check out the Meteor Guide as well. It’s not finished, but there is enough info in the outlines and drafts to give you quite a bit of guidance. It’s under active development by Meteor core devs and represents our most current thinking and recommendations.
So, you’re definitely not the only one asking these questions @lorinthe. Having talked with a lot of people about this, I’d suggest there are a few underlying strategic business questions which can give guidance on the tactical questions of which specific packages you should use:
How skilled is our team?
Do you need highly abstracted languages that transpile to Javascript?
Is the team skilled enough to use raw Javascript? For everything?
I made a diagram a few weeks ago that speaks to this issue, which I’ll repost here for consideration.
My hunch is that the broader Meteor community may want to outline a stack recipe for each of these. @shcherbin does a pretty good describing what a pure-Javascript stack without transpiled languages looks like.
But if you have a diverse team with designers, database admins, dev/ops, and application stakeholders, then maybe a more highly abstracted stack would be more suitable.
Coffeescript
Jade
Stylus
Blaze
Bootstrap
My hunch is that 2016 is going to see the release of various distros that cater to specific approaches, and we’ll see a lot more of the curated stack philosophy make it’s way back in.
We intend to develop an app that lasts minimal four years !
You can make an app last 10 years. And you could do this even with Blaze. However, your success rate is not depend on purely tools. You will need skilled people or generate them. If you are investing to train 4-5 people to work all Blaze, the jar of knowledge will die out in a year or so - a lot of the Meteor community has been going to React (as are other platforms, like Phoenix). That bet is safer to train these people in Meteor with React. The reason why I am saying six months is a good forecast, is that it is almost impossible to forecast the long term plans from MDG. Less than six months ago, Blaze 2 was still something to wait for. Change is inevitable. With Meteor that change is often. Design your project with this in mind.
Yes… I was hoping MDG would go for a strong, consistent and comprehensible core-model. Where advanced users could override with more complex or off track. For example MDG would go full force for Blaze, but other communities arise around overrides for Angular, React etc…
I do not understand the whole “HTML inside JS”-fad. From a business view it makes little sense. If you have a designer who’s creating templates, it would be far better to split the code so that all he needs to know about the app logic is {{#each}} and {{#if}} and let the developers do the logic. With HTML in JS, he would need to browse through, somewhat understand, and access js-files he might not know diddly squat about, and potentially mess up logic. Also, I think it makes the code far less readable!
In PHP we’ve been adding HTML in code for long time. Smarty and other template engines went to great length to split it similar to Blaze…l’histoire se répète , as the French would say
I remember PHP… that whole thing simply annoyed me. Wild " or ’ messing up your code or html…
When templates arrived I was a happy dev!
Forgot to mention another thing. How on earth do you test helpers with React? You have to rewrite your test if you change your design don’t you?
