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

281–288 of 288 posts

Re: Doing Rails Wrong

#281

Post by darkwater »

madebylaw wrote: post #276
darkwater wrote: post #83

Earlier quoted context omitted.

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!

Totally, around that time I did that too (although I was working with LAMP stacks so no Capistrano), but with the rise of AWS, Capistrano got outdated. I know that not everyone jumped board on cloud that early, and even the ones that did, there was an adaptation period where EC2 machines were treated just like colo machines. But Ruby also used to be the hipster thing before 2010 so... :)

Anyway, never liked Capistrano so I'm probably biased

Re: Doing Rails Wrong

#282

Post by conradfr »

em-bee wrote: post #273
conradfr wrote: post #235

Earlier quoted context omitted.

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.

I was speaking from a developer / technical perspective obviously.

Re: Doing Rails Wrong

#283

Post by mega-tux »

ksajadi wrote: post #105

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 really don't like Hotwire and FE history (I'm playing with htmx, Datastar, Phlex and love it) but the ActiveSupport autoloader -> to Zeitwerk migration was pretty much something in the background, an implementation detail, at least in my experience. Most devs don't even know what is all this about.

Re: Doing Rails Wrong

#284

Post by mega-tux »

0xblinq wrote: post #170
matpin wrote: post #10

Earlier quoted context omitted.

The question I think we should be asking: Why? Why are we replacing everything with React and a bunch of other libs on top of it? The front-end dev space feels like a cacophony of people all blurting out the same over-engineered stack. If your app is a few lists, a chart, and a form... Does it _reaaallly_ need React? 37signals is afterall running multiple successful products with Rails, and one of them is an email cl…

> The front-end dev space feels like a cacophony of people all blurting out the same over-engineered stack. If your app is a few lists, a chart, and a form... Does it _reaaallly_ need React? If your app is that simple you don't even need Rails. In my experience, everything starts that simple. But then time passes, team members rotate, and... your PM keeps asking to add more and more features... And that's when the "s…

Fully agree on templates but I use Phlex to build UIs with pure Ruby on the server side. A pleasure to work with. And with something like Datastar, reactive UIs with practically no js.

Re: Doing Rails Wrong

#285

Post by digianarchist »

madebylaw wrote: post #277
digianarchist wrote: post #144

Earlier quoted context omitted.

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?

Anything that requires state syncing between client and server.

Re: Doing Rails Wrong

#286

Post by array_key_first »

em-bee wrote: post #272
array_key_first wrote: post #262

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…

I keep as much state as I can in the database, yes. For example - foreign keys. I use constraints in the database to enforce application logic.

I could do this in the backend, yes. But that's needless complexity and it will blow up. Eventually, I'll write something to the database that's inconsistent and then I have to fix it. Because bugs happen.

Re: Doing Rails Wrong

#287

Post by em-bee »

array_key_first wrote: post #286
em-bee wrote: post #272

Earlier quoted context omitted.

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…

I keep as much state as I can in the database, yes. For example - foreign keys. I use constraints in the database to enforce application logic. I could do this in the backend, yes. But that's needless complexity and it will blow up. Eventually, I'll write something to the database that's inconsistent and then I have to fix it. Because bugs happen.

hmm, i don't want to come across as argumentative, it is more curiosity, because i simply never wrote apps that way. i just don't see how application logic could affect the data itself. the data is independent, and of course there are constraints for data consistency, but it is completely separated from the application logic. application logic doesn't make it into the database at all, or if it does then at best i might store some application specific states in a separate area in the database. effectively a different database than the one that has actual data. i can't think of an example where that separation would not be possible.

Re: Doing Rails Wrong

#288

Post by lambdaone »

spoiler wrote: post #269
lambdaone wrote: post #267

Earlier quoted context omitted.

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, whet…

Exactly. You don't need to really know how to program to use web frameworks, and web programmers are much cheaper than systems engineers. It's a no-brainer in short-term business terms. But there's a always a price to be paid for decisions like this, and this overhead is it.

Experience of similar tradeoffs tells us it will only get worse over time, and LLM-generated web programming will make the whole process get even worse even faster.

Post reply on HN