321–330 of 490 posts
The article makes a comparison to react, but that’s a front end library. Does rails also do front end?!
Yep, it builds HTML on the server side and sends it to the browser through normal get requests. Instead of constructing HTML in a mix of JS + HTML (JSX) you typically write a mix of Ruby + HTML called ERB.
Earlier quoted context omitted.
Last I looked the rails like JS framework was https://adonisjs.com/
When I last looked at Adonis I was really turned off, but I don't remember why. Looking again, it seems like the templating is a real weakness, but lots of the other things are nice.
Oh, and also they provide a repl to your app code and data… that is huge and super hard to find in the js world
If you can easily switch to a framework like Rails from a SPA, it's probably a sign your app shouldn't have been a SPA. There's too much "defaultism" in our industry.
I've settled with Svelte (SvelteKit and Sapper), after having spent lots of time with React and Vue. Svelte works in a way that jives with how I think and work, and I've built enough components for myself that side projects now only take hours to design and build into working prototypes. I think everyone needs to have a "home platform" where it's just mindless to get started. Regardless whether it's JS SPAs or Rails…
Ruby has iterators, so you don't need for loops.
list_of_things.each {|thing| thing.dostuff }
Earlier quoted context omitted.
If that's not bad enough you're probably working on a legacy app with a whole bunch of mix-ins, proxies, Active Record callbacks, and other nonsense that makes it nigh on impossible to understand what any code does.
Saying that mixins and callbacks are always incomprehensible is silly. They're just a way to pack up code and they can work beautifully. If you don't wanna use them you're gonna have to write the logic in some alternative way, so a bunch of service objects I guess? Does that automatically make code comprehensible - the fact it's using many small classes? I'm sure people can and are writing shitty services as well.
The common refrain is well, don’t write shitty code then, but all code starts off looking good to the person who wrote it. I guarantee if you have 400 engineers working on a Rails app it will end up in this state because it (ironically) lacks sane guardrails
Earlier quoted context omitted.
When people ask me how to improve their programming this is my first advice - speed read docs/stdlib top to bottom and keep writing a lot of little things. It’s amazing how many people choose painful path of learning through osmosis.
If you want to make an app from scratch, you must first understand the universe. This is a ludicrous approach for most. Sure, if you learn from reading and love to read technical manuals, go for it. But to imply this is the best way for most to learn is completely ridiculous.
there are about 35 guides in the rails guide list and half of those are digging deep into the framework... reading the first 10 of them would get you about 95% of what you really need to know in rails so that you can look up stuff later. hell even just doing the getting started guide walks you through a fairly complete rails application.
And now with the kind of apps you csn make with things like Liveview, there is even vanishing reasons to use things like React. Most React websites did not need React. Even more so in 2022z
I built my last company with Go, Vue.js, gRPC, and Kubernetes. And, wow was it a slog. It was hard for new developers to jump in, we had separate engineers for frontend + backend, and there were things we never even touched - such as real-time/websockets or end-to-end testing. I recently started a new project in the same stack [1], and partway through paused because it was taking so long to deliver customer value. I…
I wish the Go community had a popular monolith framework that folks rallied behind using when necessary. Unfortunately it's a wild west of bodging together your own routing, config, auth, etc. and nothing is consistent.
Ultimately went with Rails. As said in the article: so, so much comes out of the box or from a very well maintained ecosystem.
Real-time dashboards (action cable), background jobs (active jobs, sidekiq), auth, tooling, etc. was each less than a day's work which allows us to launch so freaking fast.
Only real downside in my eyes is the hiring for our location (central Europe) and future UI complexity, where my solution will probably be to just drop in a Vue app where it makes sense.