Live data from Hacker News

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

blog.jim-nielsen.com

51–60 of 247 posts

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

#51
post #5

The problem isn't the tool or the dependency—it's the developer's temptation to over-engineer. We grab a framework because we lack the discipline to keep something simple. Is self-control in coding just a lost art now?

> Is self-control in coding just a lost art now? Yes; a lot of people don't code because they need to make something work, they code for the joy of it. When the software they need to write is boring or solved - like another CRUD app, front- or back-end - instead of picking the boring and easy to build and comprehend languages and frameworks, they will make it interesting for themselves. Learn a new language, framewor…

  > they will make it interesting for themselves.
Engineers love to solve problems. If there are no problems readily at hand, they will create some.

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

#52

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.

That sounds plausible in theory, but I've been developing big ol' LOB apps for more than 10 years now and it happens very very sporadically. I mean bloated joins is maybe the most common, but never near enough bloated to be an actual problem.

And schema changes and migrations? With ORMs those are a breeze, what are you're on about. It's like 80% of the reason why we want to use ORMs. A data type change or a typo would be immediately caught during compilation making refactoring super easy. It's like a free test of all queries in the entire system. I assume that we're talking about decent ORMs where schema is also managed in code and a statically typed language, otherwise what's the point.

We're on .NET 8+ and using EF Core.

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

#53
post #23

Earlier quoted context omitted.

My own code doesn't break without me working on it.

Neither do your dependencies. Unless the maintainer somehow hacks into your server and updates them for you?

People in web development tend to allow dependencies to auto-update. It’s kind of a necessary evil in that the alternative is to do it only manually and then falling behind on security vulnerabilities updates and potentially getting hacked.

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

#54
post #39

I don't see the value in posts like this. It's just a random list of things that can go wrong in software projects, with no discussion of trade-offs at all. Where's the engineering?

Engineering is broader than just trade-offs Broad heuristics can be very effective We make decisions on many more datapoints than can be put into what sometimes amounts to a “for and against” list

Obviously engineering is broader than just trade-offs. I agree that broad heuristics can be useful but the ones proposed in this article just seem bad. Dependencies are (again, obviously?) really useful in many contexts. Same with build steps and frameworks.

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

#55

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.

A couple of years ago I had an opportunity to fill a fullstack role for the first time in several years.

First thing I noticed was that I couldn't roll an SQL statement by hand even though I had a distinct memory of being able to do so in the past.

I went with an ORM and eventually regretted it because it caused insurmountable performance issues.

And that, to me, is the definition of a senior engineer: someone who realised that they've already forgotten some things and that their pool of knowledge is limited.

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

#56
Honestly, I don't agree with the mindset that frameworks and build steps should be avoided at all costs. Of course, you shouldn't pull in unnecessary NPM dependencies—that's just common sense. But using a compilation step or a framework can save you a lot of time and effort. For example, if you use a framework like Astro, you get a lot of functionality out of the box. If you try to do everything by hand, you end up copy-pasting the same header and footer into every HTML file. Then, when you want to update something, you have to manually change every single page. Trust me I been in that hell many years ago.

Frameworks solve these problems efficiently. Sure, some frameworks can be overly complex (I'm personally not a fan of Next.js), but that's a problem with the specific framework, not the idea of using a framework at all. But many frameworks make things much simpler and let you avoid reinventing the wheel. You could write your own scripts (in practice a mini-framework) but eventually you'll hit limitations, especially as your project grows or you start working with others. At that point, you'll probably end up switching to an established framework anyway.

If you're already using something like PHP with server-side rendering and templates, that's fine too—you've just chosen a different kind of framework (it is still some kind of framework. Just not a client-side one). I just don't buy into the idea that avoiding all build steps and frameworks is somehow more "pure." It feels a bit like a hipster take: "I'm going to write everything from scratch and avoid all tools just to show that I can."

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

#57

On one hand I agree, one should approach issues as they come, but there's solutions that are hard to ignore such as the need for reusable fragments/components on different pages which already make a cry for dependencies. Even admitting one wants to go with bare bone web components authoring and maintaining them is expensive, requires lit or something. Thus, what's the solution? Some sort of templating? Again, you're…

PHP is actually a pretty good HTML preprocessor language. Not sure why it was blasted from this planet. Maybe because people abused it as a "rest" endpoint or backend, and burned themselves out from using the wrong tool for the job (even as php evolved to be pretty good backend for this too) A small amount of PHP as a templater for simple raw HTML and JS segments is pretty nice.

Because debugging it is a nightmare. It's really awesome for what it's good at, but inline templating after a certain level of complexity is a recipe for madness. The problem is, projects start off small and un-complex, but by the time it gets too complicated, you're in too deep and porting it something else takes extra time.

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

#58

Earlier quoted context omitted.

Basically they’re saying implicitly to be principled about adopting frameworks and other dependencies, evaluating whether they’re needed for one’s project before adopting them. It’s a pretty thought provoking post, even if it may be too subtle for some folks.

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).

You don’t get to decide that, the people voting on HN do, they did and they disagree with you, just accept you can’t agree with a large set of people all the time.

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

#60
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.

So don't run npm updates because sure then you have the security risks that you have some old code and that is five years old and hasn't been worked on for five years and you also have you missing out on new functions and optimizations. However if you have a five-year-old project that you handwritten everything by yourself you probably have a lot of security issues there too assuming that you are using complicated functions like you would have in Next.js. So then you would have to update a lot more than you would need to bring an old Next.js project up to date. You would need to rewrite all your code from scratch almost.
Post reply on HN