Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Modern Front-end in Rails

evilmartians.com

Post reply on HN
Print view View original

31–40 of 150 posts

Re: Modern Front-end in Rails

#31

Post by jaxn »

joshwcomeau wrote: post #13

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 thi…

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.

Re: Modern Front-end in Rails

#32

Post by debaserab2 »

scottmf wrote: post #29
jnmandal wrote: post #23

Earlier quoted context omitted.

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 sti…

>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?

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

Re: Modern Front-end in Rails

#33

Post by hamandcheese »

jtmarmon wrote: post #24
vemv wrote: post #15

Earlier quoted context omitted.

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 pi…

To your first point, you can still server side render if you use an API by serving your frontend through a server that fetches data from the API before rendering

And at that point is the added complexity worth not just rendering with rails?

Re: Modern Front-end in Rails

#34

Post by 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.

Re: Modern Front-end in Rails

#35

Post by kbutler »

debaserab2 wrote: post #32
scottmf wrote: post #29

Earlier quoted context omitted.

>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?

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

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

Re: Modern Front-end in Rails

#37

Post by captain_crabs »

nicolasMLV wrote: post #34

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.

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

Re: Modern Front-end in Rails

#38

Post by meesterdude »

jlebrech wrote: post #16

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.

> 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?

Re: Modern Front-end in Rails

#39

Post by bpicolo »

joshwcomeau wrote: post #14
symfoniq wrote: post #10

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 th…

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)

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

Re: Modern Front-end in Rails

#40

Post by 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

Post reply on HN