Live data from Hacker News

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

blog.jim-nielsen.com

101–110 of 247 posts

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

#101
post #11

Im pretty sure that most packages and frameworks break less than your own code…

I think the issue is API breakage. Does your 5 year old NextJS project still work after npm update? Probably not! What about your simple Go server or FastAPI server. Probably yes.

Any decent sized project will encounter breaking changes in dependencies.

The big frontend frameworks have great backward compatibility and usually provide codemods that automatically update your project.

If you install UI components and other libraries that might get abandoned or have breaking changes in major version updates you might have to put in more effort, that's not different in Go or Python.

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

#102
post #20

I host my blog using plain HTML and I have a compile step - a Python script that converts markdown to HTML, which minimizes the energy I spend on... wrapping everything in HTML tags?

> I host my blog using plain HTML and I have a compile step - a Python script that converts markdown to HTML, which minimizes the energy I spend on... wrapping everything in HTML tags?

Same, except I skipped Python and went with bash (https://gist.github.com/lelanthran/2634fc2508c93a437ba5ca511... if you're curious).

If I had to do it again, I'd go with Python, but because it started off as a small 5 line shell script I thought "Why bother with Python?".

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

#106

Earlier quoted context omitted.

No need for the random snark? I mean, again, we're in extremely obvious territory here. Just doesn't seem appropriate for hacker news front-page (to me).

What makes their random snark any better than your original comment though? There was no need for you to come in and say that you don't see any value here. If you don't see any value here, just move on to the next post.

I mean, I'm curious why this is such a highly upvoted article, which is why I'm engaging with this comment thread. I think criticism of the article is fine (although I acknowledge I could have been less blunt). It's the unnecessary criticism of my character that I object to.

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

#108

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.

I always see this sentiment here but I just havent experienced any of it in 14 years with the Django ORM.

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.

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

#109

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.

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

#110

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.
Post reply on HN