lolinder

> even though TS has its own share of problems with its 'kitchen sink type system'

Eh, people critique the kitchen sink type system but at the end of the day that system is why TypeScript took over, not a weird add-on you have to put up with to get it. It's what makes it possible to assign comprehensive types to ~every JS library, which is what allows TypeScript to gradually eat the whole JS ecosystem.

Any other approach stops short of the goal of being JS+Types, which means you end up with a different language with different semantics, which is where Dart failed.

If you assign a value judgement to that statement that's on you, not me. I was just providing the missing context: why OP didn't need a frontend framework to meet their requirements.

You and a few others are missing the point, which means I probably failed to communicate super effectively. Counterexamples aren't really a thing here because my point isn't that you do or don't need a framework for any specific kind of project, my point is that requirements vary and you can't talk framework vs frameworkless without talking requirements.

A blog is just one example of a place where frameworks don't help, chosen because the site OP shared is functionally the same as a blog. Other applications have different requirements and those requirements may also not benefit from a framework. Alternatively, the requirements themselves may actually have benefited from a framework and the authors chose to avoid them because the team preferred not to or because they felt strongly about avoiding frameworks because of personal preference.

In this case, this project has really one active contributor [0], so it's missing one of the key ingredients that in my experience really call for a framework: coordination between a large number of people.

(And lest I be mistaken: just because a project has a large number of people does not mean a framework would for sure be the best choice. I'm sure there are counterexamples to that too! It's just a hint in that direction, not an ironclad law.)

[0] https://github.com/mickael-kerjean/filestash/graphs/contribu...

Right, I agree with all of this. My point was always that requirements vary and it's pointless to talk about frameworks-vs-no-frameworks unless you're clear up front what your requirements are.

In this particular site's case, the requirements are met by WordPress, so "a WordPress blog" is a simple description of what it is. It wasn't meant to include a value judgement.

I could, but it would be a distraction because my entire point is that there are an enormous variety of apps with a large variety of requirements being deployed on the web. If I give examples that's going to turn into an argument over whether these specific examples actually need a framework, which will turn into a whole bunch of other hypotheticals of situations that would justify it or situations that won't.

Rather than opening up that can of worms I'm going to leave it where I left it.

You missed the "teams of 30+" part. I believe that a single individual who's dedicated to it can absolutely build a lot of cool stuff without frameworks, but there's a reason why large teams working on complex software tend to settle on them.

The only real viable alternative with a large team is a hand rolled framework, which isn't always worth the trade-off.

This is spot on. Load times do not matter for the kinds of apps that:

* Are exclusively loaded on high speed internet in corporate networks.

* Have a high hours-of-work-per-page-load count.

* Update infrequently.

We're engineers, or at least we like to call ourselves that. Engineering is the process of gathering requirements and building a system that meets those requirements on time and under budget. If your requirements include being able to serve users on 3G networks or users who only load your site in order to read a single piece of content per day, yeah, optimize your load times. But don't attack other engineers for failing to live up to your app's requirements.

Ah, you're right, I forgot a category: The people who will shamelessly dismiss other people's work and assert that they could do it better no matter how much context you share. This group is particularly fond of leaving dismissive comments without any substance.

Dogma is a hell of a drug.

It's not an attempt to belittle it at all, but as far as I know a news site and a blog have the same feature requirements—the main difference that I'm aware of is that a news site has more traffic and more articles and so may need better caching.

If you're aware of requirements that a news site has that a blog doesn't (and I assume you would be, as the OP and creator of the above site), I'd love to hear it.

Agreed that it's a trade-off. In your case I probably would have made the same call. Again, though: that's why use cases matter. Web app/blog is only one dichotomy—the most common two types of web dev but far from the only.

And if you can point me to an example of that I will happily lampoon them.

If we're talking about Medium, then yes, Medium is a complete disaster zone that should not be emulated anywhere. Their reader-facing use case does not require JavaScript at all except as a light optional seasoning on top.

All I'm saying is that we need to actually talk about use cases whenever we're talking about frameworks, which we almost never do. Failing to specify the use cases turns the conversation incoherent because we end up having two different conversations without even realizing it.

I think that this comment is a great example of the total disconnect these conversations always have.

On the one hand we have lots of people on here who are building full-featured web apps, not websites, on teams of 30+. These people look at frameworkless options and immediately have a dozen different questions about how your frameworkless design handles a dozen different features that their use case absolutely requires, and the answer is that it doesn't handle those features because it doesn't require them because it's a blog.

Meanwhile there are also a lot of people on here who have never worked on a large-scale web app and wonder why frameworks even exist when it's so obviously easy to build a blog without them.

It would be nice if we could just agree that the web hosts an enormous spectrum of different kinds of software and make it clear what kind of software we're talking about when we were opining about frameworks—whether for or against.

In this case: this is a WordPress blog.

Definition 4a in Webster is "paramour", which is "an illicit or secret lover". It isn't the primary definition for sure, but in this context that's the vibe it gives off.

https://www.merriam-webster.com/dictionary/lover

Yeah, so I get why it was attempted. It's likely they didn't realize that "lover" carries with it a sense of a clandestine or illicit relationship, especially in the kind of saucy story this already is by default.

Technically they never married, which is why the original article uses a bunch of other phrases to describe their relationship, but agreed that the change from "partner" to "lover" makes the title needlessly provocative. "Partner" was fine.

It was modified in the HN submission to replace "partner" with "lover", probably as an ill-conceived attempt to distinguish from him being just her business partner.

It's a great example of why not to change titles, though, because "lover" carries wildly different implications than "partner" and makes the title seem much more salacious.

If we're going to go with the seatbelt comparison then we'd have to flesh it out a bit:

Your new car sounds an alarm non-stop if any seat belt in the car is unfastened, whether or not a seat is occupied and whether or not the car is even on. This seems kind of silly, so you raise it with the manufacturer and they say that standard procedure is to just leave all seat belts fastened all the time.

You start doing that and quickly realize that it's much harder to remember to put your seat belt on than it was in your old car, because the car doesn't warn you when you've forgotten your seat belt and when you do remember on your own you have to sit up awkwardly to unfasten it before you can get under it and fasten it around you. You point this out to some fans of the manufacturer and they act like you're the weird one for not seeing how this makes you safer.

I don't think any of the negativity is about whether MCP works. It's just about whether MCP is a horribly ill-planned design that could have been much better if they'd taken the time to learn from the 50 years of experience we have as an industry in building protocols.

That it works is in some ways worse because it means we'll be stuck with it. If it didn't work we'd be more likely to be able to throw it away and start over.

Exactly.

"Response times will be higher" sounds very confusing as a way of saying we'll take less time to respond, right? So why should "response times will be lower" mean we'll take more time if the opposite construct is confusing?

Far better to just use the comparative forms that we already have for time specifically to make it perfectly clear.

Yes, this is a good explanation for the phenomenon! Thanks.

Sounds like you're the kind of person who will insist to Spanish speakers that a double negative is logically incoherent. Good luck with that approach to language!

No real human being would misunderstand because, as you note, time can't go slower. This is just an excuse for pedantry.

This case is about their search monopoly. There is another case pending about their ad monopoly.

And also: breaking everything else off of the ad company is the obvious answer to the ad monopoly. Every other part of Google exists to feed its advertising monopoly and maintain its edge there.

DeepSeek is a perfectly knowledgeable English speaker in China.

So those portions of the business will stand up fine on their own. The consumer-facing side is anticompetitive, though.

I'm not sure where you got that I'm trying to impose anything on anyone—sounds like you latched onto a side note and decided to reply to what you thought the side note was implying instead of the substance of my comment?

The argument has nothing to do with values or imposing them on others, it's simply this: These things are not and never were free. Google wants you to think they're free, but either the ads are effective at driving revenue and consumers are paying for Google's products in the form of increased consumption or Google is a parasite that lies to businesses about the efficacy of their ads and consumers are paying for Google's products in the form of the parasitic Google tax. Most likely it's a bit of both.

Either way, Google offering these products for "free" did not have a positive effect on consumer wallets and paid solutions emerging to replace Google if it actually does dissolve will not have a negative effect.

Maps/mail/drive/docs/flights/translate: provided for free using their dominance in ad tech to bankroll it and feeding the data back in to the ad platform. No one else can compete, and using dominance in one market to ensure dominance in others has historically been a clear trigger for antitrust.

Android: they lost a court case over this one that has lots of details if you care to look.

The rest are a weird mix of paid services that should be fine to stand up on their own or not even products at all (OAuth).

I didn't use that word and no one in the chain above me did either. I specifically chose "anticompetitive behavior" to emphasize that a monopoly is not required to do damage to the free market or to trigger antitrust action.

The consumer did pay the price. Google built on empire on making consumers believe they were getting things for free while selling other businesses a direct line to its customers' wallets. It's been a very effective sleight of hand operation, to the point where even relatively savvy people on HN seem to forget that advertising pays the bills by getting its targets to spend money they would not have otherwise spent.

A world without Google would not be a world with less disposable income for regular people, but it might be a world with less disposable junk.

Even if you discount the effectiveness of ads (which seems foolish given how many people have so much staked on them working), the eye-watering prices Google charges for them get directly passed to the consumer in the form of higher prices.

Monopolies are rarely if ever good for consumers, but some monopolies are better than others at offloading the responsibility for their harm onto other businesses.

It's about time that people get used to the idea that you have to pay for some of these things.

In aggregate it won't even hurt to transition to that: consumers are, in aggregate, already paying for these things in the form of increased spending on unrelated products they were sold by the ads and increased prices on goods (because their suppliers pay Google monopolistic prices for ads).