Live data from Hacker News

Modern Front-end in Rails

evilmartians.com

51–60 of 150 posts

Re: Modern Front-end in Rails

#51
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

One thing you probably hear a lot from Ruby devs: The language makes you happy.

Re: Modern Front-end in Rails

#52
post #2

Wow, I like how readable the text is. The typography in the post is beautiful.

Whenever I see a front-page link about Rails, I always think, " I bet the top comment threads will be about the font or layout rather than the content ". Click, and... yep! It's been about ten years, and you don't see as many Rails posts as you used to, but it still holds true!

I've also been around for getting on 10 years (ok, 8.8, close enough) and this is literally the first time I have heard anyone compliment the typography of a Rails post, let alone noticed it occurring enough to become an identifiable trend.

Am I missing some sort of joke?

Re: Modern Front-end in Rails

#53
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

There really aren't any major benefits/downsides anymore regardless of what you'll read. To clear one thing up, you should compare Rails/Django/Sails (each language's "full" web framework), and Sinatra/Flask/Express (minimalist web frameworks). Each of the full frameworks offer a flavor or configuration of the framework that is focused to building RESTful APIs, and you can build the front end in whatever you want. The only major difference between frameworks in each class will be the language and ecosystem it uses. Of course there will be people that have heavy feelings towards whichever ecosystem they like the most that will tell you it's WAAAYYYY better than the other frameworks, but in reality it's nonsense.

When starting a new project, my major decision is if I want to use the REST API flavor of one of these frameworks + react on the front end (substitute with your front end framework of choice), or build the project fully in the framework itself. I've been writing a lot of python lately, so I go with flask for small or quick/dirty stuff, Django or Django Rest Framework for bigger stuff. React on the front end if it needs to be a SPA.

Re: Modern Front-end in Rails

#54
post #2

Wow, I like how readable the text is. The typography in the post is beautiful.

Whenever I see a front-page link about Rails, I always think, " I bet the top comment threads will be about the font or layout rather than the content ". Click, and... yep! It's been about ten years, and you don't see as many Rails posts as you used to, but it still holds true!

I don't understand the correlation between the font and it being a post about Rails.

Re: Modern Front-end in Rails

#55
post #53
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

There really aren't any major benefits/downsides anymore regardless of what you'll read. To clear one thing up, you should compare Rails/Django/Sails (each language's "full" web framework), and Sinatra/Flask/Express (minimalist web frameworks). Each of the full frameworks offer a flavor or configuration of the framework that is focused to building RESTful APIs, and you can build the front end in whatever you want. Th…

> There really aren't any major benefits/downsides anymore regardless of what you'll read

Who made you the grand arbiter? There are huge differences. Rails is miles ahead in the options you present. Probably 90% of startups that don't have a specific reason not to, use Rails - and rightly so.

Rails has over 65k commits. Django has 25k. Sails? Less than 7k. Don't tell me these are equivalent.

Re: Modern Front-end in Rails

#56

> As developers, however, we usually care about > 1. isolated, reusable, testable code that is easy to reason > about; > 2. short “code change → visible result” cycle; > 3. straightforward dependency management; and > well-maintained tools. > Sure, “classic” Rails gives our code some structure: there > are separate folders for view templates, javascripts, > stylesheets and images. But as the front-end complexity > gr…

NPM is a well-maintained tool. Version 5 got major updates in speed and usability. They where aware of the Node release cycle and implemented the new version in advance so it would be rolled out alongside Node. NPM now does way faster caching than before, can lock dependencies in specific versions more easily (inspired by Yarn) and may have a flat dependency tree if your project demands it (like when using Polymer and it's components. like Bower works).

Re: Modern Front-end in Rails

#57

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

Re: Modern Front-end in Rails

#59

Rails is still a truly incredible framework and it still moving very fast in terms of development. It’s front end stuff has always felt wrong to me and many others and we found weird ways to doing what we wanted. Rails 5 added support for a lot of them as the article points out but it still feels complicated. Rails is awesome bc it’s opinionated but the fact that it’s ruby still lets you do what you want. I think rai…

Totally agree. You can go the .js.erb views and `$('#div_id').replaceWith('')` route, or you can use render_to_string and put your partial HTML in JSON and replace it with frontend JS, and so on and so on. And there's also turbolinks to consider and the idempotent stuff.

It's all great, I got my way around it, but I never know if what I'm doing is considered best practice or not.

Re: Modern Front-end in Rails

#60

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

Post reply on HN