6 ms·

Rails on the backend doesn’t get the credit it deserves. On the front-end it’s been a mess for a really long while now though

roboben 3y ago
I agree. What are options here? Rails in API-only mode?
- Pungsnigel 3y ago
  Yeah, that’s one approach. Works great
- crystaln 3y ago
  But why? So many more performant frameworks for this in strongly typed languages to boot.
  - roboben 3y ago
    Which ones? Never saw another one which comes with the same comfort of batteries included like rails. For example having database migrations built in etc.
    - ulizzle 3y ago
      Yeah exactly. All that boilerplate stuff is such a pain to write or maintain long term.
      - ssijak 3y ago
        Boilerplate is 1% of time, rest is solving real domain problems
    - gomoboo 3y ago
      ASP.NET (C#) has migrations: https://learn.microsoft.com/en-us/ef/core/managing-schemas/migrations/?tabs=dotnet-core-cli https://learn.microsoft.com/en-us/ef/core/managing-schemas/m...
    - ssijak 3y ago
      Migrations are easy to do in literally every framework in any language
    - KronisLV 3y ago
      > For example having database migrations built in etc. I actually went the exact opposite route, at least when possible: https://github.com/amacneil/dbmate https://github.com/amacneil/dbmate Pure SQL migrations, regardless of the back end technology that you use, completely decoupled from how each framework/library views things and therefore not dependent on them (you could even rewrite the back end in another technology later on, if needed; or swap ORMs; or avoid issues when there's a major ORM version update). It's really nice when you can generate entity mappings based on a live database, like with https://blog.jetbrains.com/dotnet/2022/01/31/entity-framework-core-inside-rider-ui-way/#existing-database-scaffolding https://blog.jetbrains.com/dotnet/2022/01/31/entity-framewor... So in my case, I can have: * a DB that has migrations applied with dbmate, completely decoupled from any back end(s) that might use it * a back end that has entity mappings for ORM (if used) generated from the live local test database container during development, used for an API and not much more * a front end that's typically a SPA using the API, but is otherwise just a bunch of prepared files that can be served off of any web server Of course, if you need SSR then things move around a bit, but that decoupling works great for me (but might not for others)!
  - ulizzle 3y ago
    That’s what a lot of people do. The value is still about convention over configuration IMO. If we are building a REST API, typical CRUD, you can go a long way with using Rails there and using something else when you need the performance or a certain feature.
  - zoky 3y ago
    Ruby is strongly typed.
    - crystaln 3y ago
      Excuse me. Statically typed.
    - berkes 3y ago
      There is no agreed upon definition of "strongly typed", so it depends on your interpretation of that term. Ruby is not, however statically typed, nor does it have a type checker (well, there is sorbet and RBS) Those are fixed terms.
    - deleted 3y ago
      [deleted]
  - Rapzid 3y ago
    The performance of Rails serializers is still a nightmare. God awful performance.
    - crystaln 3y ago
      20 years on… “Just use another framework when you need performance” they say.
      - Rapzid 3y ago
        Also 20 years on the http client still doesn't have proper timeouts.
    - berkes 3y ago
      > The performance of Rails serializers is still a nightmare Well, The performance of Ruby is still a nightmare. Not just serializers. It's that serializers in Rails are the most prominent place where you'll have cpu-bound performance made visible. But really. Just try anything cpu-bound (e.g. transform a huge list or CSV or so), and the lack of native, safe, threading, the horrendous performance of both the JIT compiler and the runtime and the language become apparent. This isn't to criticize Ruby. Because once you see all the runtime inflection, the way it can modify itself runtime and the DSL magic it allows, the current performance is a magnificent feat! It should be impossible to have it perform at all, given these features. That people managed to make such a beautiful language, with such marvelous features and still have it perform like it does, is a true engineering marvel.
      - throwthrow5643 3y ago
        > It's that serializers in Rails are the most prominent place where you'll have cpu-bound performance made visible. Sorry, what other interpreted language has significantly better serializiation/deserialization performance than Ruby?
        berkes 3y ago
        Python, PHP and JavaScript have significantly better performance for cpu-bound programs. E.g. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/ruby-php.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... And I have measured ser/de for PHP, Ruby (and Rust, we needed to know how much faster JSON serde in rust would be, and compared it to Ruby and PHP). Php is probably much faster because the JSON ser/de is apparently written in C.
  - diogenes4 3y ago
    Same reason as always—it's useful for rapid prototyping. It's not like the frontend was ever rails's strong suit.
    - crystaln 3y ago
      For prototyping you don’t need a back end. You barely need one for production. Just some cloud functions and a cloud database. Firestore, gcf, or equivalent.
      - diogenes4 3y ago
        Can't use any of them on a plane.
- ulizzle 3y ago
  I think that’s pretty much it for big apps if we go with batteries included. Only Java frameworks compare on that front and if you’re a Ruby guy you likely don’t like Java. I’ve been liking Golang but I haven’t had a job that used it in a while. Who knows what’s it’s like right now
Pungsnigel 3y ago
I love the new hotwire stuff. What don’t you like about thd front-end?
- bradgessler 3y ago
  Asset pipeline is a hot mess: https://fly.io/ruby-dispatch/making-sense-of-rails-assets/ https://fly.io/ruby-dispatch/making-sense-of-rails-assets/ Propshaft should bring sanity back to it, but its going to be a while before that's mainstream.
  - ulizzle 3y ago
    That has been a hot mess for almost a decade now.
  - mosselman 3y ago
    This is all about to change. A totally new way of using assets is coming with Propshaft which replaces Sprockets
    - caseyohara 3y ago
      I honestly can’t tell if your comment is sarcastic because my biggest gripe with Rails is that the asset story changes radically with every major release. Starting with 3.2 and the introduction of the asset pipeline, every new version was “This is all about to change. A totally new way of using assets is coming.” Every new version is supposed to solve all of the problems of the previous version. It’s exhausting to constantly change to keep up with the new One True Way™, only for it to be replaced with another assets strategy powered by a gem with a cute name. RJS and Prototype, then UJS and jQuery, then Sprockets and CoffeeScript and Sass, then Turbolinks, SCSS, then Dart Sass, then Stimulus and Webpacker, then esbuild and TypeScript, then Turbo, then import maps but there’s also jsbundling/cssbundling, then Hotwire, then Strada, then “Turbo 8” and TypeScript is suddenly phased out because DHH doesn’t like it, and now Bun. I’m probably leaving something out and this is certainly out of order. But my point stands: the prescribed way of handling assets with Rails is ridiculous.
gls2ro 3y ago
> On the front-end it’s been a mess for a really long while now though I don't disagree, but also front-end was a mess for a long time. Now Rails (with Rails 7.1 + Hotwired + Importmaps) is a pleasure to work with. But we had to wait for good support in browsers of at least ES6 + Import Maps. See the date of this article here: https://web.dev/import-maps-in-all-modern-browsers/ https://web.dev/import-maps-in-all-modern-browsers/ -> 28 March 2023 announcing importmaps is available on all modern browsers. Thus there was no way around Webpack Yarn or any other helping tool for JS until now. Now we have importmaps and good support in browsers for east least ES6 (https://caniuse.com/?search=es6 https://caniuse.com/?search=es6) thus there is almost no need for extra tooling so you can write modern JS.

roboben 3y ago

I agree. What are options here? Rails in API-only mode?

Pungsnigel 3y ago
Yeah, that’s one approach. Works great
crystaln 3y ago
But why? So many more performant frameworks for this in strongly typed languages to boot.
- roboben 3y ago
  Which ones? Never saw another one which comes with the same comfort of batteries included like rails. For example having database migrations built in etc.
  - ulizzle 3y ago
    Yeah exactly. All that boilerplate stuff is such a pain to write or maintain long term.
    - ssijak 3y ago
      Boilerplate is 1% of time, rest is solving real domain problems
  - gomoboo 3y ago
    ASP.NET (C#) has migrations: https://learn.microsoft.com/en-us/ef/core/managing-schemas/migrations/?tabs=dotnet-core-cli https://learn.microsoft.com/en-us/ef/core/managing-schemas/m...
  - ssijak 3y ago
    Migrations are easy to do in literally every framework in any language
  - KronisLV 3y ago
    > For example having database migrations built in etc. I actually went the exact opposite route, at least when possible: https://github.com/amacneil/dbmate https://github.com/amacneil/dbmate Pure SQL migrations, regardless of the back end technology that you use, completely decoupled from how each framework/library views things and therefore not dependent on them (you could even rewrite the back end in another technology later on, if needed; or swap ORMs; or avoid issues when there's a major ORM version update). It's really nice when you can generate entity mappings based on a live database, like with https://blog.jetbrains.com/dotnet/2022/01/31/entity-framework-core-inside-rider-ui-way/#existing-database-scaffolding https://blog.jetbrains.com/dotnet/2022/01/31/entity-framewor... So in my case, I can have: * a DB that has migrations applied with dbmate, completely decoupled from any back end(s) that might use it * a back end that has entity mappings for ORM (if used) generated from the live local test database container during development, used for an API and not much more * a front end that's typically a SPA using the API, but is otherwise just a bunch of prepared files that can be served off of any web server Of course, if you need SSR then things move around a bit, but that decoupling works great for me (but might not for others)!
- ulizzle 3y ago
  That’s what a lot of people do. The value is still about convention over configuration IMO. If we are building a REST API, typical CRUD, you can go a long way with using Rails there and using something else when you need the performance or a certain feature.
- zoky 3y ago
  Ruby is strongly typed.
  - crystaln 3y ago
    Excuse me. Statically typed.
  - berkes 3y ago
    There is no agreed upon definition of "strongly typed", so it depends on your interpretation of that term. Ruby is not, however statically typed, nor does it have a type checker (well, there is sorbet and RBS) Those are fixed terms.
  - deleted 3y ago
    [deleted]
- Rapzid 3y ago
  The performance of Rails serializers is still a nightmare. God awful performance.
  - crystaln 3y ago
    20 years on… “Just use another framework when you need performance” they say.
    - Rapzid 3y ago
      Also 20 years on the http client still doesn't have proper timeouts.
  - berkes 3y ago
    > The performance of Rails serializers is still a nightmare Well, The performance of Ruby is still a nightmare. Not just serializers. It's that serializers in Rails are the most prominent place where you'll have cpu-bound performance made visible. But really. Just try anything cpu-bound (e.g. transform a huge list or CSV or so), and the lack of native, safe, threading, the horrendous performance of both the JIT compiler and the runtime and the language become apparent. This isn't to criticize Ruby. Because once you see all the runtime inflection, the way it can modify itself runtime and the DSL magic it allows, the current performance is a magnificent feat! It should be impossible to have it perform at all, given these features. That people managed to make such a beautiful language, with such marvelous features and still have it perform like it does, is a true engineering marvel.
    - throwthrow5643 3y ago
      > It's that serializers in Rails are the most prominent place where you'll have cpu-bound performance made visible. Sorry, what other interpreted language has significantly better serializiation/deserialization performance than Ruby?
      - berkes 3y ago
        Python, PHP and JavaScript have significantly better performance for cpu-bound programs. E.g. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/ruby-php.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... And I have measured ser/de for PHP, Ruby (and Rust, we needed to know how much faster JSON serde in rust would be, and compared it to Ruby and PHP). Php is probably much faster because the JSON ser/de is apparently written in C.
- diogenes4 3y ago
  Same reason as always—it's useful for rapid prototyping. It's not like the frontend was ever rails's strong suit.
  - crystaln 3y ago
    For prototyping you don’t need a back end. You barely need one for production. Just some cloud functions and a cloud database. Firestore, gcf, or equivalent.
    - diogenes4 3y ago
      Can't use any of them on a plane.
ulizzle 3y ago
I think that’s pretty much it for big apps if we go with batteries included. Only Java frameworks compare on that front and if you’re a Ruby guy you likely don’t like Java. I’ve been liking Golang but I haven’t had a job that used it in a while. Who knows what’s it’s like right now

Pungsnigel 3y ago

I love the new hotwire stuff. What don’t you like about thd front-end?

bradgessler 3y ago
Asset pipeline is a hot mess: https://fly.io/ruby-dispatch/making-sense-of-rails-assets/ https://fly.io/ruby-dispatch/making-sense-of-rails-assets/ Propshaft should bring sanity back to it, but its going to be a while before that's mainstream.
- ulizzle 3y ago
  That has been a hot mess for almost a decade now.
- mosselman 3y ago
  This is all about to change. A totally new way of using assets is coming with Propshaft which replaces Sprockets
  - caseyohara 3y ago
    I honestly can’t tell if your comment is sarcastic because my biggest gripe with Rails is that the asset story changes radically with every major release. Starting with 3.2 and the introduction of the asset pipeline, every new version was “This is all about to change. A totally new way of using assets is coming.” Every new version is supposed to solve all of the problems of the previous version. It’s exhausting to constantly change to keep up with the new One True Way™, only for it to be replaced with another assets strategy powered by a gem with a cute name. RJS and Prototype, then UJS and jQuery, then Sprockets and CoffeeScript and Sass, then Turbolinks, SCSS, then Dart Sass, then Stimulus and Webpacker, then esbuild and TypeScript, then Turbo, then import maps but there’s also jsbundling/cssbundling, then Hotwire, then Strada, then “Turbo 8” and TypeScript is suddenly phased out because DHH doesn’t like it, and now Bun. I’m probably leaving something out and this is certainly out of order. But my point stands: the prescribed way of handling assets with Rails is ridiculous.

gls2ro 3y ago

> On the front-end it’s been a mess for a really long while now though I don't disagree, but also front-end was a mess for a long time. Now Rails (with Rails 7.1 + Hotwired + Importmaps) is a pleasure to work with. But we had to wait for good support in browsers of at least ES6 + Import Maps. See the date of this article here: https://web.dev/import-maps-in-all-modern-browsers/ https://web.dev/import-maps-in-all-modern-browsers/ -> 28 March 2023 announcing importmaps is available on all modern browsers. Thus there was no way around Webpack Yarn or any other helping tool for JS until now. Now we have importmaps and good support in browsers for east least ES6 (https://caniuse.com/?search=es6 https://caniuse.com/?search=es6) thus there is almost no need for extra tooling so you can write modern JS.