
Modern Front-end in Rails - galfarragem
https://evilmartians.com/chronicles/evil-front-part-1
======
trcollinson
I built a rather extensive application for a client over the last 18 months
using Rails API and Angular, using a number of these sorts of principles.
While it is entirely possible to use what the article suggested, I argue it's
a premature optimization and may be a detriment to the entire project. We're
now actively removing the Angular portion of the project and going back to the
good old way.

I wouldn't say this decision was made without careful thought nor without
weighing many options. But when it comes down to it, many line of business
applications (which is what I see a lot of in the market) don't need the level
of sophistication the instructions in this article gives. Most applications
need to be reasonably fast, reasonably responsive, and extremely easy to
maintain and extend. Does working with all of these modern front end tools
that change so quickly and given at least one order of magnitude increase in
complexity also give the application a equal increase in speed,
responsiveness, maintainability, and extensibility? I don't think so.

I'm not the first person to say this. Take a look at this presentation by Sam
Stephenson, it will be worth your while:
[https://www.youtube.com/watch?v=SWEts0rlezA](https://www.youtube.com/watch?v=SWEts0rlezA)

~~~
sillysaurus3
By abandoning React, Vue, and Angular, you're excluding yourself from hiring
all the webdevs that need a front-end technology on their resumes in order to
get hired elsewhere. That's a pretty large swath.

But yes, it's nice that the world is finally realizing Arc was way ahead of
its time. HN is snappy because the HTML is small, with few network requests.

[https://rauchg.com/2014/7-principles-of-rich-web-
application...](https://rauchg.com/2014/7-principles-of-rich-web-applications)

~~~
wwweston
Developers need to be a part of successful projects. Specific tech is less
important unless you want/need to go to work for/with people to whom "modern"
means fashionable. Which, to be fair, is a larger portion of the industry than
most of us care to admit, but then again, React and Vue basics can be learned
on side projects.

(Angular, less so, though these days I do appreciate it when companies are so
kind as to list Angular in their job postings; it's a good heuristic for
weeding out based on the probability that there's no one with influence at the
organization that thinks about the tools they're using carefully.)

------
symfoniq
Honestly, as a Rails dev, this just seems more complicated than creating a
Rails app in API mode and using #{React||Vue||Ember}} for the front-end.

It's extremely easy to get started with a front-end app using vue-cli. This
article spends a _lot_ of time changing Rails' default functionality to
achieve behavior similar to what vue-cli gives you by typing `vue init
webpack` and answering a few questions.

I understand that getting up to speed with a front-end framework takes time,
but in my case, it was time well-spent (I used Maximilian Schwarzmüller's
Vue.js course on Udemy). There's no shame in just using Rails for the API.

~~~
jnmandal
The downside there is that you're then forced to build your application as a
completely separate service and static site. With this approach, you can stick
single page app where the UI needs to be more stateful and then use
traditional server-templating for other things. I'm doing this w/ phoenix now
and its nice because my typeahead search is done as a JS component, but the
corresponding index and show pages are still mostly the same as what was
scaffolded.

Not to mention, the combined approach is 100% necessary if you are going to
require a server render for your react||vue|ember stuff.

~~~
scottmf
>Not to mention, the combined approach is 100% necessary if you are going to
require a server render for your react||vue|ember stuff

Why’s that?

~~~
debaserab2
If your react/vue codebase is isolated to client end, how is your server going
to render react/vue code?

~~~
kbutler
For server-side rendering see next.js for react and nuxt.js for vue.

~~~
nihonde
And fastboot for Ember.

------
pducks32
Rails is still a truly incredible framework and it still moving very fast in
terms of development. It’s front end stuff has always felt wrong to me and
many others and we found weird ways to doing what we wanted. Rails 5 added
support for a lot of them as the article points out but it still feels
complicated.

Rails is awesome bc it’s opinionated but the fact that it’s ruby still lets
you do what you want. I think rails needs to really dedicate some effort to
better generators that ask which of these modern front end approaches do you
want to use and then setup the project to just work and let me get to my
coding.

~~~
inopinatus
The webpack integration coming in Rails 5.2 starts to do exactly what you
suggest. We’ve had the beta in general use for weeks and I’d say the framework
is going in the direction you want.

This article seems a bit of overengineering by comparison and isn’t
representative of what’s new out-of-the-box.

~~~
coisnepe
Does 5.2 add anything on top of 5.1? The core team added the webpacker gem
back in February this year but I haven't checked out yet what they're planning
with 5.2.

~~~
inopinatus
ActiveStorage for managing file uploads is the other big new feature.

There’s also a new secrets mechanism of dubious necessity. Seems DHH just
can’t stop reinventing those.

------
the_gastropod
> As developers, however, we usually care about

> 1\. isolated, reusable, testable code that is easy to reason

> about;

> 2\. short “code change → visible result” cycle;

> 3\. straightforward dependency management; and

> well-maintained tools.

> Sure, “classic” Rails gives our code some structure: there

> are separate folders for view templates, javascripts,

> stylesheets and images. But as the front-end complexity

> grows, navigating them quickly becomes a cognitive drain.

WAT?

1\. I don't see how the directory renaming / npm config changes this at all.

2\. I guess this is an argument for speed of asset pipeline? As mentioned in
the article itself, Rails 5.1 webpack with hot reloading built in. How much
faster can you get?

3\. I don't think I've ever heard of npm referred to as a well-maintained
tool.

Beyond that, the idea that Javascript-heavy web apps are "Modern" is kind of
silly. They're certainly trendy. In the vast majority of the cases I've seen,
there's no coherent reason for the added complexity.

~~~
muthdra
NPM is a well-maintained tool. Version 5 got major updates in speed and
usability. They where aware of the Node release cycle and implemented the new
version in advance so it would be rolled out alongside Node. NPM now does way
faster caching than before, can lock dependencies in specific versions more
easily (inspired by Yarn) and may have a flat dependency tree if your project
demands it (like when using Polymer and it's components. like Bower works).

~~~
the_gastropod
Yarn exists because npm has historically been a problem-riddled package
manager.

~~~
minor3rd
They still have some awfully awkward stuff in npm5. In some cases they will
overwrite your package.json with logging data (WTF?)

------
nicolasMLV
Turbolinks is the official Front-end part of Rails and it works very well, but
there is no mention of it in the article neither in the hackernews comments,
so i think it is under-used.

There's also turbolinks-ios and turbolinks-android, I built my mobile apps
with minimal knowledge of Swift and Kotlin.

~~~
captain_crabs
I've transitioned from rails-everything to working exclusively with front-end
frameworks and libraries (react, angular, polymer), and I'll tell you this
still: if I'm working in rails, I use turbolinks. It's a wonderful approach,
way under-appreciated.

When two or more things on the page need to know about each other/you require
a high-fidelity interaction that you can't easily handle with just it, then
yeah - reach for vue, react, or what have you. But no need to start there! Use
those as targeted air strikes

~~~
WaxProlix
I think the issue is that with out of the box rails apps, there's not a lot of
opportunity to perform one of these 'targeted air strikes'. Emergent
requirements incentivize quick solutions and you can end up with a bunch of
ad-hoc foundation components and really bad jquery-ui slapped around in erb
files.

At least, that's been my (very limited) experience with it.

~~~
captain_crabs
I've found it easier to just drop in `react-rails` and build out react
components for certain situations than to try and string a bunch of jquery
together.

------
joshmn
This is over-engineering at its finest, and doesn't answer some questions:
When do you want to use a front-end framework, and why?

For at _least_ 90% of the things out there, you don't need a front-end
framework like React/Vue/Ember/Angular. And while these front-end frameworks
increase the complexity of the app, its trade-off often doesn't nearly provide
enough value in terms of speed/extensibility/maintainability to warrant it.

Rendering server-side views is fine: plug-in Turbolinks and have a blast. It's
not cool, it won't get you stylepoints with your colleagues, but you should be
trying to impress your client/boss with speed/extensibility/maintainability,
and not impress with complexity of your stack.

------
davidw
I eagerly await the article in a year explaining how all that is old hat and
explaining the new, new way, based on last month's Javascript trends.

------
joshwcomeau
Hm. While I think it's awesome that the Rails community is moving towards
adopting modern JS practices, from this post, it's not making a very good case
for _why_ you'd want to do this.

Modern JS is lovely to write compared to ES5, but this tutorial doesn't write
any yet! Perhaps this'll be addressed in the next part of the tutorial
(although doing it in a framework-agnostic way seems tough).

Also, if I'm reading this correctly, they're still attaching an `erb` for each
component, and using Rails to determine how they relate to each other? This
feels a bit wrong to me, at least for dynamic web applications; when you have
a framework like React controlling all of your front-end rendering, it's easy
to integrate client-side routing and make it a single-page app, which means
lightning-quick page transitions.

So yeah, delighted to see Rails move towards this direction, and this post is
super helpful in explaining the "how" for a basic setup, but not the "why"; it
also falls a bit short IMO in going "all the way", to have the front-end truly
control its destiny and reap the benefits associated with that.

~~~
jaxn
We have a large monolith rails app and are gradually moving the front end to
Vue. And as we start to seeing those “lightening-quick page transitions” it
makes me want to devote more resources over to the change.

The method in the article seems like a very non-conventional way to go about
it with no added benefit.

------
colinsidoti
I may be mistaken, but I think the meat of this will be in post 2?

It sounds like your taking React's render() and replacing it with ERB. But,
how are you giving the ERB file access to state and props?

I suppose if it's done well, this would make it easier for Rails devs to adopt
single page apps. It sounds like you're abstracting away a lot of React and
creating a Rails-ier API to it.

~~~
swanson
I think the intention is to go the opposite way: instantiating React
components in the ERB template and passing in state/props from the controller
instance variables.

------
blauditore
Off-topic: That website sets font size in `vw` (viewport width percentage).
This is horrible: Text is way too large on maximized desktop browsers, and
zooming the page doesn't change that, but only causes a weird jump in
position.

~~~
pmontra
Worse than that: if I make the window narrow it displays some 40 lines, if I
maximize it displays 20. The expected behavior is that the font size is
independent from the width of the window, exactly as on HN and any other site.

What's the purpose of making text small, punishing readers for not maximizing
the site? :-)

Seriously, it could be a way to make text flow into a smaller column, but
there is no need to make text smaller. HN reflows and keeps the same font
size.

------
endlessvoid94
I'm starting to really like Turbolinks due to its simplicity over the latest
fashionable frontend trends.

However, I have found precious few actual guides on the iOS and android
wrappers. Has anyone found a good guide / documentation on this topic?

------
zabana
Not trying to start a flame war here, buy what is the argument for using Rails
over Express or Django/Flask for a new project ? Genuinely curious to know the
benefits / downsides of each option

~~~
sho
You can't compare Rails to Express. It's a much, much more full-featured web
framework. JS doesn't really have an equivalent to Rails (that I know of).

Django is comparable in scope but Rails is many times more popular and a lot
more work has gone into it. IMO you would need a very good, specific reason to
choose Django over the far more popular Rails.

~~~
orb_yt
> JS doesn't really have an equivalent to Rails (that I know of).

Probably Meteor, though not as mature as Rails.

------
evolve2k
Much of the reconifgufation work here seems to relate to just moving the
default webpack Javascript directory from /app/javascript to /frontend (or
something on root).

The Rails team historically is known for making informed decisions about file
structure conventions, since Rails already picked app/javascript as the place
for webpacked JavaScript, why the need to move it?

------
pbreit
To a newbie this setup process is totally insane. Is this really what it's
come to in Late 2017?

------
lsiebert
I really wish Rails came with an easy out of the box to run as a REST api mode
that let you load your initial front end from a single endpoint, or for server
rendered react/vue/angular that can then hit the REST api, in a way that let
you abstract the front end cleanly so that front end developers never need to
touch anything rails related.

Rails with webpacker built in and rails api mode are both awesome, but they
don't feel well integrated together.

Sure, you can get this working in a rails engine, but it feels like a hack and
you miss out on a lot of built-in template goodies. There is also shakacode's
React on Rails, which is awesome, but still pretty tightly integrated with the
default rails views.

------
bcheung
That font is ridiculously huge. It's painful to read. Looks like the browser's
font resize functionality is blocked but you can change the size by resizing
your browser width. I really don't like that UI pattern.

~~~
marsrover
Funny you mention that. I have a 4k monitor and bad eyesight and normally have
to zoom in on webpages. When I clicked this one I was pleased that it was
already zoomed in for me.

------
buf
I understand the craze. But c'mon...

[http://www.castingcall.club](http://www.castingcall.club) serves over 1M
pageviews a month. Total hobby project. It has a hybrid of what this article
describes. I have my `/app/assets` folder for most of the pages on the site
and I've got my webpack `/frontend` folder which handles the complex
components.

I also run [http://program.reforge.com](http://program.reforge.com). Same
approach. Rails asset pipeline for the pages that are simple and React on the
pages that need to be componentized.

------
desireco42
I see a lot of people respond negative to this post, I got a lot from it.

First it shows you how to override rails defaults to create very similar
environment that you would get if you would go api/react or vue. Advantage
with this setup is that you still Rails foundation and this comes with a lot
of goodies.

I love that it explain rather simple way to have hot reloading, I feel this
makes me significantly more productive.

Overall really enjoyed article and will adopt many of ideas in it. It is good
way to modernize your Rails projects.

------
mmontoya
Webpacker is an anti-pattern: pollute the ruby sphere with JS and pollute the
JS sphere with Ruby because you don't wanna read the Webpack tutorial.

------
hijp
Thanks for this, I've been fooling around with trying to get a Rails + Vue app
started and sampling a bunch of tutorials.

One thing that would help me understand this better is a short overview of
your strategy and why you chose it as opposed to some other options mentioned
like rails api + JS-framework frontend.

It goes from history to nitty gritty, so I'd have to follow through step by
step to get an idea how it all fits together.

------
kuon
I found it to be much easier to build an API (in rails or whatever, I use
phoenix/elixir now) and consume it with either a frontend framework like ember
(I use elm now) or a static site generator (I use hugo).

This way I can produce either an app frontend (something that requires JS) or
a site frontend (something that doesn't require JS).

------
Rotareti
This website is total crab on my Laptop. The font is huge and zooming with
ctrl +/\- doesn't work (firefox 57).

Edit: Sorry for my harsh words. I just get kinda angry when I come across
websites that don't allow me to zoom in or out, especially when the default
font size is way off the standard.

------
bsaul
Curious : is there an up to date analysis on the reasons you would still want
to render to html on the server today ? Which search engines work fine with
client js rendering the page ? Are there other issue you may still experience
( facebook links, mobile browsers bugs, etc) ?

~~~
Spone
Main reason for me is performance. Especially important on a mid-range
smartphone with sloppy network.

------
phaedryx
Looks like a solid approach. I'm going to try it out tonight.

------
crb002
Django/Rails should emit static views in Vue/Angular.

------
knivets
Wow, I like how readable the text is. The typography in the post is beautiful.

~~~
StevePerkins
Whenever I see a front-page link about Rails, I always think, " _I bet the top
comment threads will be about the font or layout rather than the content_ ".
Click, and... yep!

It's been about ten years, and you don't see as many Rails posts as you used
to, but it still holds true!

~~~
sho
I've also been around for getting on 10 years (ok, 8.8, close enough) and this
is literally the first time I have heard anyone compliment the typography of a
Rails post, let alone noticed it occurring enough to become an identifiable
trend.

Am I missing some sort of joke?

------
jlebrech
I think Vanilla Rails sprinkled with a bit of React can go a long way.

Not every part of an app needs the duplicity of state, or need to look
dynamic.

~~~
meesterdude
> sprinkled with react

I can sprinkle in javascript for a normal rails app to add behavior - but i
thought react required moving all rendering into it? are you able to
"sprinkle" with react within otherwise normal html/css/js?

~~~
cies
Yes you can. Not like jQuery where you use it to manipulate the DOM (as
rendered from HTML generated on the server).

With React you basically let it manage one or more subtrees of the DOM; you
let React do the rendering for that subtree at all times (possibly using React
on the server to do pre-rendering).

------
nullundefined
This article and a lot of opinions I hear like this are incredibly ignorant.
There's nothing wrong with using Rails in a "classic" way as everyone seems to
call it.

I do think calling Rails' method classic and these new frameworks "modern" a
bit ignorant. If anything Rails is "modern" and these new frameworks are just
that, new. Being new does not mean you're modern. It means you're new. A
trend. You'll likely be gone tomorrow.

------
onebot
People still use Rails?

~~~
matthewmacleod
Yes. Thousands and thousands of engineers still use Rails to be produce
valuable web applications and APIs. For a large number of use cases, there is
little benefit to moving to a different stack.

------
RomanPushkin
TLDR please, thx

------
aphextron
This is precisely what was always wrong with the “Rails philosophy”. Front end
should be completely independent to any kind of backend. The level of
integration proposed here is an absolute nightmare to maintain and extend.

~~~
dvdhnt
It’s not just a backend, Rails is a full stack framework - from database
administration to data modeling, business logic to frontend. It literally has
built in frontend templating in the form of erb.

That said, I think that frontend development has evolved into a place where
frontend development is better done separately. As part of its evolution,
Rails integrated Rails API and can be configured minimally to be a backend API
only.

