3 ms·

Opinion forming: Isn't this a way to invite volatility into the Rails ecosystem? Maybe instead of adding options for webpack, yarn etc. Rails should decouple i

by dakull 10y ago

Opinion forming: Isn't this a way to invite volatility into the Rails ecosystem? Maybe instead of adding options for webpack, yarn etc. Rails should decouple itself from the front-end so that most of us can use our Preferred approach™ Alternately something in the vein of moonglum's gem [0] should also work but again, as an external lib. not part of Rails. [0] - https://github.com/fejo-dk/rails_external_asset_pipeline https://github.com/fejo-dk/rails_external_asset_pipeline

madebysquares 10y ago
You could say that work is already done. Generate a rails API app and then use whatever front end you want.
- dakull 10y ago
  Yes but that's geared towards building an API (ofc I can strip Rails however I like, dropping whatever I don't use) but it wasn't my main point - the tooling in the JS world changes rather quickly, now, this would imply lots of changes in main Rails just to support all of those external changes hence the volatility part in my comment. For example looking at the Phoenix framework - they choose by default Brunch [0] but they also let you implement whatever you want. It's still opinionated but they make it clear is not part of the core framework. [0] - http://www.phoenixframework.org/docs/static-assets http://www.phoenixframework.org/docs/static-assets
sintaxi 10y ago
It was clear ages ago that this should happen but this is rails catering to the market as it tends to do.