1GZ0

It was the goose all along.

Yeah, no thanks..

I'll just stick with a $5 vps with lamp and jjquery

I hate the fact that modern webdev has become to unnecessarily complex that developers unironically turn to LLMs instead of realising that it doesn't have to be like this.

Yes, and they've been at it for a while. its honestly hard to watch.

Darkreader plus 150-200% zoom and you have something pretty usable on hidpi displays. You could always try making your own frontend for HN, it's pretty trivial :)

Writing for AI honestly doesn't seem much different to writing for pagerank algorithms which SEO specialists have been doing for years. The only change is that almost all the SEO content on the web is now being written by AI, for AI to later summarise.

Somewhere in Denmark, DHH is smiling

So they're going after mukbang YouTubers now?

Its not clickbait though.

You should try reading the article before passing judgement.

Its not like the article is called "5 facts that will make you hate package managers. Number 5 will shock you"

Liability: "Something for which one is liable; an obligation, responsibility, or debt."

Third party dependencies absolutely are liabilities. You are liable to vet them, inspect their licenses and keep them updated while ensuring that they continue working with your existing code.

This is not something package managers help you do. Package managers like NPM make it trivial to skip these steps entirely.

What is being argued for, is a more thoughtful approach to handling third party dependencies. Or at the very least, the need for people to realise that there are costs associated with bringing third party dependencies into your codebase.

Its not splitting hairs at all. Its more of an presumption on the part of a large number of readers, that the 2 points argued conflate to "Package manager suck, because third party dependencies suck and you should write everything from scratch instead".

It's completely fair game to react to the provocation rather than the substance of the article itself.

Yeah, but its down right stupid to do so.

The title isn't even misleading or part of a Motte-and-bailey argument.

People just hear "Package Managers are Evil" and assume that the author means you shouldn't use third party dependencies. Which is NOT what's being argued.

But I guess you'd know that, if you read passed the title.

The Author isn't arguing for not using third party dependencies. He's arguing for developers to be more conscious of the dependencies they use, by manually vetting and handling them. That screams "I've been down the package manager route and paid the price". Not inexperience.

"let's kill it off" proceeds to offer no solutions.

Why would anyone care who Paul Graham hangs out with?

But why stop there? based on your arguments 10-bit bytes would be even more better.

I love how quick people are to dismiss the obvious technical skill involved in making something like this, just because of the off-color premise.

This really strikes cord with me. I chose early on in my carrier not to use frontend frameworks, precisely because of the added abstraction and inherent complexity they tend to bring to your codebase. Its been tough and limited my prospects significantly as a junior dev. But these days, I'm happy that I chose to steer clear of frameworks. As it really does give you a much more broad understanding of how the web platform works.

Tl;Dr for the juniors out there, learn React if you want a job. Learn javascript if you want a good job.

You wouldn't show up drunk to a job interview just because its at brewery, would you?

Try this: https://archive.md/20250129074531/https://www.reuters.com/te...

Isn't that what being "Open" should be all about?

I feel like "Complexity" is the wrong word here.

Although I agree with the notion that deep knowledge of complex systems has decreased over the years, I'd argue that the problem isn't the lack of interest in gaining deeper knowledge that's the problem, nor a perceived lack of respect for expertise.

I'd argue its more to do with the nature of how large codebases morph over time as they're retrofitted to do more usercases. Its a lot easy in the short term to just hack in the functionality you need into an existing codebase, instead of rewriting the entire thing from scratch every time. This comes at the cost of maintainability and leads to a lot of headaches in the long term, as systems that where never designed to work together clash in unexpected ways.

I don't begrudge anyone for not wanted to dive into codebases like that.

Just like code bounties might sound like a good idea on paper, rewarding ethical hackers with huge amounts of cash would undoubtably result in rapidly diminishing returns.

While they absolutely could / should have rewarded him with more than a lousy t-shirt. I suspect they aren't keen to encourage a bunch of random people to try and poke holes in their security with the expectation of a cash price.

Why ignore mobile?

Context matters. In the context of the wider web, I don't think Firefox matters anymore.

2.65% global marketshare on statcounter would suggest Firefox doesn't matter. Its a shame really. But unless something drastic happens, to bring Firefox back into relevancy, I don't see its trend towards obscurity changing.

Well dad, turns out you were right..

I wonder how much of that code is boilerplate vs. actual functionality.

Its a bit early to start using this in products (see: https://caniuse.com/?search=css-scroll-timeline)

But once its baseline I'll absolutely use it, anything to ship less javascript.

It made it way worse, just by convincing people that making everything in react would make recruiting easier.

I wrote my first jQuery lite selector clone a bit ago, any feedback would be appreciated, especially since I don't see the need to separate out querySelector & querySelectorAll

``` const $ = (param) => { if (typeof param === "string" || param instanceof String) { const elm = document.querySelectorAll(param); return elm.length > 1 ? elm : document.querySelector(param); } else { return [param].length === 1 ? [param][0] : [param]; } }; ```