Rails 7.1 Released

The idea behind ember-data [2] is that the models and their relationships are defined on the frontend side, which implies that the models are the single source of truth for both the frontend and the backend, including the APIs themselves. Ember adheres to json api specification, but there is lots of adapters for other database query languageds and/or storage types [1]

As I said in my previous post, it's a framework based on conventions, so it'd a batteries-included approach to both frontend and backend.

[1] https://emberobserver.com/categories/ember-data-adapters

[2] https://guides.emberjs.com/release/models/

Cool, but why not just use Docker? 2-4GB extra ram overhead and some initial learning curve, add a decent Makefile and.. never worry about local env ever again. Switch back and forth between Mac, Windows, Linux like it's nothing.

1. Rails has had direct upload since it introduced Active Storage. No one has uploaded files through their servers in a decade

2. What do you mean? Point whatever CDN you want at your origin

3. Maybe

3a. Yes

3b. Metadata or a new table

4. GraphQL is the single worst technology that has ever been adopted. We adopted at my company...twice. Twice we made the same mistake now we're stuck with it for mobile clients. In fact we're stuck on the old Graqphl RB gem that used a DSL instead of classes, which also blocks our Rails upgrade. We've been able to revert everything back to good ole Rest for another part of the app. Be cautious adopting technologies of large companies.

I wouldn't necessarily recommend moving from an existing react frontend to hotwire at the same time as upgrading Rails itself. I'd get to Rails 7.1 first/independently.

FWIW the Rails 7+ way of doing single page app JS is also more reasonable than it used to be. You pretty much just use whatever build tool you want in isolation from your rails app. You have to run something like `yarn build --watch` alongside `rails s` in development but IMO that's not so bad and makes things a lot simpler.

My company builds software to automate Rails upgrades, and offers a full service where we'll upgrade Rails for you. steve (at) infield.ai if that's interesting or you can generate a free rails upgrade plan at https://app.infield.ai/users/sign_up (no cc required). https://docs.infield.ai/docs/creating-an-upgrade-path for some more details.

> if you're looking to hire frontend engineers, the candidate pool for React is a few orders or magnitude bigger

Two comments on this - I know it will not change your mind, but maybe other people will read this:

1. Of course, the candidate pool for React is bigger, I think Hotwired - in its current form was released in 2021 (November or December). So this expectation is kinda “Planning to fail” right? If you put this as a criteria of course you are going to choose React. Are you sure you are not already decided to use React and then found reasons for the decision. It is totally fine if you did as we are all doing this constantly (first deciding and then finding reasons or explanations for the decision)

2. I think if you have a React developer (so a person who should know JS and HTML) who cannot write Hotwire code, that is a big problem. Anyone with a good foundation of JS and HTML should be able to write Hotwire code (Stimulus + Turbo)

Recommendation: Don't put in your job ad "Required skill: Hotwired". Just hire people who understand how the web works (browser + HTML ...) and they will be able to write Hotwire-compliant code.

> 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

I am not sure what packages are you trying to find. But I would suggest if you are trying to find an 1-on-1 corresponding React package to Stimulus package the way the UI and UX is designed is not for Hotwire. You should not choose Hotwire to replace React but keep the same page behaviour. You should think your UX web experience different - more back to basics with interactivity sprinkled around

> Stimulus doesn't really offer a way to write unit tests for your controllers

Again if you have an application like say Figma UI then probably you need unit tests. But if you think the UX to be Rails 7 + Hotwire, you will not write so much JS code that you need unit tests for it.

Testing an end-to-end feature should be enough.

Of course, this is just me talking about a product (yours) that I don't know what it is an I am making so many assumptions.