Live data from Hacker News

Doing Rails Wrong

bananacurvingmachine.com

271–280 of 288 posts

Re: Doing Rails Wrong

#271
post #268

Earlier quoted context omitted.

The event handling alone is almost a hundred calls deep. Because a lot of the work is happening asynchronously, you won't see most of it when stepping through the debugger starting from a click handler for example, but try adding a breakpoint to the compiled JSX. With fibers (React >16) and a couple commonly used hooks you'll easily hit a thousand high call stack.

Do you mean that the async chains of something().then(somethingElse()).then(...), into which async/await code desugars, grow 1000 levels deep? I never encountered it, but, OTOH, I did not research this in particular. V8 very definitely does not produce a call stack out of it, but schedules every new Promise as a separate task. (A bit like a Lisp threading macro.) So, what forms 1000 levels of nested calls? Is that an…

I meant the actual React code: handling the click event, running the component code, resolving dependencies and running hooks, building the virtual dom then handing off to react-dom for reconciliation, scheduling updates, and finally modifying the DOM. Not your application code.

The async comment was to point out that if you attach a breakpoint to your `onclick` handler, you will reach 'the end' of execution after less than a hundred function calls. But the actual work (see above) inside react and react-dom hasn't even started, as it's pushed to a queue. This may give the impression that far less code is running than actually is.

This is still in context of "you can read through the library's codebase and understand what it's doing fairly easily"; so yes, it's specific to React being very complex vs something like htmx, which most devs could understand in its entirety in one afternoon.

Re: Doing Rails Wrong

#272
post #143

Earlier quoted context omitted.

i can explain it. (ok, i can't explain why someone would create a react monster instead of using a better suited frontend framework, but i can explain why i prefer to separate backend and frontend) ever since i started using frontend frameworks for websites, the backend has become trivially simple. so simple that i have been able to reuse the same backend for all my websites built since. most websites do not need mor…

My main issue with putting state in the frontend is that you introduced sync points, which is where, like, 90% of the bugs happen. Take form input and validation. Great, let's write out the validation on the frontend. But that doesn't mean much. We need to sync it. Okay... So let's just write the validation, again, on the backend. Hope it's the same validation. It never is, so we just introduced a whole class of bugs…

you have to do the same on the server side and your database, if you have one. the API is just data too. you don't keep all your application state in you database, do you?

i don't know what kind of application you have in mind, but in mine the frontend state and the backend state are entirely different things. the only thing that needs to be kept in sync is the data itself. and that's easier than the whole frontend state which is a lot more complex. in most cases you treat the backend like a database itself. there is n additional state to be kept in the backend, than what goes into the database. at least with all the applications i ever built. i am sure there are other applications that are more complex, and i may change my mind when i get to work on one, but i believe most applications are CRUD, and complex UI state is only in the fronted, data state in the backend/database,

Re: Doing Rails Wrong

#273
post #143

Earlier quoted context omitted.

i can explain it. (ok, i can't explain why someone would create a react monster instead of using a better suited frontend framework, but i can explain why i prefer to separate backend and frontend) ever since i started using frontend frameworks for websites, the backend has become trivially simple. so simple that i have been able to reuse the same backend for all my websites built since. most websites do not need mor…

I don't see much difference between returning some json or displaying the same data in a server side template.

the difference is how the application feels to the user. especially on a slow network. for every pageload in hackernews i have to wait seconds. as an SPA i would not have to wait at all unless i open a new story. because new comments can be loaded in the background while i read, and my own comment submissions can be sent in the background too.

Re: Doing Rails Wrong

#274
post #244

Earlier quoted context omitted.

Batteries included backend frameworks exists in the JS ecosystem, just look at https://adonisjs.com/ . The problem is that the nodejs ecosystem started off with micro-frameworks as the antithesis to what they believed were “overbearing” frameworks, like rails and Django, at the time. I remember express’s selling point was to build quick and dirty.

Even from the POV of micro-frameworks, the JS ecosystem sucks. There's just so many competing half-baked libraries doing the same thing slightly differently and incompatible ways. Compare this to the Ruby ecosystem, where every framework (including Rails) uses Rack, which means that all the frameworks compose together, if that's how you'd like to modularize your monolith. Or the other ecosystem known for its preferen…

It's because JavaScript has no culture

Everyone who works with the web is forced to use it, each coming in with their own opinions of how things should be done.. thus we have the fragmentation

Ruby grew in a large part due to Rails, so everyone that's in—and stayed in—that community has been self selected to share similar ideas of how to build web apps

Re: Doing Rails Wrong

#275
post #272

Earlier quoted context omitted.

My main issue with putting state in the frontend is that you introduced sync points, which is where, like, 90% of the bugs happen. Take form input and validation. Great, let's write out the validation on the frontend. But that doesn't mean much. We need to sync it. Okay... So let's just write the validation, again, on the backend. Hope it's the same validation. It never is, so we just introduced a whole class of bugs…

you have to do the same on the server side and your database, if you have one. the API is just data too. you don't keep all your application state in you database, do you? i don't know what kind of application you have in mind, but in mine the frontend state and the backend state are entirely different things. the only thing that needs to be kept in sync is the data itself. and that's easier than the whole frontend s…

my keyboard swallows keys, to remove ambiguity, i meant to say "there is no additional state to be kept in the backend"

Re: Doing Rails Wrong

#276
post #71

Earlier quoted context omitted.

The parent wasn’t describing an autoscaling deployment system. Rails has a container-based deployment if you actually need that level of complexity.

GP was talking about pre-docker deployments. You could totally deploy immutable Rails AMIs without both Docker and Capistrano.

AMIs were still pretty novel at the time I started (around 2007 like the GP). The standard deployment in the blogs/books was using Capistrano to scp the app over to like a VPS (we did colo) and then run monit or god to reboot the mongrels. We have definitely improved imho!

Re: Doing Rails Wrong

#277
post #30

Stimulus and Hotwire are the "rails way" now. I've read the docs and they still confuse the hell out me. Seems like you're reinveting your own javascript components over and over again. In my opinion Rails 8 + Intertia.js + React so much less "reinventing the wheel" (especially if you use shadcn components).

Stimulus is basically a very small event system with HTML hooks that integrates well with the Rails request lifecycle. I'd love to know if anyone has built anything sophisticated with it because I found it difficult to do anything remotely complex.

What complex thing were you trying to do with it?

Re: Doing Rails Wrong

#278

This is cute but fails to mention how many times in the life a rails application we have to go from bundler to webpacker to sporkets to Propshaft and importmaps to jsbundling. Or from autoloader to zeitwerk or from Turbo to Hotwire and god knows what else. Take a look at ads on rails newsletters and how many of them are professional services to upgrade your rails app.

I’ve done all those updates at real companies with millions of users. They took from an afternoon to maybe a week of single dev time. If you keep your garden tended, weeding it becomes less of a chore.

Re: Doing Rails Wrong

#279
post #266
post #254

Earlier quoted context omitted.

For the consistency/security rules, I meant that any API accessible in the browser is also publicly accessible to anyone. Quite a lot easier to e.g. syphon data out of a system than if they just did SSR. So if you want to avoid that, you'll have to build a proverbial Chinese wall between frontend and backend. And whenever you want to add a feature, you'll have to adjust that wall. For SSR, the devs working on the fro…

For the consistency/security rules, I meant that any API accessible in the browser is also publicly accessible to anyone. not quite. you still need access credentials. having an API doesn't mean that anyone can access it without permission. you protect an API the same way you protect the actual website. Quite a lot easier to e.g. syphon data out of a system than if they just did SSR. if the data is sent to the client…

Yeah, if the API design prevents this, parsing HTML is about as hard. But I've seen a lot of cases where a single request will get you _all_ the data you could ever want, a lot of it not even rendered on the frontend, no need to deal with pagination or anything. Kinda full database access as long as you have an auth token, which any logged in user has.

Re: Doing Rails Wrong

#280
post #279
post #266

Earlier quoted context omitted.

For the consistency/security rules, I meant that any API accessible in the browser is also publicly accessible to anyone. not quite. you still need access credentials. having an API doesn't mean that anyone can access it without permission. you protect an API the same way you protect the actual website. Quite a lot easier to e.g. syphon data out of a system than if they just did SSR. if the data is sent to the client…

Yeah, if the API design prevents this, parsing HTML is about as hard. But I've seen a lot of cases where a single request will get you _all_ the data you could ever want, a lot of it not even rendered on the frontend, no need to deal with pagination or anything. Kinda full database access as long as you have an auth token, which any logged in user has.

those are the cases that make it into the news when someone reports the insecurity of a API they found, and then gets accused for breaking into the website or database.

there are many reasons to prefer SSR over SPA, but covering up incompetence should not be one of them. designing an API is not hard.

Post reply on HN