14 ms·

Modern Front-end in Rails

355 points by galfarragem 9y ago

onebot 9y ago
People still use Rails?
- castis 9y ago
  Dude people still use fortran and cobol. This should not surprise anyone.
- matthewmacleod 9y ago
  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.
bsaul 9y ago
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 9y ago
  Main reason for me is performance. Especially important on a mid-range smartphone with sloppy network.
knivets 9y ago
Wow, I like how readable the text is. The typography in the post is beautiful.
- StevePerkins 9y ago
  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 9y ago
    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?
  - Kiro 9y ago
    I don't understand the correlation between the font and it being a post about Rails.
  - deemx 9y ago
    probably due to the fact that rails tends to be more accessible for junior frontend devs or designers guys that want to try some backend stuff
- publicfig 9y ago
  I know this is off topic, but I noticed the typography too and was just seeing if I could tell what it was before looking. But oddly enough, I can't seem to find out what typeface is used using the developer tools for the life of me. Does anyone know how that could be hidden from the styles pane?
  - ericthor 9y ago
    The rendered typeface is Stem Text. If you click on an element with the typeface and go to the computed tab that will show you what font-family style is applied.
  - deleted 9y ago
    [deleted]
  - phaedryx 9y ago
    I think it is this font: https://www.myfonts.com/fonts/paratype/stem-text/ https://www.myfonts.com/fonts/paratype/stem-text/ (look in the 'computed' tab of dev tools)
- tudelo 9y ago
  The capital letters all look bold. The font is extremely ugly.
  - ahoka 9y ago
    The font size is also ridiculously large on ultra wide screens: https://imgur.com/a/Q8IAn https://imgur.com/a/Q8IAn
    - pbreit 9y ago
      I don't see anything wrong in that image.
the_gastropod 9y ago
> 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 9y ago
  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 9y ago
    Yarn exists because npm has historically been a problem-riddled package manager.
    - minor3rd 9y ago
      They still have some awfully awkward stuff in npm5. In some cases they will overwrite your package.json with logging data (WTF?)
symfoniq 9y ago
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.
- joshwcomeau 9y ago
  Yeah, really good point; this article is kinda halfway between "modern client-side app" and "traditional server-controlled app", and it kinda feels like the worst of both worlds (added complexity without many of the benefits)
  - bpicolo 9y ago
    For what it's worth, there are a lot of good reasons to have access to both (though not saying the article is doing it the best way). There are all sorts of pages that aren't worth the boilerplate and extra time to develop (data-heavy admin pages, trivial about pages, etc). I love SPAs for the heavy-hitting User-facing pages, but for a lot of things they're total overkill and not worth the extra maintenance and development effort
- vemv 9y ago
  Agree in principle, but any technique is frigthening at first. Clearly for the authors this is a usual workflow - they're productive with it, and they only had to pay the complexity cost once (when figuring out things). Once you get an integrated frontend-backend system and codebase, you start to get unique benefits: - Server-rendered data, for avoiding superfluous ajax requests - Simpler deployments (fewer moving pieces) - Single codebase, less knowledge segregation and so on.
  - jtmarmon 9y ago
joshwcomeau 9y ago
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 9y ago
  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.
jlebrech 9y ago
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 9y ago
  > 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 9y ago
    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).
  - mmontoya 9y ago
    The best approach is to let that Webpack handle SCSS/JS but still you can create most of the site with old good HAML.
  - jemminger2 9y ago
    It's even easier to sprinkle with Vue.js
pducks32 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      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.
- pqdbr 9y ago
  Totally agree. You can go the .js.erb views and `$('#div_id').replaceWith('<%= escape_javascript(render partial :partial_name) %>')` route, or you can use render_to_string and put your partial HTML in JSON and replace it with frontend JS, and so on and so on. And there's also turbolinks to consider and the idempotent stuff. It's all great, I got my way around it, but I never know if what I'm doing is considered best practice or not.
colinsidoti 9y ago
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 9y ago
  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.
deleted 9y ago
[deleted]
Rotareti 9y ago
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.
aphextron 9y ago
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 9y ago
  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.
zabana 9y ago
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
- esaym 9y ago
  Well, in this case it looks like they have decent built in webpack support.
- fleetfox 9y ago
  I can only comment regarding Django and it mostly boils down to python vs Ruby and what is idiomatic to them
- sho 9y ago
  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 9y ago
    > JS doesn't really have an equivalent to Rails (that I know of). Probably Meteor, though not as mature as Rails.
  - Can_Not 9y ago
    Not as mature as rails, obviously, but Adonisjs and sailsjs are options.
- desireco42 9y ago
  Genuinely to answer, Rails offer much richer environment, Express is pretty much bare bones server, Flask is comparable to Sinatra, the only comparable thing is Django and, especially in new version it got much better, I still think Rails is much more flexible solution, which offers you a lot already premade stuff, with your ability to control how things will be used, still quite significant. Most of all, I believe a set of good practices enforced or encouraged with Rails is what distinguish it over all other frameworks. Most difficutlty with Rails is after few years when you need to upgrade, I feel a lot of busy work has to happen then.
phaedryx 9y ago
Looks like a solid approach. I'm going to try it out tonight.
nicolasMLV 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      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.
  - pqdbr 9y ago
    I love turbolinks as well. I can get < 100ms to screen with it without almost any extra effort.
  - minor3rd 9y ago
    Have to disagree on this one for anything but the most basic apps (think blogs and lots of static content). I'd have rewritten my entire app over by now with the "targeted air strikes" approach.
RomanPushkin 9y ago
TLDR please, thx
trcollinson 9y ago
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
- Scarbutt 9y ago
  That presentation makes me want to learn Rails but fortunately there is a shortcut, you can use turbolinks on its own (written in coffescript thought).
  - tortilla 9y ago
    I'm using turbolinks with my Phoenix/Elixir stack.
  - jordanlev 9y ago
    Or use intercooler, which was inspired by turbolinks but is a completely separate (and non-coffeescript) library: http://intercoolerjs.org/ http://intercoolerjs.org/
- jfaucett 9y ago
  > Most applications need to be reasonably fast, reasonably responsive, and extremely easy to maintain and extend. Exactly this. I do a lot of freelance rails work and have worked on all kinds of ruby/rails projects. I would say for honestly at least 80% probably around 90% of projects, the "old school boring" rails way is by far the way to go. The whole front end heavy craze is really not the right choice unless you need a very high degree of desktop-like interactivity which again is something most i.e. 80/90% of applications I see in the wild do not require.
desireco42 9y ago
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.
davidw 9y ago
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.
bcheung 9y ago
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 9y ago
  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 9y ago
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.
joshmn 9y ago
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.
pbreit 9y ago
To a newbie this setup process is totally insane. Is this really what it's come to in Late 2017?
blauditore 9y ago
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 9y ago
  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 9y ago
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?
kuon 9y ago
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).
evolve2k 9y ago
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?
hijp 9y ago
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.
lsiebert 9y ago
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.
mmontoya 9y ago
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.
nullundefined 9y ago
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.
crb002 9y ago
Django/Rails should emit static views in Vue/Angular.

355 points by galfarragem 9y ago

onebot 9y ago

People still use Rails?

castis 9y ago
Dude people still use fortran and cobol. This should not surprise anyone.
matthewmacleod 9y ago
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.

bsaul 9y ago

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 9y ago
Main reason for me is performance. Especially important on a mid-range smartphone with sloppy network.

knivets 9y ago

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

StevePerkins 9y ago
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 9y ago
  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?
- Kiro 9y ago
  I don't understand the correlation between the font and it being a post about Rails.
- deemx 9y ago
  probably due to the fact that rails tends to be more accessible for junior frontend devs or designers guys that want to try some backend stuff
publicfig 9y ago
I know this is off topic, but I noticed the typography too and was just seeing if I could tell what it was before looking. But oddly enough, I can't seem to find out what typeface is used using the developer tools for the life of me. Does anyone know how that could be hidden from the styles pane?
- ericthor 9y ago
  The rendered typeface is Stem Text. If you click on an element with the typeface and go to the computed tab that will show you what font-family style is applied.
- deleted 9y ago
  [deleted]
- phaedryx 9y ago
  I think it is this font: https://www.myfonts.com/fonts/paratype/stem-text/ https://www.myfonts.com/fonts/paratype/stem-text/ (look in the 'computed' tab of dev tools)
tudelo 9y ago
The capital letters all look bold. The font is extremely ugly.
- ahoka 9y ago
  The font size is also ridiculously large on ultra wide screens: https://imgur.com/a/Q8IAn https://imgur.com/a/Q8IAn
  - pbreit 9y ago
    I don't see anything wrong in that image.

the_gastropod 9y ago

> 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 9y ago
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 9y ago
  Yarn exists because npm has historically been a problem-riddled package manager.
  - minor3rd 9y ago
    They still have some awfully awkward stuff in npm5. In some cases they will overwrite your package.json with logging data (WTF?)

symfoniq 9y ago

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.

joshwcomeau 9y ago
Yeah, really good point; this article is kinda halfway between "modern client-side app" and "traditional server-controlled app", and it kinda feels like the worst of both worlds (added complexity without many of the benefits)
- bpicolo 9y ago
  For what it's worth, there are a lot of good reasons to have access to both (though not saying the article is doing it the best way). There are all sorts of pages that aren't worth the boilerplate and extra time to develop (data-heavy admin pages, trivial about pages, etc). I love SPAs for the heavy-hitting User-facing pages, but for a lot of things they're total overkill and not worth the extra maintenance and development effort
vemv 9y ago
Agree in principle, but any technique is frigthening at first. Clearly for the authors this is a usual workflow - they're productive with it, and they only had to pay the complexity cost once (when figuring out things). Once you get an integrated frontend-backend system and codebase, you start to get unique benefits: - Server-rendered data, for avoiding superfluous ajax requests - Simpler deployments (fewer moving pieces) - Single codebase, less knowledge segregation and so on.
- jtmarmon 9y ago

joshwcomeau 9y ago

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 9y ago
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.

jlebrech 9y ago

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 9y ago
> 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 9y ago
  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).
- mmontoya 9y ago
  The best approach is to let that Webpack handle SCSS/JS but still you can create most of the site with old good HAML.
- jemminger2 9y ago
  It's even easier to sprinkle with Vue.js

pducks32 9y ago

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 9y ago
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 9y ago
  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 9y ago
    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.
pqdbr 9y ago
Totally agree. You can go the .js.erb views and `$('#div_id').replaceWith('<%= escape_javascript(render partial :partial_name) %>')` route, or you can use render_to_string and put your partial HTML in JSON and replace it with frontend JS, and so on and so on. And there's also turbolinks to consider and the idempotent stuff. It's all great, I got my way around it, but I never know if what I'm doing is considered best practice or not.

colinsidoti 9y ago

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 9y ago
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.

deleted 9y ago

[deleted]

Rotareti 9y ago

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.

aphextron 9y ago

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 9y ago
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.

zabana 9y ago

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

esaym 9y ago
Well, in this case it looks like they have decent built in webpack support.
fleetfox 9y ago
I can only comment regarding Django and it mostly boils down to python vs Ruby and what is idiomatic to them
sho 9y ago
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 9y ago
  > JS doesn't really have an equivalent to Rails (that I know of). Probably Meteor, though not as mature as Rails.
- Can_Not 9y ago
  Not as mature as rails, obviously, but Adonisjs and sailsjs are options.
desireco42 9y ago
Genuinely to answer, Rails offer much richer environment, Express is pretty much bare bones server, Flask is comparable to Sinatra, the only comparable thing is Django and, especially in new version it got much better, I still think Rails is much more flexible solution, which offers you a lot already premade stuff, with your ability to control how things will be used, still quite significant. Most of all, I believe a set of good practices enforced or encouraged with Rails is what distinguish it over all other frameworks. Most difficutlty with Rails is after few years when you need to upgrade, I feel a lot of busy work has to happen then.

phaedryx 9y ago

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

nicolasMLV 9y ago

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 9y ago
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 9y ago
  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 9y ago
    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.
- pqdbr 9y ago
  I love turbolinks as well. I can get < 100ms to screen with it without almost any extra effort.
- minor3rd 9y ago
  Have to disagree on this one for anything but the most basic apps (think blogs and lots of static content). I'd have rewritten my entire app over by now with the "targeted air strikes" approach.

RomanPushkin 9y ago

TLDR please, thx

trcollinson 9y ago

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

Scarbutt 9y ago
That presentation makes me want to learn Rails but fortunately there is a shortcut, you can use turbolinks on its own (written in coffescript thought).
- tortilla 9y ago
  I'm using turbolinks with my Phoenix/Elixir stack.
- jordanlev 9y ago
  Or use intercooler, which was inspired by turbolinks but is a completely separate (and non-coffeescript) library: http://intercoolerjs.org/ http://intercoolerjs.org/
jfaucett 9y ago
> Most applications need to be reasonably fast, reasonably responsive, and extremely easy to maintain and extend. Exactly this. I do a lot of freelance rails work and have worked on all kinds of ruby/rails projects. I would say for honestly at least 80% probably around 90% of projects, the "old school boring" rails way is by far the way to go. The whole front end heavy craze is really not the right choice unless you need a very high degree of desktop-like interactivity which again is something most i.e. 80/90% of applications I see in the wild do not require.

desireco42 9y ago

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.

davidw 9y ago

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.

bcheung 9y ago

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 9y ago
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 9y ago

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.

joshmn 9y ago

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.

pbreit 9y ago

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

blauditore 9y ago

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 9y ago
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 9y ago

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?

kuon 9y ago

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).

evolve2k 9y ago

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?

hijp 9y ago

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.

lsiebert 9y ago

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.

mmontoya 9y ago

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.

nullundefined 9y ago

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.

crb002 9y ago

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