Hi all,
I’m a front-end developer who is trying to find a way to creep Meteor into my company’s workflow. I moved them from Grunt to Gulp and I’ve done very well with all the options that are offered but I want to adoptive Meteor as a front-end static site build tool (for now) as a foot in the door. My boss is very interested in Javascript, everybody on the team already knows it…I want to take website front-end mocks to the next level as long as I can get the CSS, JS, and HTML for individual views.
I’ve looked into https://github.com/frozeman/meteor-build-client and it looks like it could be the solution but I was wondering if there are any other alternatives to use Meteor as a task-runner or if there are tutorials for writing something like this on a case-by-case basis (sort of you would with Gulp)?
Ideally I’d like something that would:
handle most operations a normal task runner would: copying, combining partials, minifying or exporting with sourcemaps
export each view as a static html page
allow me to leverage the plugins meteor offers while in ‘watching mode’
take whatever data I used to feed to client and export that as static text
export the entire project to a location nearby or onto the Desktop
I understand that’s not what Meteor was designed for but this would be a great way to allow influential team members to bring Meteor into the normal web dev workflow and it seems totally possible, am I missing anything?
Well, as far as I know, meteor does not support custom build routines, the link you provided achieves the “client only” build with bash scripts.
Also Meteor was not meant to build static sites, thats is like taking a bulldozer for a nice chill ride around the sea border.
If you want to bring Meteor in to your team, I don’t think this is the best approach (lot of hacking around, to use it to build static sites), stay with gulp, it was meant to do exactly this! I think you could salvage the view engine of meteor and use it with gulp.
If you love some things meteor does, lets say event bindings, it is pretty easy to do - with jQ and underscore.js.
bindEvent = function(evt, element, fn) {
return $(document).on(evt, element, fn);
};
events = function(events) {
var oKeys = _.keys(events);
var oValues = _.values(events);
for (var i = oKeys.length - 1; i >= 0; i--) {
var evt = oKeys[i].split(' ')[0];
var element = oKeys[i].split(' ')[1];
bindEvent(evt, element, oValues[i]);
}
};
If you guys do static sites or sites with no need for live data, don’t try cramp Meteor in to everything, that is just wasting resources.
I don’t have a solution for you, but I wanted to state my thoughts on this:
After working with Meteor for a while I absolutely hate going to back to using Grunt (in my case) for anything. It just feel so archaic to have to set up each and every build plugin again and again for every damn project… That’s just annoying once you’ve gotten used to Meteor’s fantastic “add package and you’re good to go” build model.
I don’t know how we’ll accomplish that, but we need this powerful package + build model for the whole web, not just to build the sites / apps that all the other Meteor components have been built to power best.
Plus, as @j0e says, if Meteor’s build process could really be extended to fit “all” web use cases, then that would be a fantastic step in the door for Meteor for all kinds of projects. Or at the very least it would benefit those Meteor components greatly because of the use and involvement of so much more of the web dev community.
I don’t know what exactly it would take to make this happen, but I am certain that it would be worth it. Maybe the way to do it is to simply replicate Meteor’s build tools and process. Maybe it is to extract those components, just like DDP can also be used standalone. And maybe it is to simply improve and extend them as they are and where they are, if that wouldn’t take much. I don’t know, others here will be able to speak about that more knowingly and specifically.
But I’d get involved in making it happen, ideally with some guidance from the technical/architectural masterminds here.
To clarify we do way more than static sites, but some clients we have prefer to implement back end logic with completed front end markup. This workflow is obviously more laborious now that I know Meteor because to I’m doing double the work and supporting the clients’ Dev team when they aren’t creative enough to work around simple solutions.
If I could seed a database and allow a view to create loops versus copy pasting multiple things I’d be one happy guy. And by cutting my time down I could win my company over.
That said, I understand your metaphor about driving a tank around a boardwalk…but that doesn’t mean its impossible. hell, maybe driving a tank around a boardwalk would be kinda fun.
hmmmm do you know http://emmet.io? It is super cool, although it is not as elaborate as blaze templates, but is awesome for rapid prototyping of static templates.
Also keep in mind that meteor is not creating static html files for your templates it mashes every template in to one compiled javascript file! Look at, lets say handlebars, it does the same - it is not generating html file but a javascript file I don’t know of any front end templating lib which would generate html files (weekend hackaton maybe?)…
hell, maybe driving a tank around a boardwalk would be kinda fun.