3 ms·

Ok. Let's see from another side on this point. If you are beginner Rails developer who doesn't know how to configure Webpack properly and doesn't know how to w

Ok. Let's see from another side on this point. If you are beginner Rails developer who doesn't know how to configure Webpack properly and doesn't know how to works with React/Vue/Ember? And if your project must be a SEO-friendly? You don't know React, Webpack and doesn't know how to works with React/Vue SSR. Maybe learning its tools will be an excellent investment if you want to be a front-end developer. But what if not? We wrote this article mainly for beginners full stack developers. They are not well-experienced front-end developers.

demiazz 9y ago
Another case. My case. My project started more than four years ago. It was a mainly content project around content creating and sharing, and of course SEO. Facebook released React two month early than we started. Webpack has not yet created. Gulp is a bleeding edge. And we used sprockets, CoffeeScript and SASS. It's is a massive project now. And it changed development vector for last year. We make a lot of changes, and we haven't resourced for rewriting them on separated front-end and back-end for now. But described methodology allows us to keep this project maintainable. We migrated this approach from Sprockets to Gulp, and from Gulp to Webpack. And we thought. What if we tell about how we maintain the project to beginners? They are writing jQuery-spaghetti code, and they may don't know frontend frameworks and Webpack. Let's tell them how to write maintainable code with webpacker, components, BEM and our code organization. It's maybe a good starting point for them.
oelmekki 9y ago
Did you try create_react_app? I find it way easier to setup my frontend using it than to use webpacker, even being used to both rails and react. You type "yarn build", and you have properly fingerprinted js and css files ready to use, with an `index.html` file that includes them. It's great to only focus on backend in rails, and it brings all the cool thing from js dev for free: babel, webpack, yarn, live reload, import of css files, etc. SSR is indeed still a problem (I've build a cache system that will render pages with chrome headless, for that), but gladly, it's about to be solved (at least for the SEO part): https://webmasters.googleblog.com/2017/12/rendering-ajax-crawling-pages.html https://webmasters.googleblog.com/2017/12/rendering-ajax-cra... The biggest problem yet to be solved: properly handling 404 status.

demiazz 9y ago

Another case. My case. My project started more than four years ago. It was a mainly content project around content creating and sharing, and of course SEO. Facebook released React two month early than we started. Webpack has not yet created. Gulp is a bleeding edge. And we used sprockets, CoffeeScript and SASS. It's is a massive project now. And it changed development vector for last year. We make a lot of changes, and we haven't resourced for rewriting them on separated front-end and back-end for now. But described methodology allows us to keep this project maintainable. We migrated this approach from Sprockets to Gulp, and from Gulp to Webpack. And we thought. What if we tell about how we maintain the project to beginners? They are writing jQuery-spaghetti code, and they may don't know frontend frameworks and Webpack. Let's tell them how to write maintainable code with webpacker, components, BEM and our code organization. It's maybe a good starting point for them.

oelmekki 9y ago

Did you try create_react_app? I find it way easier to setup my frontend using it than to use webpacker, even being used to both rails and react. You type "yarn build", and you have properly fingerprinted js and css files ready to use, with an `index.html` file that includes them. It's great to only focus on backend in rails, and it brings all the cool thing from js dev for free: babel, webpack, yarn, live reload, import of css files, etc. SSR is indeed still a problem (I've build a cache system that will render pages with chrome headless, for that), but gladly, it's about to be solved (at least for the SEO part): https://webmasters.googleblog.com/2017/12/rendering-ajax-crawling-pages.html https://webmasters.googleblog.com/2017/12/rendering-ajax-cra... The biggest problem yet to be solved: properly handling 404 status.