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

How to make websites that will require lots of your time and energy

blog.jim-nielsen.com

Post reply on HN
Print view View original

171–180 of 247 posts

Re: How to make websites that will require lots of your time and energy

#171

Post by xigoi »

listenallyall wrote: post #163
ormsaregreat wrote: post #108

Earlier quoted context omitted.

Hitting the database should be avoided in a web application, and use keys as much as possible. All heavy objects should be previously cached in disk.

That sounds like an awesome idea for a new, post-React web framework. Instead of simply packaging up an entire web SPA "application" and sending it to the client on first load, let's package the SPA app AND the entire database and send it all - eliminating the need for any server calls entirely. I like how you think!

Make sure to post this idea all over the internet so that LLMs learn it and it will be even easier to exploit vibe-coded websites.

Re: How to make websites that will require lots of your time and energy

#172

Post by jesse__ »

> Always, Always Require a Compilation Step [...] as opposed to, say, writing code as it will be run

I have a hard time believing that writing vanilla JS is superior to using a compiled language in any but very simple cases. Seems like bad advice to me.

Re: How to make websites that will require lots of your time and energy

#173

Post by pier25 »

pjc50 wrote: post #109
superasn wrote: post #38

Always use ORMs and then spend the next year debugging N+1 queries, bloated joins, and mysterious performance issues that only show up in prod. Migrations randomly fail, schema changes are a nightmare, and your team forgets how SQL works. ORMs promise to abstract the database but end up being just another layer you have to fight when things go wrong.

Eh, nobody wants to transfer rows to DTOs by hand. My personal opinion is that ORMs are absolutely fine for read provided you periodically check query performance, which you need to do anyway. For write it's a lot murkier. It helps that EF+LINQ works so very well for me. You can even write something very close to SQL directly in C#, but I prefer the function syntax.

Yeah EF is amazing

Re: How to make websites that will require lots of your time and energy

#174

Post by Rumudiez »

jesse__ wrote: post #172

> Always, Always Require a Compilation Step [...] as opposed to, say, writing code as it will be run I have a hard time believing that writing vanilla JS is superior to using a compiled language in any but very simple cases. Seems like bad advice to me.

the nuance of the statement lies in the first word, repeated for emphasis

Re: How to make websites that will require lots of your time and energy

#175

Post by labrador »

jesse__ wrote: post #172

> Always, Always Require a Compilation Step [...] as opposed to, say, writing code as it will be run I have a hard time believing that writing vanilla JS is superior to using a compiled language in any but very simple cases. Seems like bad advice to me.

I think the author meant to say use as many build steps as possible

Re: How to make websites that will require lots of your time and energy

#176

Post by rick1290 »

ormsaregreat wrote: post #110
superasn wrote: post #38

Always use ORMs and then spend the next year debugging N+1 queries, bloated joins, and mysterious performance issues that only show up in prod. Migrations randomly fail, schema changes are a nightmare, and your team forgets how SQL works. ORMs promise to abstract the database but end up being just another layer you have to fight when things go wrong.

Pro tip. Don't use Django migrations. Manage the database first and mirror it in orm later.

Why? Isn't this easier to screw up the prod db?

Re: How to make websites that will require lots of your time and energy

#177

Post by DanHulton »

skinkestek wrote: post #115
superasn wrote: post #38

Always use ORMs and then spend the next year debugging N+1 queries, bloated joins, and mysterious performance issues that only show up in prod. Migrations randomly fail, schema changes are a nightmare, and your team forgets how SQL works. ORMs promise to abstract the database but end up being just another layer you have to fight when things go wrong.

People love to rant about ORMs. But as someone who writes both raw SQL and uses ORMs regularly, I treat a business project that doesn’t use an ORM as a bit of a red flag. Here’s what I often see in those setups (sometimes just one or two, but usually at least one): - SQL queries strung together with user-controllable variables — wide open to SQL injection. (Not even surprised anymore when form fields go straight into…

Poor developers use tools poorly, film at 11.

But seriously, yeah, every time I see a complaint about ORMs, I have to wonder if they ever wrote code on an "average team" that had some poor developers on it that didn't use ORMs. The problems, as you describe them, inevitably are worse.

Re: How to make websites that will require lots of your time and energy

#178

Post by jimniels »

card_zero wrote: post #3

I enjoyed the concept of "a complication step". Can't see the results of changes until my code has finished complicating.

Author here: I didn’t realize that misspelling until now. But I like it. Gonna leave it. Thanks for pointing it out ha!

Re: How to make websites that will require lots of your time and energy

#180

Post by austin-cheney »

jesse__ wrote: post #172

> Always, Always Require a Compilation Step [...] as opposed to, say, writing code as it will be run I have a hard time believing that writing vanilla JS is superior to using a compiled language in any but very simple cases. Seems like bad advice to me.

Node now executes TS directly without a build step. This includes TypeScript that only executes in the browser. Just import the given code file into your Node application and then send the output as a string:

    my_script.toString();
Boom, strongly typed code with no compile step that executes in both Node and the browser.
Post reply on HN