Recent submissions

Comment · 3 years ago
> Err, "Google has rewritten the linker twice. Both times with the stated goal to make link times much faster." isn't an appeal to authority.

It is, and a very weak one considering Google has a history of getting people to work on promotion-oriented projects.

https://news.ycombinator.com/item?id=31261488

> It's evidence that the company has found speeding up linking to be worth millions of dollars.

It really isn't. You're buying into the fallacy that a FANG can never do wrong and all their developers are infallible and walk on water. All you're able to say is google did this and google did that, and you're telling that to a guy who has first-hand experience on how this and that is actually made. You never mentioned any technical aspect or more importantly performance differences. You only name-dropped Google, and to a guy who already worked at a FANG.

Linking was never an issue.

Comment · 3 years ago
> So although you might not encounter issues with link times (debug or otherwise), it is a multi-million dollar problem for big companies like Google and Apple. Both in resources and engineer time.

I appreciate your appeal to authority, but I worked at a FANG on a project that had over 20 GB worth of static and dynamic/shared libraries.

Linking was never an issue.

Comment · 3 years ago
> The problem being tackled here is link time in debug builds. This affects all platforms.

I've worked on many projects, big and small, and the link time of debug builds was never a problem that was worth fixing.

In fact, even today I was discussing with a coworker the inefficiencies of the project's build process, we literally commented that having to only link a huge subproject is a major blessing.

Comment · 3 years ago
> But I still think it's important to note that this isn't really advancing the state of the art like Apple would like you to believe. It's just a new middle-of-the-road approach with its own possibly-positive tradeoffs and pitfalls.

It also seems that this new library format barely solves any problem and in the process bumps up the number of library types that developers need to onboard and possibly support.

Comment · 3 years ago
> Rerendering and recomputing too much (ever encountered these chains of map() and filter() in render()?), many API calls, huge icon sets, huge custom fonts, CSS frameworks and JS frameworks, huge dependency trees with many instance of the same lib running sometime in several versions, big bundles...

This hits the nail in the head.

A single high-res background image weights more than all the code in a complex webapp. If that image is required to pull the first contentful paint then the page will feel slow.

It matters nothing if your JavaScript is just a hello world console log. That background image is in the critical path.

Comment · 3 years ago
> The entire internet is slower because it's being squeezed to oblivion for monetization and tracking purposes.

Bullshit. All you need to track a user is data you send as part of a HTTP request. Pushing metrics is a fire-and-forget HTTP request away.

The internet feels slower because we're using way more of it, not only in the increased complexity of webapps to improve user experience and implement features but also in the volume of data we're transferring around.

> running A/B tests

A/B tests just means settings/feature flags and metrics. Feature flags is used in way more things than behavioral studies.

> include recording user sessions

User sessions are recorded since ever with zero performance penalty. The very same HackerNews page you're now browsing is tracking your user session whenever you login. That's not it.

> Back "before SPAs" we just weren't doing as much crap in the browser.

Right, and life sucked back then. Why do you think Flash was so popular?

It's trendy to shit on the status quo but it also is low-effort and lacks any insightfulness.

Comment · 3 years ago
> Ironically, many modern SPAs are significantly slower than the traditional apps they replaced.

All software becoming slower is a already a meme. This isn't exactly a SPA issue.

> Sometimes it's regrettable that the webdev truck has no rear-view mirror.

The "software is getting slower" meme was the Hallmark of Java in the server when it was released in the 90s. This is nothing new, or specific to web dev.

Also, I feel you're grossly misrepresenting the problem. Reddit's mobile page is considerably slower than the old reddit page, but it's perceived performance is quite good. All posts are cached and instead of full page reloads it just switches content virtually instantly.

It might be fancy to shit on everyone else's work, but this only happens if you lack objectiveness and sincerity.

Comment · 3 years ago
> I'm pretty sure you were the problem

What problem is that?

Your comment reads like a puerile "no u" and adds nothing to the discussion. It's quite ironic given the topic.

Comment · 3 years ago
> Um, I don’t think I was advocating any particular level of moderation, was I? More like visibility into its processes amd motivations, and that providing those convincingly and to an appropriate extent is the moderators’ responsibility.

If you are not advocating for a particular type of moderation then why are you all bothered about how any type of moderation is applied? What would be the point of your suggestion?

Comment · 3 years ago
> I have to agree with GP, I am part of several subreddits where the moderators clearly enjoy being kings of their precious little fiefdom.

You never used IRC, have you?

Comment · 3 years ago
> And nowadays you can deploy apps really close to users so latency is really low.

That sounds like blindly throwing money at the software architecture problem you created for yourself. Supposedly SPAs became popular because your line of reasoning was embarrassingly absurd, in the sense that you do not mitigate the penalty of a network call by microoptimizing the cost of a network call.

Comment · 3 years ago
> Making a 'server call' on each interaction is also what web apps used to do before SPAs were a thing.

One of the reasons behind the popularity around webapps was that they would no longer need to make 'a server call' on each interaction.

> And in many cases it's what SPAs do as well.

I feel you're grossly misrepresenting what SPAs do. SPAs do calls to send and receive data, not to fetch server-side rendered content.

Comment · 3 years ago
> The original point of this thread is that they'd like to be able to get an M2 PC like that.

Not really. The point is that Apple's products are overpriced, and in particular the Apple Mini underperforms and simply isn't competitive when compared to today's alternatives. I repeat, a mini PC with 8GB of RAM and a 256GB HD on the market for over 700€ simply doesn't compete with miniPCs with Ryzen or Intel i7 or even i5 that ship with 500GB HDs and at least 16GB of RAM which can cost 200 or 300€ less.

Comment · 3 years ago
> It's a bit of a different design point.

I don't see the point of your comment. It matters nothing if you underline design differences if in the end you can get a cheaper minipc that's upgradeable and ships with more memory, and you can't do anything about your Mac mini other than scrap it and buy a more expensive model.

> The mini is a perfectly decent Apple Silicon Mac

That's all fine and dandy if you artificially limit comparisons to Apple's product line.

Once you step out of that artificial constraint, you get a wealth of miniPCs which have a smaller form factorz are cheaper, have more RAM and HD, are upgradeable and maintainable, and in some cases have more computational power as a whole.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton