How to make frontend developers work with rails?

Question

css

I became interested in how people establish a connection between frontenders and backenders in rails. There is a frontender, which, of course, is more convenient to work in the gulp/grunt.js environment, where the speed is high and the page does not need to be refreshed. Bekender then manually transfers the changes to the project, and even replace everything background: url()with background: image-url()so that the assets cling normally. And if you type directly in the rails environment, then it is very long, because all the grunt / gulp chips disappear. So you have to choose which of the employees will be comfortable and who will not.
What is your workflow with frontend developers?

Answer 1

The thing is that when Rails started, there were no systems for front-line soldiers, so the Assets pipeline and so on were invented. It was the Rails way to deal with everything related to the front, and it remains so to this day.
If you want to use gulp for layout and scripts without much trouble, then you will have to abandon the Assets Pipeline toolkit, such as helpers in files, erb inserts, and so on.
The only place where you will have ruby ​​code is in templates.
Put all the junk given by the front-line soldier in public, write the paths there in the templates.
You can generally stir up some git-submodule.
Well, just leave a link to compass-mixins https://github.com/Igosuki/compass-mixins
This is a package for porting compass-based SASS projects to libsass, a pure node.js implementation of SASS without ruby. libsass compiles sass files several times faster than the ruby ​​implementation.

Answer 2

As for me, the ideal solution to the problem is to separate the frontend and backend into different projects and their interaction via the REST API.

Answer 3

Good afternoon! You are confusing something... grunt/gulp is an assembly of a front-end project (what then gets into the build folder, for example). When building, the frontender or another specialist writes a script in the case of grunt / gulp in the javascript language. Which replaces (replaces) paths for asserts, does minimization, combines scripts, and so on. That is, what happens after building gulp / grunt can be deployed to the server.
If you are doing a project on Rails api (REST), then there can be no problems in principle. Since in this case, most likely, your frontend and backend are separated. But if you have a monolithic RubyOnRails application and the markup is generated on the server, then in this case you won’t be able to use grunt / gulp, maybe there is something special for rail views ... for example, asp.net chiks have bundlers that shake and glue scripts, and also can me the path to the files during deployment.

Answer 4

And why does the backender use handles to transfer what has been put together into the project? Why can't gulp build be called during deployment? Why does he manually replace background: url() with background: image-url(), is the frontender really so clumsy that he can’t do it right right away? Even so, why not write a gulp task that does this?
Right now I'm working on a project from which we cut out Kokhan's minion in favor of grunt, and the backend does not interfere with my work, and I do not interfere with it. At a previous job, we built the frontend with grunt and copied all the files to the folder with the ASP.NET application - again, no one interfered with anyone. Why do the rails interfere with the gallop and why does the gallop interfere with the rails?

Answer 5

There is middleman in rails for this and, it seems, yoman. They offer a lot of rails-style haplers. Written in ruby, you can make inserts directly in ruby, etc. Of course, all the goodies of the autoreload, etc.
But what is easier - to make the backender do everything with handles or the frontender to deal with the new stack - is your choice.