81–90 of 245 posts
Earlier quoted context omitted.
Comparing the two: I have a hard time understanding how one could write FE code using classes (Stimulus) in 2023, when simple functions with inputs and outputs are there for the taking. It's just asking for trouble and hidden complexity. Choose wisely!
> when simple functions with inputs and outputs And the state library, and the hooks for side effects, and the SSR, and the hydration, and the VDOM, and... It's not that simple.
Earlier quoted context omitted.
Then that was not a good candidate from the get go? What about hiring people that really care about the product they're building and not just tool fanatics?
One good reason to avoid a job doing Hotwire is so that you can take a job doing React for a similar amount, where your experience applies better and where you'll gain more transferrable experience. In short, it's probably better for your career to work on React.
What I don't get is why as an owner/stakeholder/CTO/lead would pick the worse tool (in some context) just because everyone is using it. Well, I do get it... I just don't agree.
If you read between the lines here, everyone is just picking React because everyone else is picking React, that's the only reason apparently. It drives me mad, but honestly I do understand it.
Earlier quoted context omitted.
But why? So many more performant frameworks for this in strongly typed languages to boot.
Ruby is strongly typed.
Ruby is not, however statically typed, nor does it have a type checker (well, there is sorbet and RBS) Those are fixed terms.
Earlier quoted context omitted.
I love the new hotwire stuff. What don’t you like about thd front-end?
Asset pipeline is a hot mess: 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.
Earlier quoted context omitted.
But why? So many more performant frameworks for this in strongly typed languages to boot.
Same reason as always—it's useful for rapid prototyping. It's not like the frontend was ever rails's strong suit.
Earlier quoted context omitted.
Then that was not a good candidate from the get go? What about hiring people that really care about the product they're building and not just tool fanatics?
One good reason to avoid a job doing Hotwire is so that you can take a job doing React for a similar amount, where your experience applies better and where you'll gain more transferrable experience. In short, it's probably better for your career to work on React.
Earlier quoted context omitted.
What is SSR with slim?
I think they mean Server Side Rendering (normal rails controllers/views), and Slim is just the name of the templating engine. It's a little nicer than the default ERB. https://github.com/slim-template/slim There's also SSR with react and other js frameworks, but I don't think that's what they meant.
Earlier quoted context omitted.
But why? So many more performant frameworks for this in strongly typed languages to boot.
The performance of Rails serializers is still a nightmare. God awful performance.
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.