When to use browserify-rails and when not to
In 2014, I joined a startup and began rewriting their single page web application. One developer had been working on that particular part of the site and it was long in tooth. Startups need to iterate fast and try new ideas and their codebases typically reflect that. Many developers at startups talk about switching from one language to another as if that was the solution to their problems but in reality, most of the time, the rewrite is simply getting rid of all the cruft that has built up along with the knowledge the developers have built by working on the existing code.
Because it was a painful process that would be easy to get bogged down in, we decided to rewrite it as is — to avoid spending too much time refactoring the existing code. That way we would work in phases: get the code base to modules then focus on refactoring the individual modules (while of course juggling add new features).
In the end, I contribute quite a bit to the gem and continue to work on it today. But I have noticed that not everyone is sure when using something like browserify-rails is appropriate. Of course, I think it is best that people make up their own minds but I will outline my thinking.
Of course, that begs the question: is Ruby on Rails an appropriate stack for a modern client-side rending web application. That is a very loaded question but I do think it is something that should be asked on any new project. Isomorphic web applications are coming and they are coming for solid technical reasons. Choose your stack carefully.