In order to build static web pages to serve interactive news applications (mostly data visualizations scripted with something like D3 or lightweight apps built with Bootstrap.js), is it worth the effort to install and configure a build system like Middleman or Grunt.js?
The reason why I am asking is because I am not familiar with Ruby and Ruby Gems at all, and do not have the time and willingness at the moment to dwelve deeper into it, as I already know Python & Javascript pretty well.
Do I need to know Ruby in order to use Middleman productively? Or should I just use Grunt? I am asking because I want to reuse the same templates over and over again and heard that this is easy with Middleman.
There is a distinct difference between Middleman and Grunt.
Grunt is a generic task runner while Middleman is a static site generator.
Middleman for example would be used to create a site with multiple URLs. You put some files in a folder and Middleman takes care of arranging them, creating subfolders for URLs, rendering layouts, compressing assets and in the end you have a bunch of files that represent the site. All this is built in.
You don’t necessarily need to know a lot of Ruby to get started with Middleman, but to get the most out of it, understand how it works and change configurations to your needs, basic Ruby knowledge is key.
Grunt on the other hand works by using plugins and telling them exactly what to do. By default it does nothing. You could think of Grunt as "framework", ready for you to add tasks. Compress these two css files. Combine these JS files and move theme over here. Things like that.
For building a complete website I recommend Middleman. In order to be able to use the templates you create in another language like JS, you could use Jade as a templating language. By default Middleman uses ERB (part of the Ruby standard library). Another popular choice is HAML, but I’m not sure if there is a decent JS compiler for it.
If you want to have really fine grained control over the output of your JS files (you’re talking about JS client side apps in your question) you can even use Grunt and Middleman together. Grunt would take care of the assets (you can have really detailed configurations there) and Middleman would handle templating, URL generation and all the other "default website related" stuff.
If you're keen to use Grunt as a base for this sort of build, you may like to look at Assemble.io.
This is a static-site generator like Middleman, but one that is completely (currently) dependant upon Grunt tasks in order to do its thing.
I believe the learning curve for Assemble.io is rather higher than Middleman. It is based on Node, rather than Ruby. However I don't believe it's necessary to know Ruby in order to get a lot from Middleman.
You may have a look to http://wintersmith.io/ a static page generator like Jekill or MiddleMan (I don't really know this one)
With Grunt you have something at a lower level: Grunt provides you tasks to automate things so you'll have to find or write the task that fits your needs.
Related
I'm wondering whether there is a nice way to continuously bundle complex javascript files in a single, customized, JS file that is then directly served to clients, sort of a "smart" CDN.
My use case is really simple: serve JS files to different web applications from a microservice, like RUM scripts (or also Google AdSense scripts, or anything else that works by importing a JS file from a service in your web application).
Problem is, at every request the JS file will be different, based on several parameters (for example, IP address of the request, query params in the URI, back-end configuration, and so on).
Solution can be trivial, for example I could manually bundle JS files by concatenating strings, and then serve the resulting file, with minimal logic or with the help of a standard template engine that handles placeholders/pre-processing within the source JS files.
I was wondering if there is a better way to do this, like using JS bundlers as Webpack or Parcel.js.
My experience in using JS bundlers is limited to their standard usage, so that use them in the build process (or at application startup), and make them write to disk the compiled JS file.
Is there anything better to use, or a best practice to suggest for my use case?
Programming language makes no difference, I added the node.js tag because ideally the backend would be developed using Express.js, but also Java or other compiled languages would be ok.
Thanks in advance,
Sure, that's definitely possible.
Esbuild (a new, fast bundler) has a well-documented Node.js API: https://esbuild.github.io/api/#js-specific-details
The two other bundlers you mention are similarly available:
Webpack has a well-documented Node.js API: https://webpack.js.org/api/node/
Parcel has a well-documented Node.js API: https://parceljs.org/api.html
Then it's just (always "just" ;-) ) a matter of hooking those up to the web framework of your choice and going to town.
I'd recommend thinking about caching in advance, though – even if e.g. Esbuild and Parcel are pretty fast, not doing work is always faster than doing work.
I've been using a grunt file to concatenate all my JS into a single file which is then sent to the client. What advantage do I have in using require calls then? The dependencies are inherent from the concatenation order and I don't have to muddy all my JS with extra code and another third-party library.
Further, backbone models (for example) clearly state their inheritance in their definitions. Not to mention that they simply wouldn't work if their dependencies weren't included anyway.
Also, wouldn't maintenance be easier if all comments related to dependencies were in one place (the grunt file) to prevent human error and having to open every JS file to understand its dependencies?
EDIT
My (ordered) file list looks something like:
....
files: [
"js/somelib.js",
"js/somelib2.js",
"js/somelib3.js",
"js/models.js",
"js/views.js",
"js/controllers.js",
"js/main.js"
], ...
So perhaps requireJS isn't worth it for small projects anyway.
Using require.js allow you to break down each part of your application into reusable modules (AMD) and to manage those dependencies easily. It is not easy to manage dependencies in a javascript application with 100 classes, for example.
Also, if you don't want all the overhead of require, check this out (developed by the same guy who created require.js): https://github.com/jrburke/almond
The answer depends on the size of your app and the end use case..
A single site.min.js payload for the front end (client) generally aims for small file sizes and simple architectures (1 single file generated from maybe 10).
back end based (server) apps are usually much bigger and complicated and therefore may warrant the use of another tool to help with managing large code libraries and dependencies (50 files for example).
In general, RequireJS is worthwhile but only if you have many files and dependencies. An alternative for use in the client would be almond. Again, using a tool like this must warrant the need (many files and dependencies).
The answer from orourkedd is also worth reading.
I am working on a pretty large node web application and realize that my workflow is suboptimal. The server side code is quite well organized into node modules. However most of the heavy lifting in the application happens on the client side code.
The project consists of jade, less and javascript/coffeescript code. Furthermore there is a bunch of css/js includes from libraries (jQuery, D3, Bootstrap, etc). What I am looking for, but have a hard time to find, is a nice tool chain that helps me organize my project and switch between development and production:
Developing mode: compile jade, less and coffeescript on the fly in node without a need for rebuilding. Include compiled code into the html as separate files. Set some debugging parameters in the server side code.
Production mode: a build script (make/ant) that compiles compresses and combines the code into static html/css/js.
Currently I am doing a lot manually with some node server code for development, and a make file for production, e.g. things like:
cat javascript/*.js > build/client.js
However this is a bit annoying and I am not at all a make/ant expert. Also a source of problems has been that I am maintaining separate html files for development and production, because they include different css/js files.
Is there any good frameworks or example projects that can help me improve my workflow? Google gave me things like hem, buildr.npm, grunt, but I am not quite sure how mature these projects are, and if they really solve my problem or add more complexity.
You can also have a look at brunch, with many plugin support
As per the website it supports the following, you can also add a new plugin if you need to...
Programming languages: JavaScript, CoffeeScript, IcedCoffeeScript, LiveScript, Roy
Pre-compiled templates: Handlebars.js, Jade, Mustache, Eco
Styles: CSS, Stylus, LESS, Sass
Linters: JSHint, CoffeeLint
Minifiers: uglify.js, clean-css
I would take a look at grunt. We use it to handle the deployment and testing of our projects.
I am in the process of writing a heavy Javascript app, which will ultimately be used by injecting one script into clients websites.
As of now I am writing all the modules in one JS file, however I am quickly finding that to be ineffective, as it feels very messy and cluttered, and I feel like the modules should all be in separate files.
My question is, what is a good approach to managing this. Should I write all the apps modules in separate files, and than compile them into one on the Server?
If it matters, I am using Node.js for my server.
First point : don't try to code everything in one file. Most big javascript applications contain dozens of files.
Use some kind of makefile to concatenate your js (and css) files. And after that use a minifier (I use Google Closure Compiler). To help debug, my deployement scripts always make two versions in parallel : one non concatenated/minified and one concatenated/minified. The uncompressed version enables the development/test onsite without any deployement operation.
This means that, as for all big application development, you need some kind of deployement toolchain to orchestrate the operations. This may be based on shell scripts, maven, ant, etc.
Secondly : use classes (without abuse, javascript isn't really OOP) and namespaces to clearly isolate your functions.
Yes, keep all your files logically separate and then minify and combine them as a publish step or on the fly when serving them. Scott Hansleman wrote a very good blog post on why you should do this here.
So we're writing a full-text search framework MongoDb. MongoDB is pretty much javascript-native, so we wrote the javascript library first, and it works.
Now I'm trying to write a python framework for it, which will be partially in python, but partially use those same stored javascript functions - the javascript functions are an intrinsic part of the library. On the other hand, the javascript framework does not depend on python. since they are pretty intertwined it seems like it's worthwhile keeping them in the same repository.
I'm trying to work out a way of structuring the whole project to give the javascript and python frameworks equal status (maybe a ruby driver or whatever in the future?), but still allow the python library to install nicely.
Currently it looks like this: (simplified a little)
javascript/jstest/test1.js
javascript/mongo-fulltext/search.js
javascript/mongo-fulltext/util.js
python/docs/indext.rst
python/tests/search_test.py
python/tests/__init__.py
python/mongofulltextsearch/__init__.py
python/mongofulltextsearch/mongo_search.py
python/mongofulltextsearch/util.py
python/setup.py
I've skipped out a few files for simplicity, but you get the general idea; it' a pretty much standard python project... except that it depends critcally ona whole bunch of javascript which is stored in a sibling directory tree.
What's the preferred setup for dealing with this kind of thing when it comes to setuptools? I can work out how to use package_data etc to install data files that live inside my python project as per the setuptools docs.
The problem is if i want to use setuptools to install stuff, including the javascript files from outside the python code tree, and then also access them in a consistent way when I'm developing the python code and when it is easy_installed to someone's site.
Is that supported behaviour for setuptools? Should i be using paver or distutils2 or Distribute or something? (basic distutils is not an option; the whole reason I'm doing this is to enable requirements tracking) How should i be reading the contents of those files into python scripts?
The short answer is that none of the Python distribution tools is going to do what you want, the exact way you want it. Even if you use distutils' data_files feature, you're still going to have to have your javascript files copied into your Python project directory (i.e., somewhere under the same directory as your setup.py.)
Given that, you might as well just copy the .js files to your package (i.e. alongside mongofulltextsearch/init.py) as part of your build process, and use package_data or include_package_data=True.
(Or alternatively, you could possibly use symlinks, externals, or some such, if your revision control system supports those. I believe that when building source distributions, the Python distribution tools convert symlinks to real files. At least, you could give that a try.)