Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Doing Rails Wrong

bananacurvingmachine.com

Post reply on HN
Print view View original

261–270 of 288 posts

Re: Doing Rails Wrong

#261

Post by misiek08 »

timr wrote: post #166
bguthrie wrote: post #150

Earlier quoted context omitted.

My recollection is that this is what many Capistrano setups were doing under the covers. Capistrano was just an orchestration framework for executing commands across multiple machines. More than that, I worked for many enterprises that were using Rails but had their own infrastructure conventions and requirements, and were unable or unwilling to explore tools like Capistrano or (later) Heroku.

> More than that, I worked for many enterprises that were using Rails but had their own infrastructure conventions and requirements, and were unable or unwilling to explore tools like Capistrano or (later) Heroku. Well, OK, so you remember a bad setup that was bad for whatever reason. My point is that there's nothing about your remembered system that was inherent to Rails, and there were (and are) tons of ways to dep…

If you call a stable, testable and „reproducible” (by running locally or on some dev machine) tarball worse than git pull then you are the one who is killing the solutions that work with unpredictable and unsafe world. I think beer with swapping stories is a good idea, because I would love to learn what to avoid.

Re: Doing Rails Wrong

#262

Post by array_key_first »

em-bee wrote: post #143
fhd2 wrote: post #68

Earlier quoted context omitted.

I was hiring for a Django dev earlier this year. For the case study, almost all of them built a thin API backend in Django, and a React monster for the frontend (and in some cases, pretty much all the business logic). When asked about their motivations, almost nobody could explain it. We hired one of the very few people that just used SSR.

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 around that.

Or just take a look at routing. Okay, let's route on the frontend. But what about access control? Okay, let's do a little routing logic on the backend too. Oh and now we've run into the same problem.

When you do rich frontend and backend, you always have a minimum of two application states. You have two apps. You cannot get rid of the backend state, it's non-negotiable.

So you have to keep them in sync, or more accurately, try to keep them in sync.

Re: Doing Rails Wrong

#263

Post by array_key_first »

b_e_n_t_o_n wrote: post #224
JodieBenitez wrote: post #223

Earlier quoted context omitted.

I fail to see the connection with jquery. Anyway brittle and hard to maintain is what we experience now with frontend stacks and codebases with very short lifespan. I can't keep track of components libs du jour that come and go and keep being reinvented with very little value added on each iteration, along with constant api breakage. Brittle, indeed. Meanwhile, Rails and Django have been rock solid.

Both jquery and htmx style approaches lack the concept of components, data flow, template binding etc. At most you get string templates. You end up manually wiring up dom updates when state changes, and that kind of thing is brittle and is why stuff like React was invented in the first place. React has been very stable throughout its life time. You can run 10yo react code in v19x without issues.

The reason HTMX lacks the concept of components is because you already have components.

Components are backend logic in an SSR application. If we have some component and the associated HTML BS JS, we're good to go. Virtually all backend frameworks have components.

Whats the advantage of this? We have one component. When we use react or vue, we now have two. The backend one and the frontend one, and they're not the same component. We can kind of force them to talk together over JSON and an API.

Re: Doing Rails Wrong

#264

Post by array_key_first »

tshaddox wrote: post #206
AstroBen wrote: post #172

Earlier quoted context omitted.

"Islands" are really nice for this. The highly interactive pieces are usually only a small part of the app - just mount a component there if it's suitable. You don't need a full blown SPA

Islands probably have some runtime performance benefits, but the dev experience and build-time complexity is probably just as high or higher than most JavaScript SPA setups.

IMO no, because with a SPA everything has to be a SPA, which is incredibly inconvenient.

The benefit of the island is only the island has to be a SPA. The rest can be SSR.

Re: Doing Rails Wrong

#265

Post by matltc »

rco8786 wrote: post #47
poorman wrote: 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).

I'm a huge rails fanboi but the state of Stimulus and Hotwire make me sad. The concepts are awesome, and I think the execution might even be good. But the documentation is so incredibly horrible that I have a hard time even getting started, and I can't learn enough about it to answer the question of whether or not using it in any given project will end with me painted into a corner.

I feel so validated! When I started learning web dev, I was working through The Odin Project's Rails course. All smooth sailing til I hit the Turbo/Stimulus/Hotwire sections.

I thought I was stupid or just terrible at JS/front-end stuff, because I would read and re-read the same chapter in the Stimulus docs and become more confused.

Now I'm mainly in TS-node/React land, and boy do I miss Rails.

Re: Doing Rails Wrong

#266

Post by em-bee »

fhd2 wrote: post #254
em-bee wrote: post #218

Earlier quoted context omitted.

Do you really want to expose a full CRUD API, or are there consistency/security rules you want to enforce? That's cool, but makes API design a little more challenging and frontend development a little more frustrating. fair point, however i don't see that as a drawback. the security/consistency rules you want anyways. and an API makes it easier to enforce them and not allow people working on the frontend to get aroun…

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, then the client ca access it either way. sure, embedding it in HTML makes it harder to parse, but that is really just security by obscurity. that's actually another reason why i prefer APIs. they make it blatantly obvious what data you are publishing. in a SSR page it is easier to let things slip through. the SSR page looks like a closed box, it gives the impression that it is possible to prevent users from entering that box and getting data out of it, but that is an illusion.

you'll have to build a proverbial Chinese wall between frontend and backend.

which is the API. small, only containing what is needed, very easy to verify that private data doesn't leak out.

Re: Doing Rails Wrong

#267

Post by lambdaone »

spoiler wrote: post #256
lambdaone wrote: post #249

Earlier quoted context omitted.

Once you give up any hope of understanding the inner workings of the frameworks you are using, you're no longer a programmer, you're a cargo cultist. Now compound this a dozen levels deep, with systems piled on systems built by people who don't understand the other systems they are building on top of, and you have the current mess.

Every engineer in our industry is a Cargo cultist by that definition. Including experts. Where do you draw the line? I'm sure you have one, but your line is no less arbitrary than mine or someone elses.

A competent programmer should be able to at least conceptualise every level from the transistor up - not necessarily completely understand, but at least know roughly what it does, and what it rests on, and what rests on it. Transistors, gates, logic, state machines, instruction sets, assemblers, parsers, compilers, interpreters, operating systems, memory allocation, graphics, browsers, that sort of thing. Not at all unreasonable for someone with a decent computer science degree, surely?

Of course, you don't have to know any of that to grasp how to bang a page together with today's web frameworks; but you end up with the resource-hogging unmaintainable security disaster that is the modern web in the process.

Re: Doing Rails Wrong

#268

Post by nine_k »

ricardobeat wrote: post #252
nine_k wrote: post #215

Earlier quoted context omitted.

I don't think a typical React rendering call is even 100 calls deep. React itself adds maybe a dozen frames. Your components could be complicated, but likely they don't add more than another dozen or two. React is pretty efficient if you hold it right, and use for its intended purpose, that is, large and complex interactive UIs.

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 anything specific to React? I'm very curious now!

Re: Doing Rails Wrong

#269

Post by spoiler »

lambdaone wrote: post #267
spoiler wrote: post #256

Earlier quoted context omitted.

Every engineer in our industry is a Cargo cultist by that definition. Including experts. Where do you draw the line? I'm sure you have one, but your line is no less arbitrary than mine or someone elses.

A competent programmer should be able to at least conceptualise every level from the transistor up - not necessarily completely understand, but at least know roughly what it does, and what it rests on, and what rests on it. Transistors, gates, logic, state machines, instruction sets, assemblers, parsers, compilers, interpreters, operating systems, memory allocation, graphics, browsers, that sort of thing. Not at all…

Ok, but I've worked with people who are pretty good with web dev, but I guarantee you they don't know how memory gets requested from the operating system.

Like, sure it helps in some contexts, but in their context it would largely be irrelevant.

For the wast majority of people, it's fine for them to know basic tradeoffs between stdlib container types. Most web performance problems today come from misusing tools, whether container types, bad algorithms, memory leaks (and I don't think knowing how an OS manages memory would help them in JS for example), DOM pollution, or oversized assets or whatever. And my take is that that people are often too overworked to care about it, rather than lacking awareness about these things lol

On the other hand, if you're a systems engineer, then you absolutely do needs to know all of this stuff.

And I bet you they'd navigate stuff like better than a systems engineer, because that's more useful to their day to day!

Re: Doing Rails Wrong

#270

Post by CobrastanJorji »

phoehne wrote: post #159
CobrastanJorji wrote: post #25

Earlier quoted context omitted.

I really appreciate the power of JS's openness to writing entire new platforms. It's a great thing that everybody gets a chance to reinvent the wheels. It's great that many of these platforms actually just all more or less work if you use several of them at once. So extensible! So hackable! And you can host the entirety of them locally, so your whole site can be built in a permanently unchanging way? Wonderful! But a…

When I bought a 3-D printer years ago, I had an important insight. I was either buying a printer as a project, or I was buying a printer to help with other projects. Both are reasonable answers. It makes people happy to work on their 3-D printers. They love tinkering with them, like printing new braces, holders, parts, etc. The love tuning them. They love finding the perfect filament storage system. That's the hobby.…

Yep, 100%, that's a great example. I have a friend who LOVES tinkering with his 3-D printer. He built a CoreXY from scratch to his own spec, he hacks about in the firmware, he experiments with new slicing algorithms, but to my knowledge he's never actually printed a 3D part for any purpose except calibration and for making 3D printers. The printer is the hobby. Its ability to make stuff is both entirely the point and also entirely unimportant.

But the idea of a 3D printer is totally different. It's for people who need to learn just enough about 3D printers in order to use them to do other things. The idealized owner of a printer does not care how printers work besides picking one that's suitable for a job. If you spend a lot of time thinking about the design of your printer, something's wrong. A framework should, for most regular work, be as much like a printer as possible.

Post reply on HN