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

91–100 of 150 posts

Re: Modern Front-end in Rails

#91

Post by wcarron »

weego wrote: post #72
Can_Not wrote: post #65

Earlier quoted context omitted.

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

So now you've simplified your 1 app server into 2 app servers that aren't even the same language or environment.

Thus creating cleaner, more focused, more testable, likely faster, and more maintainable code bases. Which also adhere to the Single-Responsibility Principle.

We as developers already offload certain tasks to separate servers. Do you use your app server to terminate TLS connections? You could; but why would you when Nginx can do a much better job of it?

You could store you application data like usernames and password in a JSON file if you really wanted to. But why would you when you can run an SQL server and use a real database?

Pick the best tool for each job. JS frameworks handle the view layer better than Rails does.

Re: Modern Front-end in Rails

#92

Post by Can_Not »

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.

Not as mature as rails, obviously, but Adonisjs and sailsjs are options.

Re: Modern Front-end in Rails

#93

Post by stevenwoo »

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…

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.

Re: Modern Front-end in Rails

#94

Post by Can_Not »

weego wrote: post #72
Can_Not wrote: post #65

Earlier quoted context omitted.

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

So now you've simplified your 1 app server into 2 app servers that aren't even the same language or environment.

The Nuxtjs (and the others) SSR peices are not "an entire extra app you write and maintain", it's a small component, mostly already written by the nuxt team, that does one thing. It allows you to write a leaner, better focused backend.

Re: Modern Front-end in Rails

#95

Post by wwweston »

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

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

Re: Modern Front-end in Rails

#96

Post by criddell »

stevenwoo wrote: post #93
criddell wrote: post #77

Earlier quoted context omitted.

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…

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.

Re: Modern Front-end in Rails

#97

Post by trcollinson »

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

In my area, it doesn’t much matter whether they actually have experience in Vue/React/Angular, all three and more are on their resume anyway and they can easily talk about the technologies.

There’s no doubt I have had applicants pass on us because we don’t use one of those frameworks. But there are plenty of other great web devs who do want to work in a reasonable environment and love it. So it’s balanced out.

I’d say my greatest selling point for the job is that we deploy all day long to production. Developers love getting features to users.

Re: Modern Front-end in Rails

#98

Post by jordanlev »

Scarbutt wrote: post #57
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…

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

Or use intercooler, which was inspired by turbolinks but is a completely separate (and non-coffeescript) library: http://intercoolerjs.org/

Re: Modern Front-end in Rails

#99

Post by swanson »

colinsidoti wrote: post #18

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.

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.

Re: Modern Front-end in Rails

#100

Post by Spone »

bsaul wrote: post #41

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

Main reason for me is performance. Especially important on a mid-range smartphone with sloppy network.
Post reply on HN