mind-blight

I know someone who works for a university in event planning. They were putting together an event for a civil rights icon. Because of the new policies, they were forced to go through all of the brochures and pamphlets and censor any use of words such as "racism" and "black" (when referring to the man's skin color).

They literally couldn't say "black man fighting against racism" about a civil rights icon without losing millions in funding. I have no idea how someone can argue that this kind of censorship targeting universities is acceptable

You're getting downvoted because you're retreating into philosophical nihilism rather than actually addressing the points. If you disagree with how people interpret the studies, the studies themselves, or how science measures reality - just say that.

I also love SMBC's explanation of this: https://smbc-wiki.com/index.php/2010-09-23

I'm just not quite sure why "speed" is what be js bundlers are selling themselves on. We have a number of fast bundlers already, so that's not what's taking my time. DevEx is the real selling point for me, and that didn't talk about any of their differentiators there

Onerous regulations and process are a huge part of the problem. I looked into building a small apartment complex with a local developer in the city. It was zoned well, but the entire surrounding neighborhood had dirt roads. After talking with the city planner we found out that:

1. We'd need to pay 5k get a price estimate for all of the permits we would need, and

2. That we would need to either pave a road along the property (which would immediately fall apart from erosion since it would be the only paved road for multiple blocks), or pay $400k for the right to not pave the road

At that point, we stopped even trying. There's no way to build affordable housing in a timeline manner in that city.

Yeah, it's definitely not a perfect solution. Portland, OR has tried a housing first policy. However, there weren't enough available houses, so that requires to build them. That's lead to years of people still being homeless and underserved while resources went into building homes.

I think it can help a lot under the right circumstances, but if the system is already overwhelmed then funding less permanent solutions for a while may actually be more effective and kind

(Replying to your latest comment.) I meant 'colluding to flag' by brigading - same as what the other commenter was interested in.

That you haven't seen much evidence of a change is actually really nice to hear and a bit surprising. Since HN has grown in popularity in recent years, I would have expected collusion to show up as a noticeable change in behavior. The motivation and potential reward for brigading seems like it would increase with HN's influence on the tech community.

Also, thanks for responding and providing your insights!

Thanks for explanations! I'm really curious if it looks like brigading has increased based on what your seeing in the data, or if this looks like roughly the same patterns you've seen historically.

I assumed that brigading had increased. This is mostly due to seeing things go from unflagged to flagged in the amount of time it took me to read the article. I've been a many-times-a-day reader for about 12 years now, and I hadn't really encountered that until recently. But, after reading about MOTs, those seem like a playable reason too

Fair - maybe there was a little name calling. But, I agree it was deserved.

I thoroughly enjoyed the post and thought your tone was appropriate, entertaining, and kind of kethartic. You didn't call them names, engage in ad hominem, or do anything click-batey. You were understandably irritated at how they talked to you and how they were clearly trying to hide a massive exposure from their users. And then you shredded them with data.

A+ - And thanks for trying to keep folks like this honest!

That's not true. Many government positions and rules require different levels/types of clearance. E.g. the DoD and DHS have entirely different clearances managed by different organizations.

The DoD funds so much scientific research. There are entire budgets that are classified to hide how much we spend on - say - split satellites. Having access to the books of all of these orgs likely would require tons of different background checks and clearances from different organizations under normal circumstances

That feels more like bashing Redux or one of the state management libraries. That's where I've seen a lot of complexity sneak in.

You should check out Radix UI (https://www.radix-ui.com/). Same idea as headless ui, but it doesn't assume that you will use Tailwind. I _think_ they add css classes to all of their components to allow you to choose any styling method you want, but I'm usually working with ShadCN (which is one level up and uses tailwind).

Though, I'll say that I agree with OP that a lot of functionality already exists within HTML and browsers.

> When you embrace CSS as your primary architecture, you're not just writing styles - you're building a design system.

And

> Nue is of course not for everyone. It's specifically designed for developers who see CSS as a creative medium - who get excited about the possibilities of container queries, custom properties, and calc() functions. For these developers, CSS isn't just a styling language - it's a powerful system for expressing design.

Are both super interesting and make sense with a number of changes I've seen in the ecosystem. I respect CSS-focused developers (I'm not one, but I like to dabble) and appreciate a ton of innovation that's coming out of the designer-developers who try to push the boundaries of both the roles and the technology.

The disconnect that remains for me is that client/server state management and scope creep are the two main drivers of sprawling code bases in my experience. Having a bunch of 1-off styles in a component definitely made design updates a nightmare, but tailwind and/or just using CSS variables helped improve that. Using service-oriented architecture (including on the frontend to keep complex business logic out of components), GraphQL + fragments + urql/apollo, and/or Remix (or a similar framework) were all really big steps forward in trying to solve the thorny state management problem. They all come with their own tradeoffs, but that's where most of the complexity and sprawl comes from in my experience.

There's definite bloat from people re-inventing the wheel (forms are the most common one I encounter), but the explanation pages feel like Nue is a panacea. I only see how it improves specific areas rather than the whole architecture. I'll say, I really like how HTMX approached their education around this. Similarly, they're a "use the standards!" kind of library, but they have clear examples of what is solved, and what isn't solved. And their "isn't" includes cases where the current approach is better suited. That makes the scope a lot clearer, which I still feel like I'm missing from the Nue project

ETA:

It's also possible that I'm just not the target audience. Most of the projects I've built or lead have been either extremely event heavy (E.g. using Bluetooth sensors attached to limbs + timers to guide people step-by-step through exercises) or extremely data heavy (e.g. analytics and information collection based on dynamic ontologies). The data model and state management were always multiple orders of magnitude more complex than almost anything else.

I appreciate the links. I think this quote from the FAQ captures the disconnect for me:

``` This isn't about rejecting modern development - it's about recognizing that browsers now offer sophisticated capabilities that eliminate the need for most framework abstractions. ```

The problem I have is that I agree with the initial premise, but I disagree with the conclusion. Framework architectures mostly solve different problems than modern web standards.

If you want to go after specifics like 1) just use browser forms and stop re implementing the wheel, 2) you probably don't need a massive state validation library, or 3) stop building CSS features in JS, then I'm 100% on board. But that's not a problem with CSS-in-JS, JSX + render library, components, or many of the other targets you go after.

Things like tailwind (for example) solve fundamentally different problems, and those have more to do with team standardization, avoiding bike shedding, and rapid prototyping. For styling in particular, I don't want to return to the days of crawling through thousands of lines of CSS - edited over years by multiple teams - to find all of the places where different styles impact the specific html component I'm looking at. That's tightly coupled code with loosely defined locations. JSX components just decay less quickly due to encapsulation.

I've also just never seen the separation of CSS and HTML actually provide practical value. It's always been "check out what's possible!" projects like CSS zen garden. Super cool, but that decoupling just doesn't do much in practice.

Like I said, I think there are some interesting ideas here, but I just don't think it's clear why this is a better approach for general web application development (which is the argument you appear to be making).

I'm super curious to see if you prove me wrong, so I'll definitely keep an eye out :). I just don't yet see how the proposed solution solves the identified problems without pulling in a bunch of pain points that were already solved a while ago.

I've also been developing web apps since the days of jQuery and Flash. I think there are some interesting kernels here (in particular, emphasizing how much browsers have evolved), but the post brings up older architectures as better (MVC, separating CSS from HTML) without providing arguments for why those were better at addressing current pain points.

Personally, I hated MVC in frontend code. It works ok for backend apps (though I prefer service-oriented architectures more), but it tended to creating arbitrary separations that provided little value on the frontend.

Similarly, I think the separation of CSS and HTML was an illusion 90% of the time. The CSS is always coupled with the html, and having it spread across multiple files just made design updates more error prone. That provided all of the problems with separation of concerns with none of the benefits. You want to be able to update things like fonts, colors, spacing, etc site-wide in either 1) components (which works great with coupling html & css inside of component files) or 2) logical areas (which works great with css themes and variables). Neither of those are due to the separation of HTML and CSS.

I think there are a couple of interesting ideas here, but I'd need to see clearer arguments about why these patterns were actually better on the frontend (and when they fail) to be convinced in this direction.

Yeah, I was expecting something bigger and more explicit when he went after tailwind. Instead, the author just re-hashed older design patterns (MVC and semantic html decorations from css) without providing context add to when and why you would prefer the older patterns over newer ones. I've been building since the jQuery days, and I totally agree that there are a lot of challenges that people tend to forget from that time. Decoupling html from css just didn't provide much value, but it did create a lot of bike shedding.

I really like how htmx has handled explaining their architectural trade offs. They're very clear about the kind of problem they're solving, how they're solving it, and when/why their solution is better.

This post just has "get off my lawn" vibes without a ton of substance

A deterministic uuid based off of a hash of bits is also very useful (UUID5). I've used that for deduping records from multiple sources

Super cool idea! What are you doing to ensure consistent results based on the input? E.g.

- does the AI perform the same trades given the same input?

- does the AI perform the same trades given slightly different inputs? (E.g. same data, but re-ordered)

I reread the books multiple times. I was actually pretty impressed with how well they cast each character. Which is impressive because I think that's one of the hardest things to do.

But, the dialogue and storytelling were terrible. They invented new, pointless content. There's ~18k pages of source material. Amazon's job was to figure out how the hell to pair that down without compromising the original story. Instead, they went for visuals over storytelling

If you don't mind me asking, do you have any cues or techniques that you use to help differentiate between a delusion and something real? Or are the kind of delusions you have consistent to the point where you've already categorized and figured out how to deal with them?

Cosmic Crisp is a new varietal that seems like a solid successor to honey crisp. It seems like they started in a cooler climate (I first encountered them in northern Oregon), and they're fantastic.

I've honestly been pretty happy with it. It gives developers the ability to push back on shirt practices with "do you want to lose access to the European market?" Having that in the tool belt is very handy

That doesn't seem like it applies here. The argument is that "expert consensus has consistently said a thing", which is a very reasonable stance to take.

The default would be to assume the scientific consensus is correct, then being evidence/reasons to show when it's not.

This is super cool! Do you have any integrations with duckdb? It seems like these two could work really well together

Are you folks planning on more first class postgres support? From the outside, it really seems like forcing MongoDB into the orm has forced a pretty watered down experience for the main orm (I.e. not typed SQL).

I don't know if it's true, but it seems like you're be able to address the backlog more easily of you didn't have to force abstractions that work for a no SQL db

Honestly, I hated Prisma for a while. I've tried to actively rip it out of multiple projects. But, typed queries + views being supported have rally started to change my mind. Prisma is great for basic CRUD operations, and those two features give me a really solid, type safe escape hatch for most of my complaints.

Dropping the rust client will solve another big complaint. I definitely feel the issues languishing problem. I've submitted a few confirmed reproducible bugs that have hung out for a couple years. Still, I'm happier with their recent direction than I would have expected.

That's great news. The rust client has eaten a few days of my and my co-workers' life by causing deployment issues

I use o1 for research rather than coding. If I have a complex question that requires combining multiple ideas or references and checking the result, it's usually pretty good at that.

Sometimes that results in code, but it's the research and cross referencing that's actually useful with it

This is super cool! One suggestion for the blog: I would put "re-imagines vector embeddings as database indexes. It's not literally an index but it functions like one to update embeddings as source data gets added, deleted or changed." as a tl/dr at the top.

It wasn't clear to me why this was significantly different than using pg_vector until I read that. That makes the rest of the post (e.g. why this you need the custom methods in a `SELECT`) make a lot more sense in context