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

101–110 of 150 posts

Re: Modern Front-end in Rails

#101

Post by krrrh »

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…

I've been noticing the problem of fancy js-driven front-ends on the open web more lately too. I feel like not a day goes by when I don't use some site that just breaks on a certain browser, or exhibits weird unintended ui behaviour with unresponsive buttons or blank page loads. Blogger is a classic example, but I see a lot of sites from travel to banking that used to be perfectly serviceable and boring become unreliable lately and months later the problems don't get fixed. Usually the source reveals angular.js or something like it.

This has got to be costing companies money, but it's hard to say when we'll see a return to simplicity as a virtue.

Re: Modern Front-end in Rails

#102

Post by bpicolo »

and0 wrote: post #82
trcollinson wrote: post #79

Earlier quoted context omitted.

I’ve built rails api only applications for a long time and I find it to be a great experience. Now, to be fair, I pick it because I know Rails very well. But it’s worth taking a look at for sure.

Agreed. My latest project has a Vue front-end (it's a small tool) and Rails does a wonderful job just dumping JSON for the front-end to render. Even if it is a little excessive (which I don't think it is), I have features planned in the future where having an ORM like ActiveRecord+Ruby will make things very simple.

I'm using Vue + Rails atm as well. Terrific stack, very productive. I still lean on pure-rails for pages that aren't the main, interactive app.

Re: Modern Front-end in Rails

#103

Post by jensvdh »

kbutler wrote: post #35
debaserab2 wrote: post #32

Earlier quoted context omitted.

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.

Hypernova is pretty awesome for React as well!

Re: Modern Front-end in Rails

#104

Post by endlessvoid94 »

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?

Re: Modern Front-end in Rails

#105

Post by jfaucett »

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…

> Do you think RoR is a good choice when all you really want is a service with a REST API?

I'm going to be honest with you. I love building pure REST apis in rails. The experience is so clean and effortless.

That being said there is at least one caveat to using RoR for the first time, and thats that the learning curve is probably going to be a little steeper than a rest lib like flask where things are more explicit, since there is a lot of convention over configuration in RoR. Once you learn the conventions, the development speed is ridiculously fast, but until then things can be pretty opaque and take some time to get used to, especially for people who don't understand well how the ruby runtime works. I've witnessed this on multiple occasions with multiple projects, if there are more advanced/not-stack-overflowable things that need to be done, devs who are working in RoR and ruby for the first time, will run into a lot of roadblocks. This has little if anything to do with their particular skills as a programmer and more to do with the dynamic nature of ruby and a lot of very tricky hacks rails does under the surface to make the end-user api clean and succinct.

Re: Modern Front-end in Rails

#106

Post by kuon »

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

Re: Modern Front-end in Rails

#107

Post by evolve2k »

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?

Re: Modern Front-end in Rails

#108

Post by debaserab2 »

wcarron wrote: post #91
weego wrote: post #72

Earlier quoted context omitted.

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…

More testable? Because they are discrete codebases, possibly. It sure sounds like getting a dev environment setup that mirrors the production env just got a lot harder. Given there is an entire new codebase there is now an overall larger coverage area to test.

Faster? I don't see how putting an entire app server layer in between your HTTP requests is going to make anything faster.

More maintainable? You now have an entire codebase duplicating the request your client is making. It actually breaks SRP more than it helps, because you'll need to constantly keep it in sync with your rendering/client codebase in order to perform server rendering. The individual codebases may be more maintainable but your application as a whole now has fragmented responsibilities.

I can't imagine when the trade-off of introducing an entire new layer of infrastructure into your app in addition to your normal app servers would be worth it just for the purpose of server side rendering outside of some specific niche scenario. That sounds like overengineering to the extreme.

Re: Modern Front-end in Rails

#109

Post by hijp »

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.

Re: Modern Front-end in Rails

#110

Post by captain_crabs »

WaxProlix wrote: post #60
captain_crabs wrote: post #37

Earlier quoted context omitted.

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

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.
Post reply on HN