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

111–120 of 150 posts

Re: Modern Front-end in Rails

#111

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

Re: Modern Front-end in Rails

#112

Post by demiazz »

pmontra wrote: post #90
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…

It's probably a matter of tastes, either one project or two projects. I've been working with Rails since 2006 and I'll create two separate projects. A Rails API project and a front end one. Two projects, two repositories, maybe two teams (specialized teams are more common than full stack.) The front end is served by the reverse proxy in front of Rails. If I want to serve some semi-static HTML page from Rails, all I h…

Of course! If you have human resource to separate and maintain backend and frontend - it's an excellent solution.

But it's article not for teams like this. The described solution for full-stack developers and small projects, which needs to be maintainable too. And component manner is a proper way to organize frontend code.

Re: Modern Front-end in Rails

#113

Post by simplyluke »

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.

When turbolinks first hit most people went "oh it breaks jquery" and never touched it again.

Which is a shame considering how much it speeds most typical applications up by completely ignoring the mobile advantages.

Re: Modern Front-end in Rails

#114

Post by rubyfan »

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…

Totally agree with the sentiment. I see engineers put to much time and energy focusing on frameworks and architecture and not enough time on building business value.

The joy of Rails is that for the most part you can just focus on getting shit done, focus on building value instead of figure out the right directory structure or which latest framework to use (learn) on your project.

I have yet to see a demonstrable benefit from the single page app, front end framework, microservice backend that I didn’t have with a Rails monolith 10 years ago. The majority of what I see these days is unwarranted complexity.

Re: Modern Front-end in Rails

#115

Post by pmontra »

demiazz wrote: post #112
pmontra wrote: post #90

Earlier quoted context omitted.

It's probably a matter of tastes, either one project or two projects. I've been working with Rails since 2006 and I'll create two separate projects. A Rails API project and a front end one. Two projects, two repositories, maybe two teams (specialized teams are more common than full stack.) The front end is served by the reverse proxy in front of Rails. If I want to serve some semi-static HTML page from Rails, all I h…

Of course! If you have human resource to separate and maintain backend and frontend - it's an excellent solution. But it's article not for teams like this. The described solution for full-stack developers and small projects, which needs to be maintainable too. And component manner is a proper way to organize frontend code.

I would split in two even if I'm working on it alone.

Re: Modern Front-end in Rails

#116

Post by pdkl95 »

criddell wrote: post #77
jfaucett wrote: post #62

Earlier quoted context omitted.

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

Do you think RoR is a good choice when all you really want is a service with a REST API? I prototyped something in a couple of days with Python and Flask and it made a good enough impression that we are thinking about fully developing the idea. I'm open to just about any tech and am thinking about continuing with Flask (and Flask-restful), using Go, or Ruby on Rails. I have almost no experience with any of these and…

One note about RoR: it's very opinionated about using convention over configuration. It's very efficient if you generally work with it's convention. However, if you design and/or goals are regularly in conflict with those conventions, RoR might not be the best tool to use for that project.

Re: Modern Front-end in Rails

#117

Post by tarsinge »

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…

This completely reflects my experience too, as I recently got back to building line of business apps and clients were impressed by the snappiness of basic Rails apps with server rendered templates. Like you said the impact on complexity (and also important on productivity) of going the SPA route for this kind of apps is not justified for me.

Re: Modern Front-end in Rails

#118

Post by mctx »

criddell wrote: post #96
stevenwoo wrote: post #93

Earlier quoted context omitted.

I'm just learning Flask myself - are you using a database for storage? That's my next step. I've done full apps with RoR and this would not be a question at all with RoR, it's already built in, just toying with Python/Flask to learn stuff.

For the prototype, I just put my data into some json files. Connecting to some kind of database would be my next step if I continue on with it. Probably would use SQLAlchemy. I'm a bit of a REST newbie and so some concepts (esp HATEOAS) are still a bit blurry. I would probably take a little time to dig into just what goes into a well-structured REST service.

Check out Django Rest Framework - it uses Django’s ORM and adds some really nice features for building a decent sized API

Re: Modern Front-end in Rails

#119

Post by demiazz »

pmontra wrote: post #115
demiazz wrote: post #112

Earlier quoted context omitted.

Of course! If you have human resource to separate and maintain backend and frontend - it's an excellent solution. But it's article not for teams like this. The described solution for full-stack developers and small projects, which needs to be maintainable too. And component manner is a proper way to organize frontend code.

I would split in two even if I'm working on it alone.

Ok. Let's see from another side on this point.

If you are beginner Rails developer who doesn't know how to configure Webpack properly and doesn't know how to works with React/Vue/Ember?

And if your project must be a SEO-friendly? You don't know React, Webpack and doesn't know how to works with React/Vue SSR.

Maybe learning its tools will be an excellent investment if you want to be a front-end developer. But what if not?

We wrote this article mainly for beginners full stack developers. They are not well-experienced front-end developers.

Re: Modern Front-end in Rails

#120

Post by [deleted] »

sillysaurus3 wrote: post #88
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…

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

[deleted]
Post reply on HN