Earlier quoted context omitted.
I live in a very HCOL country, companies abroad can’t match local market pay.
What is HCOL?
High cost of living
Rails 7.1 Released
191–200 of 245 posts
Re: Rails 7.1 Released
#192Re: Rails 7.1 Released
#193Don't get me wrong, I love Rails, and have been using it off and on since Rails 2. It's a really good framework, and for someone like me who needs to stand up a website from time to time it really is the path of least resistance. What bugs me is the pain of setting up a new laptop to run Rails. I need node, which means npm. I'm a backend guy, I don't understand how to set up node, what order to do things in, etc. I d…
What are you comparing Node to? Other typical back ends are more complicated (except Go) Java, C#, Python for example
dotnet new webapi - for apis
dotnet new webapp - for crud
dotnet new react - using react
How is that complicated?
Re: Rails 7.1 Released
#194Rails is great, and better than ever. I've spent most of my early years in the field working with Django and Laravel, then moved to frontend doing [all the usual stuff we do nowadays] and this year I was assigned back to a Rails + Hotwire project. I'm truly amazed how much simpler things are. I feel sad most of us have forgotten how easier things could be, and I'm terrified about new people joining this industry that…
I'd like to throw in Phoenix LiveView here. Rails wins every battle for initial development speed, as the conventions are so thorough and well thought out that nothing even remotely comes close. Laravel is creeping in, but it's not there yet IMO. LiveView however, scales better (in every sense of the word). It also comes with batteries included (auth, database access, jobs, mailer, complete testing kit etc), little-t…
Just gave it a look. Dynamically typed. IMO if scalability is on the table, having types is a huge benefit.
It saddens me that ruby, python, elixir, JS... many of the best and most productive backend frameworks have types as an afterthought only.
Rust is cool, but it's also hard to write(did last year's AoC using it, and it was fast to run, slow to write).
Anyone have any recommendations for me? Should I look at go/gin perhaps? No Java please - I need type inference because I'm a spoiled baby.
Edit: anyone tried crystal? Looks promising, but doesn't seem popular...
Re: Rails 7.1 Released
#195Earlier quoted context omitted.
I'm working on a fairly recent Rails 7 code base. We initially started using Stimulus, but are now considering switching to React for a few reasons: - if you're looking to hire frontend engineers, the candidate pool for React is a few orders or magnitude bigger - it's getting harder and harder to find vanilla JS packages that you can wrap in Stimulus controllers for common tasks, compared to finding React packages -…
> if you're looking to hire frontend engineers, the candidate pool for React is a few orders or magnitude bigger The trick is not to look for React developers, or Stimulus developers, but to look for frontend developers. Those who can competently write javascript/typescript, have a good understanding of browser apis, and are competent in css and html.
Agreed, Stimulus is so simple that there's almost no prerequisite other beyond a basic understanding of HTML and javascript, both things that any "React developer" and even most "backend" web developers should already have.
Maybe I'm biased but I feel like rails + stimulus makes it incredibly easy for anybody with any kind of programming background to grok the entire project, and maybe you can reconsider even even having dedicated "frontend developers" at all. I know that specialization is a thing, but it's just so easy to be a "full stack" developer on such an app that I think almost anybody could pick it up.
Re: Rails 7.1 Released
#196Earlier quoted context omitted.
I'm using both on two different customers. I have a preference for Rails. The project structure of a Rails project is fixed and it's easy to jump into somebody's else project. The structure of a Django project is potentially pure anarchy, good luck with that. That's mitigated by the lack of autoloading so you can learn the structure of the project by looking at the import statements at the top of the files. Unfortuna…
> That's mitigated by the lack of autoloading so you can learn the structure of the project by looking at the import statements at the top of the files. Unfortunately that means that you have to waste time by writing those imports. Although its been a while, I do remember struggling a lot with autoloading in rails for two reasons: you can't find your dependencies from the code itself and when it breaks down its quite…
> > Model.objects.filter(...)
> Its called a manager. I understand you don't like to type 'objects', it fits in the rails culture of being allergic to redundancy, though I can't really empathize with it.
The point it that the objects method adds zero information to the statement. However it's an opportunity to add a soon to be discovered bug when Django crashes because one forgets to type .objects
They should have made filter a method of all model classes and of the models.Manager class. Same thing for all its sibling methods.
Re: Rails 7.1 Released
#197Earlier quoted context omitted.
A significant part of that ""reacted badly"" was a bunch of kids and YouTuber idiots spamming GitHub with meaningless comments, issues and PRs. Those people don't come out of it looking respectable, regardless of DHH's approach.
I mean yeah sure but DHH does seem to enjoy the controversy a bit. Either that or he’s really good at unintentionally courting it.
There's nothing unintentional about it, it's a strategy they employ since 2006/7. They have an entire chapter about it in their first book "Getting Real"[0]:
> […] One bonus you get from having an enemy is a very clear marketing message. People are stoked by conflict. And they also understand a product by comparing it to others. With a chosen enemy, you’re feeding people a story they want to hear. Not only will they understand your product better and faster, they’ll take sides. And that’s a sure-fire way to get attention and ignite passion.
Re: Rails 7.1 Released
#198Currently stuck on a fairly large code base on rails 6 with a ton of react and trying to upgrade to the new “non”-JS way with Hotwire. Wish me luck Rails is great when you stick with the defaults and a land of pain as soon as you leave them.
Goodreads is an example of a Rails victim like yours. They customized the app on top of Rails, and it's been so bad that Goodreads is dead in the water and has not received major tech updates despite Amazon throwing engineers at it. Ruby is a dangerous language to refactor, so often you're locked for a long time. See also: Every blog post about Rails upgrades ever (see also: Stockholm syndrome)
Are you sure Goodreads did not received updates because of Rails?
Here is a competitor build with Rails https://thestorygraph.com/
Seems kinda cool. So I think Rails is not the problem here.
Re: Rails 7.1 Released
#199Don't get me wrong, I love Rails, and have been using it off and on since Rails 2. It's a really good framework, and for someone like me who needs to stand up a website from time to time it really is the path of least resistance. What bugs me is the pain of setting up a new laptop to run Rails. I need node, which means npm. I'm a backend guy, I don't understand how to set up node, what order to do things in, etc. I d…
The latest version of Rails 7 works out of the box with importmaps so no node (nor yarn or any other version manager) is required.
Re: Rails 7.1 Released
#200Earlier quoted context omitted.
> 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.
I know react is moving towards SSR quite a lot but I don't think hydration or SSR are actually common for react devs to care about. You also have very similar issues with hotwire, so I'm not sure it makes React more complicated. For all its flaws, React is still extremely "small" as far as front end and server side front end goes. That might change with the increased push towards next.js and SSR though.
Very true. For every day dev, all the framework bits are stuff the average dev doesn't need to know at all. Ie, none of the devs at my company know anything about that, and that's just fine. We get a ton of work done.