5 ms·

If you’re going for speed of development, it’s hard to beat server side rendering in Rails. The creator built Rails for speed of development and happy engineers

by nthj 6y ago

If you’re going for speed of development, it’s hard to beat server side rendering in Rails. The creator built Rails for speed of development and happy engineers. It’s also very opinionated (convention over configuration) which helps me just build out features rapidly without making thousands of pointless decisions. I am not opposed to React for like, a calendar application, or a particularly complex part of a web app, but most web apps have 90% CRUD and 10% shiny. And with well-tuned SQL and turbolinks dropped on, Rails pages load in 30-60ms with no page refresh.

_benj 6y ago
I agree with you, even thought I might personally prefer Elixir/Phoenix :-) In my particular case thought I've been opting for Golang given that my web app needs to perform a little more that CRUD. And in regards to the CRUD part I've been heavily relying on PostgreSQL functions, thus instead the pain of a ORM I just have simple raw sql `SELECT * FROM api.get_user_data(?,?);` I'm not saying that is not possible to to things like this on Ruby, but when your application is a little more than CRUD RoR starts getting on my way...
- nthj 6y ago
  Sounds like you and I have similar approaches, and I just have more CRUD to manage in my case. For e.g. payment processing endpoints, I use Golang. Managing 3rd party SDKs is nicer in Golang, imo. I also heavily rely on Postgres views, which ActiveRecord just sees as read-only tables, so my Rails code can still call `user.api_data_entries` without any ORM wrangling.
  - _benj 6y ago
    nice!
jack_riminton 6y ago
The happy engineer concept is a much neglected one imo. Rails devs who’ve mastered a lightweight js framework like Stimulus and perhaps a webhook utility like ActionCable are immensely more productive than a team of very separate front and back end devs. Basecamp take this a level further whereby each dev is quite heavily involved in the design process, and their designers can also code in Rails. With Hey I think they’ve shown that it can not only be lightning fast but pretty shiny!
- nthj 6y ago
  Oh I agree, I lost a lot of nuance with my trite 1-sentence summary. Shiny is mostly good judgement, good taste, careful organization and a lot of sweat resulting in well-crafted CSS. Especially in the past few years, as browsers have implemented a lot of animations and scaling in CSS which offloads to the GPU. You don’t want JavaScript/CPU doing that math anymore. Component-based JavaScript frameworks “force” us to organize our CSS in the same way outlawing cars in favor of bikes bikes ensures everyone follows the speed limit.

by nthj 6y ago

_benj 6y ago

I agree with you, even thought I might personally prefer Elixir/Phoenix :-) In my particular case thought I've been opting for Golang given that my web app needs to perform a little more that CRUD. And in regards to the CRUD part I've been heavily relying on PostgreSQL functions, thus instead the pain of a ORM I just have simple raw sql `SELECT * FROM api.get_user_data(?,?);` I'm not saying that is not possible to to things like this on Ruby, but when your application is a little more than CRUD RoR starts getting on my way...

nthj 6y ago
Sounds like you and I have similar approaches, and I just have more CRUD to manage in my case. For e.g. payment processing endpoints, I use Golang. Managing 3rd party SDKs is nicer in Golang, imo. I also heavily rely on Postgres views, which ActiveRecord just sees as read-only tables, so my Rails code can still call `user.api_data_entries` without any ORM wrangling.
- _benj 6y ago
  nice!

jack_riminton 6y ago

The happy engineer concept is a much neglected one imo. Rails devs who’ve mastered a lightweight js framework like Stimulus and perhaps a webhook utility like ActionCable are immensely more productive than a team of very separate front and back end devs. Basecamp take this a level further whereby each dev is quite heavily involved in the design process, and their designers can also code in Rails. With Hey I think they’ve shown that it can not only be lightning fast but pretty shiny!

nthj 6y ago
Oh I agree, I lost a lot of nuance with my trite 1-sentence summary. Shiny is mostly good judgement, good taste, careful organization and a lot of sweat resulting in well-crafted CSS. Especially in the past few years, as browsers have implemented a lot of animations and scaling in CSS which offloads to the GPU. You don’t want JavaScript/CPU doing that math anymore. Component-based JavaScript frameworks “force” us to organize our CSS in the same way outlawing cars in favor of bikes bikes ensures everyone follows the speed limit.