Is preprocessing static resources through middleware (using express) a good idea for production environments? From my understanding the middleware stack is run, in series, for every request. Wouldn't that mean then that preprocessing middle would regenerate a static resource (ie some_styles.less -> some_styles.css) after every request? If so, would it be better to simply preprocess through a build system such as grunt.js in advance and serve those files? I'd like the final rendering of the css and js to be concatenated to one file and minified.
Also, is it worthwhile to pre-render html from templates (such as jade) on pages with only static content? Or is that more trouble than it's worth?
The easiest way to handle CSS and JS preprocessing and minifying is through some sort of build system, be it grunt, cake, etc. It also might offer some performance benefits; at the very least, it reduces the workload for your server.
For my projects, I have tasks in my Cakefile to handle both CSS and JS. These are invoked by running the build task, and just output to a directory of static files that is set up through app.use("/res", express.static("RESDIR")).
As for pre-rendering HTML, it will offer a performance benefit. Unless doing it is very complex, I would go ahead and pre-render everything you easily can. It is far, far simpler to do it up front than to bolt it on down the road (if you're expecting any sort of growth, it could matter in the future).
Related
I use the boilerplate webpack react app below. In production I get many small "chunks" from the build process. The first load of my page downloads 24mb in "chunks" and it's a somewhat simple website. After the first load a service worker serves all those assets from cache. It has our whole development team stumped, and we don't even know where to begin. Perhaps we rethink our build process?
https://github.com/react-boilerplate/react-boilerplate/blob/master/internals/webpack/webpack.prod.babel.js
Are there any recommended workflows for managing front-end dependencies? I've been reading a lot of articles that recommend moving away from Bower, and on to an npm-only solution like Webpack, but Webpack is a whole new paradigm (loading js, scss, fonts, etc through a single js file) that by default, requires js to be running in the browser for css to load. Part of the reason I want a static site is so that js isn't mandatory for an end-user. However, I'm really tired of bower-installing things, and then having to either host everything in bower_components, targeting specific filenames (js, css, img) to include in output, or move their css/img dependencies into my own repo. Not to mention that relying on two registries is less than ideal.
Does Hexo have a recommended way, or does anyone have an opinion on how to do this? Running a Hexo server in a separate terminal from a webpack-dev-server seems painful and awkward, and possibly create some confusion as to which library should be handling which files.
Are other tools more suited for dependency management in a static site generator's dev/build process?
Are there any existing solutions for run-time bundling of ES6 modules?
I'm looking to simplify JavaScript code development in a MVC5 web app. We're having issues with large, unwieldy JS files, so I'm hoping to get a module loader system in place. So far, I'm not finding any existing bundle transformers for ES6 or another module loader format. I'd be fine with using TypeScript or nodejs require style. I prefer not to use require.js style, though.
Perhaps there's a good reason this solution doesn't exist already. Maybe the dependency resolution processing is too much for a run-time bundling solution. But, I figure it's worth a shot to ask.
Solutions Considered
Prebuilt Web Client
Ultimately, this is where I want to be, but I need a stop-gap solution for now. I know how to put together a build system for an HTML client using grunt/gulp/webpack. But I don't want to have to tell developers to run webpack -w or something similar during development. Nor do I want to tell them to rebuild a solution for every JS change. They should be able to modify the file, refresh the browser, and see the change.
Directory Structure
This is the route I'll probably end up going with. Basically, this JS codebase consists of jQuery widgets and plain JS (helpers/common functions). So, if I structure the code in this directory structure and include the js dir, it should get me most of the way there:
js (DIR)
app-start.js
helpers (DIR)
widgets (DIR)
Widgets should be fine. Helpers, I can see issues where one function/class depends on another. Though, since a function call should never start with a helper (only a widget), this should work fine, assuming no globals are used (or maybe one global like 'App').
I have a question regarding the node app that I want to build.
Before starting on the development, I've written a clear document that splits up my app into different components:
Home
Search
User profile
Dashboard
etc...
Each of these modules may in turn consist of different submodules.
As every module in my app works quite independently (although there are common, reusable components), I decided to render the main page for each of the modules from the server using Express.
Each of the pages that I want to render is highly interactive in the field of DOM interaction and event driven view updates, so I want to go with Backbone for this (using push state for loading submodules dynamically for the nested url's), in combination with requirejs for asynchronous module loading.
The thing I wonder about is if it is okay to include a minified file for each of the pages that I render from the server with express. It seems that this causes quite some overhead, because for each module loaded all the libraries need to be included again (backbone, underscore, jquery, and others).
Is there a common solution to this problem, and will this (in your experience) cause unacceptable performance issues?
What we end up doing with a similar multi page app structure is we break the build to separate "common.js" file that contains all the shared modules, and "main-[module-name].js" files for page specific code, and load it with 2 separate script tags per page
I don't know that it has actual significant perf impact. I am guessing that not really, unless you have some large libraries in your project
Take a look at the multi page config example for requirejs
My $0.02
I'm building an app that will contain many js (jquery) modules (files) using the following setup;
The build is run using Grunt task runner.
I use handlebars templates, then generate the html from *.hbs files.
During the build, I uglify all the js files into one minified file.
I call the minified file in my application <script src="assets/js/app.min.js"></script>
Now, I want to use requirejs to organize my code and adhere to the AMD specifications..
But I got 3 problems with this approach:
I need to have 1 single minified file for all the js; this keeps my code harder to "decode" thus to copy (since it is mixed with other dependencies; jquery, modernizer..) and also helps avoid extra http requests if scripts are called individually.. However, requirejs needs a main file to initialize the app and inside that main file It calls the other required files.. I don't have such configuration.
Many of the dependencies I'm using are in a bower package (that I don't include in the distribution); this makes it not possible to call those files using the suggested requirejs method.
I'm using jquery on this with some 3rd party plugins that don't call define(); to make them work I have to use shim config which again rises the problem #2!
So how am I supposed to take advantage of requirejs while keeping my code in modules and well organized?
Sorry for the long question and thanks for reading :)
ps: Feel free to change the title of the question as I couldn't find a better one!
I finally opted for AngularJS as it adheres to my setup above and allows me to split my app into manageable small modules.
I have also the possibility to use the ease of jQuery (even though it is not a best practice among angular community) and much more.