I was reading the Rails webpacker gem documentation where it says:
Webpacker makes it easy to use the JavaScript pre-processor and bundler webpack 4.x.x+ to manage application-like JavaScript in Rails. It coexists with the asset pipeline, as the primary purpose for webpack is app-like JavaScript, not images, CSS, or even JavaScript Sprinkles (that all continues to live in app/assets).
However, it is possible to use Webpacker for CSS, images and fonts assets as well, in which case you may not even need the asset pipeline. This is mostly relevant when exclusively using component-based JavaScript frameworks.
I'm trying to understand the rationale behind using both the older assets pipeline for CSS/images/JS-sprinkles if webpacker is capable of handling all of this?
I've read some other articles that walk me through using webpacker for all of this, but I don't understand the reasoning behind this decision.
Is this just to support legacy applications and eventually the older assets pipeline will go away and webpacker will be used for everything in Rails apps?
As a maintainer of an app that existed before Webpacker, I can give you one reason:
It's hard to migrate an existing frontend from Sprockets to Webpack.
Sprockets builds all JS into one big file with shared scope. Webpack isolates the scope of every JS module. To migrate to Webpack, you need to make sure your code still works with the scope isolation.
Which is often problematic, because in the Sprockets times you didn't have proper JS requires, either, and had to rely on globals or top-scope variables to share code and data between your JS source files.
Rails doesn't offer a painless transition path from Sprockets compilation to Webpack. So, it must support both.
But to answer your other question - going forward, you should use Webpacker if you have enough JS to make it worthwhile.
If your frontend is simple, you will skip some JS nuisances if you use Sprockets. Like if you want to add 10 lines of JS to your app, you might not want to setup a whole JS environment with dependency management and node_modules etc - which is the price of using Webpack/Webpacker. It would be even more senseless to manage a JS environment if all you want is to compile CSS and add digests to your image filenames - which Sprockets is perfectly capable of, without a package.json and anything else JS related.
Therefore, there's a second reason:
Webpacker is good for apps that have a significant frontend codebase. Sprockets is good for adding a bit of JavaScript to a traditional server-rendered app, and for apps with no JavaScript at all.
Related
I am trying to deepen my understanding of modules in JavaScript beyond just using CommonJS, AMD and ES Modules.
This has lead to me look more into webpack to understand how it actually makes modules work in the browser without relying on the still relatively new ES Modules. From what I understand, Webpack bundles the JS, converting import and require statements to its own statements and ships it with a runtime and manifest which allows it to execute them. So Webpack has gotten past the lack of module support by basically implementing its own?
I have tried to compare this to a different bundler — Parcel, but I can’t seem to find any information about how it handles modules.
Does anyone know if my understanding of Webpack is correct, and how that compares to how Parcel does it?
Appreciate any help in advance.
Thanks
The implementation of the ES6 import/export syntax has rendered many traditional module loaders such as RequireJS / AMD and rollup somewhat obsolete. However, asset bundlers like Webpack and Parcel still find their place in modern web development.
An assets bundler packs multiple files into a smaller set of files (including JS, images, fonts, LESS, SCSS etc.), thereby reducing the number of requests to the server and communication overhead. The bundling process typically involves script minification, dead code removal and dependencies management. This also allows more modular front-end web development.
In some ways, Parcel, being newer, is more advanced than Webpack. Parcel supports many different languages and file types out of the box, from web technologies like HTML, CSS, and JavaScript, to lower level languages like Rust, and anything that compiles to WebAssembly (WASM), to assets like images, fonts, videos, and more. You can build multiple targets at once and live-update them as you make changes. Parcel compiles all of your files in isolation in parallel inside workers, caching all of them as it goes along. No explicit configuration is needed for code splitting using dynamic import() statements.
Both Webpack and Parcel provide you a development server to test your project on a browser. Unlike Webpack, the entry point of Parcel is an HTML file instead of a JS file. You should not declare type=”module” within the < script> tags.
Another asset bundler is Browserify. It is a simpler tool which merely bundles your files. It is not as rich in features as Webpack and Parcel.
I would like to upgrade my existing Rails and Angular 1.x application. I'm following the ng-upgrade documentation and seeing that there are many dependencies including systemjs, typescript, tsd and a few other javascript libraries. Ideally there would be a angular-2 gem that would have all the dependencies but I'm not able to find that. Next I looked for gem's for each dependency but there isn't one for tsd.
Does it make sense to switch over to a custom build strategy so I can use npm for javascript package management? I read this article that recommends gulp but I do like the convenience of the asset pipeline.
Can anyone point me to examples of successfully using ng-upgrade with a rails project? Does it use a custom build solution like gulp or does it use the asset pipeline?
My main suggestion is not upgrading yet to Angular2, is still heavily in development and you'll face a lot of this issues like not finding a gem for rails.
Anyway, currently, angular2 can't be compiled with sprockets (the default rails pipeline), so you really want a custom solution.
My main suggestion is go with webpack, other options are browserify or gulp (and others), that's mainly a matter of taste. Overall, configuring a pipeline for angular2 is complicated, you have to take care of .d.ts files through typings (which is the updated version of tsd which now is deprecated), you have to transpile your typescript through tsc and possibly through babel too if you want to use async/await (which are really cool). You'll lose the ability to reference to your files in rails like image_path and such, using a custom pipeline, so you want to take that into account too.
Typescript is much more complex to compile than simple coffeescript files, you depend on every other file it reference, since it needs to compile check against it, don't expect something straightforward.
That being said, if you really want to work with Rails and Angular (2 or not), the right way to handle it is to have two separate projects, one with only the Rails app and one with the AngularJS path. In this way you separate concern, you can have a custom pipeline for Angular2 without impacting Rails and you'll be forced to correctly code your Angular2 app by using Rails as a JSON API, as you should.
My solution was to keep it as simple as possible without using webpack or the asset pipeline. I put the ts files in public and configured rails to serve the npm assets through the pipeline.
I put up a starter project with this structure as an example: https://github.com/jonnysamps/rails-ng2-starter
In many ways it has the benefits of having separate backend/frontend projects but keeps all the code together.
use angularjs gem
gem 'angularjs-rails', '~> 1.4', '>= 1.4.8'
insert into application.js
//= require angular
You can use http://bower.io/#install-bower and you can add two files to your the rails app .bowerrc and bower.json which is like GemFile
When running jshint to validate JS code, I often get errors like
line 264, col 11, 'Cookies' is not defined.
Cookies come from
//= require js.cookie
Which compiled as part of Rails asset pipeline, so JSHint doens't know about it.
Is there a way to set this up so that JSHint runs on a file with all dependencies in place? Or are there any other alternatives?
You can consider using globals option to make jshint aware of shared globals.
If the above proves to be too tedious, then you run jshint after running the files through sprockets - ie. run rake assets:precompile and then run jshint on generated files in public/assets.
But the best course of action I can recommend is something different:
You should consider using a proper module system as opposed to using sprockets for javascript dependency management. This will alleviate the root problem of shared globals (which is a widely regarded poor programming practice).
While the community had come up multiple module systems with varied levels of community acceptance - the best option right now is to embrace the ES6 modules standard. It is good to finally have a standardized approach for modularity. I have recently written a short guide on integrating ES6 modules with rails.
In a nutshell, the ES6 modules standard is a superior option for organizing javascript today as opposed to solutions like AMD, CommonJS or Sprockets directives which were developed in an era when no standardized solution for modular javascript was available.
So I just started learning Laravel, and I want to build something cool with it. I've been working mostly with frontend development, particularly AngularJS, and started using RequireJS recently.
I like the way Yeoman generators set up front-end applications as far as the directory structure, (i.e. /app, /test, /dist) and would like to continue using this structure, but I want to pull it into the overall application. I also like that in most cases, the application uses unbuilt files (particularly JS) for development because it cuts down on waiting for processes.
How can I set up and structure my Laravel (or any other framework) application and templates to use a similar directory/build setup for files? The problem I keep getting stuck on is using unbuilt/uncompressed files for development, as well as a clean separation of my source vs. built front-end files.
Since starting with Laravel I have tried all sorts of Asset Management tools and methods. I ended up using Stolz/Assets, an ultra-simple-to-use assets management PHP library that can be installed with composer. It is not an ideal tool as there are some issues when minifying (particularly CSS.)
Like you though I really needed neatly compiled and minified js/css assets for production.
After much research I have ended up using Gulp.js after reading this blog post (http://www.abishek.me/using-gulpjs-with-your-laravel-application/). I immediately downloaded and installed Gulp.js and created a gulp file with my own directory structure in it. I was up and running within minutes. I have since gone on to modify my gulp file so it now compiles SASS, minifies and compresses both CSS and JS for production.
I continue to use Stolz/Assets (Asset Management Library for Laravel) for serving up my files but I do not rely on this for any compiling or minification.
I am about to start a new emberjs project and I cannot decide whether to use requirejs or rake-pipeline.
The ember advice seems to be to use the rake-pipeline.
Anybody any thoughts on either side of the argument?
If you want to load the dependencies dynamically after page load on an as-and-when-required basis then requirejs is the preferred option.
However if loading all the script when the page loads is not an issue for you (amount of javascript is small, or lot of javascript is required just for the rendering of content) then rails asset pipeline reduces a lot of boilerplate for you because even if you use require js you will eventually have to use r.js compiler to bundle all the dependencies into a single script. Rails does all of this concatanation and minification transparently behind the scenes without you having to do anything at all. Using the rails asset pipeline eases rolling deployment for you because in development scripts are all served as individual files without minification and in production scripts are served as minified and concatenated. This does not require you to run any build script or optimizer upon every change and you don't even have to modify anything in your HTML files. As long as you follow the sprockets specifications and specify the dependencies (which you have to do in case of requirejs too) everything works out of the box.
Also, Rails asset pipeline does not tie your client application to rails platform as sprockets (the dependency manager used behind in the rails pipeline) can be used independently without rails.
If however AMD compatibility is important for you (for example you are planning on using the same code on a NodeJS server as well as client, or are creating a distributable library) then requirejs is a great option.
You can also take a look at https://github.com/jwhitley/requirejs-rails/ which attempts to integrate requirejs into the rails pipeline. Please make sure that you have a reasonable level of familiarity with both requirejs and rails before you adopt this approach.