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

61–70 of 150 posts

Re: Modern Front-end in Rails

#61

Post by orb_yt »

sho wrote: post #47
zabana wrote: post #42

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

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.

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

Probably Meteor, though not as mature as Rails.

Re: Modern Front-end in Rails

#62

Post by jfaucett »

trcollinson wrote: post #40

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

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

Re: Modern Front-end in Rails

#63

Post by pqdbr »

captain_crabs wrote: post #37
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…

I love turbolinks as well. I can get < 100ms to screen with it without almost any extra effort.

Re: Modern Front-end in Rails

#65

Post by Can_Not »

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?

You have a simple nodejs server that renders using react nextjs, vue nuxtjs, angular universal, or ember fastboot while using rails for your APIs.

Re: Modern Front-end in Rails

#66

Post by jessewmc »

trcollinson wrote: post #40

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

When you say you're going back to 'the good old way', out of curiosity, what do you mean? 'Unobtrusive' JS and ajax here and there, but primarily server rendered templates? Or something else?

Re: Modern Front-end in Rails

#67

Post by Can_Not »

hamandcheese wrote: post #33
jtmarmon wrote: post #24

Earlier quoted context omitted.

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?

Some would say "keeping rails" or "TWO templating languages" are the unnecessary added complexity.

Re: Modern Front-end in Rails

#68

Post by Dirlewanger »

zabana wrote: post #42

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

Rails is a great entry point into web development, because it Just Works. If you need to do something not included, there's most likely a Ruby gem that integrates seamlessly with Rails. Need authentication? Authorization? Audit trails? Piping logs to different systems? There's several mature options for each in the Rails ecosystem.

Re: Modern Front-end in Rails

#69

Post by polysaturate »

trcollinson wrote: post #40

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

Turbolinks is plenty fast enough and simple enough for most Rails projects. Maybe sure you're relying on the correct Turbolink events and there's pretty much not anything else you need to change to have Rails automatically load server rendered markup through PJAX.

Re: Modern Front-end in Rails

#70

Post by trcollinson »

jessewmc wrote: post #66
trcollinson wrote: post #40

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

When you say you're going back to 'the good old way', out of curiosity, what do you mean? 'Unobtrusive' JS and ajax here and there, but primarily server rendered templates? Or something else?

We are going back to server rendered templates yes. We are using erb's for templating, jquery, sass and bootstrap, and Turbo Links. It's old and boring and works like an absolute charm. It's not that we don't use JavaScript, we do quite a bit (we're not into CoffeeScript, it's a personal preference). We are using Action Cable for rendering data through web sockets which is one of many examples of a JavaScript heavy portion of our application. We also have a near native mobile application for Android and iOS. Other than the wrapper for the mobile applications, the application is monolithic.

Overall, we've seen a substantial increase in speed, responsiveness, and most importantly our ability to maintain and extend the application.

Post reply on HN