God created men; Sam Altman made them equal (taylor.town)
1 points by surprisetalk 9m ago 1 comments
Show HN: Omnara – Run Claude Code from Anywhere (github.com)
7 points by kmansm27 18m ago 0 comments
We keep reinventing CSS, but styling was never the problem
42 speckx 90 8/12/2025, 1:39:42 PM denodell.com ↗
Most GUI suffers from the NIH sydrome. Instead of using system components (and systems values and colors), every designer are pushing for adhoc widgets with fixed values.
Someone’s never used Windows before Vista. Remember how themeable XP was across all apps?
We had standard OS controls, that’s why all that worked. The web has… extreme customization per website.
Are we actually, in fact, if we're being honest?
I haven't seen anything like that. 99.9% of applications I interact with are just a series of simple CRUD operations. Sometimes they add unnecessary complexity and flashiness and of course there are some games and such, but when it comes to actual business apps they all just boil down to updating text records in a database at a human pace.
I am genuinely interested to hear examples of these "highly interactive" web apps others are building I keep hearing about but never seeing.
The vast majority of web apps out there could be implemented as REST systems (in the real, Fielding, HATEOAS sense, not the JSON-over-HTTP sense).
There are a few out there which need to be web apps, but those are relatively rare.
The point is you need the logic on the server since you can't trust the client, but you can make the client "dumb" with just super generic ability to show data and submit forms, and then you don't need to write your application logic a second time in the client. The server sends it instructions for the generic renderer to perform.
Practically every one of these uses components, internal state, and design systems to make the site highly interactive, just about every "web app" falls into this category.
Fill out an email form, hit submit. Fill out my tax form, hit submit. Fill out a ticket form, hit submit. It's prettied up CRUD, but it's CRUD.
There's no high levels of interactivity, nor any sort of need for client side state in any of them.
Like go over 20 jira tickets to update the names or adjust different properties on different ticket.
Now read again "different properties on different issues".
Like you are not going to bulk edit task requirements or set title for 20 tasks to the same thing.
Better examples would be things like Google Maps, Lucidchart, Google Docs, Photoshop, Zoom, any 3D rendering. These applications can only work with components and internal state.
99% of web "apps" don't need the complexity.
Obviously, yes.
> I haven't seen anything like that. 99.9% of applications I interact with are just simple CRUD apps.
Irrelevant. Being CRUD is completely orthogonal to whether the WebApps are interactive or not.
Look at Gmail. You can hand wave over it and claim it's a CRUD app. However, no one in their right mind would try to deny the app is a "highly interactive, component-based, state-driven, design-system-heavy applications".
Also, it's silly to pretend that SPA-type apps are only justified if you check each box in the buzzword bingo card. One of the primary selling points of designing SPA or non-static lage, SPA-like WebApps is performance. Meaning, you are able to put together a highly performant web page if you do not require full page reloads each time anyone clicks on something, if you can easily implement optimistic logic in components, and if you can update only a subset of components when you receive a response from a request.
I recommend discovering the concept of perceived performance and afterwards you read through common patterns and strategies to optimize perceived performance. After you do that, go through a though experiment where you start off with an old timey dynamic HTML/server-side rendered WebApp and consider the challenge of achieving the same type of improvements in user experience, or even doing the same tricks. You'll quickly arrive at the same conclusions at the whole world around you already arrived at.
It's literally basic web 2.0 junk from the early 2000s, the UI has barely changed since it launched.
It's possible to make a web 1.0 HTML email client but GMail is much much better. It's the difference between 1998 MapQuest and Google Maps.
That's perfectly fine. If you can't see it, you can't see it. You need to know what to look for to see it, though. If you're oblivious to web development then every page is just a page.
> You receive like an email a minute?
Irrelevant. The range of operations that Gmail supports and falls within the lazy classification of CRUD operations goed way beyond sending and receiving emails. For example, see gmail's support for tagging, email classification, multiple types of inboxes, etc.
> It's literally basic web 2.0 junk from the early 2000s (...)
Tell me you're completely clueless about web development and WebApps in general without actually saying it. Just keep in mind that you also have the option of not commenting on things you're oblivious about.
Of course, there are webs which are developed with the worst practices and bloated to oblivion. But even the best websites with the greatest UI/UX and perceived performance will have at least some complexity to it to give that experience to the end user. UX and simplicity done right is really a craft that mixes creativity, human psychology and technical skill.
Petty sniping is not welcome.
It's not that complex or fancy compared to what can be found in b2c, but it's not just a crud where users are directly tasked to update values in fields either. And yes, it could have been a crud, but I believe our users would have been worse off.
There are plenty of JS frameworks and some have a more ergonomic dev experience than others, but what is an undeniable fact is that most users prefer SPAs for highly interactive apps. There is a ton of research into user retention that proves this. Google aren't building SPAs because they like Angular.
It’s a Dropbox-like file manager that instead of owning your data integrates with your existing storage, authentication, and authorization systems. Under the hood, there’s a lot going on, very recently I added plugins to handle various kind of file types that are not typically handled by browser, we're talking > 100 kind of file types handled entirely in the browser for niches like astronomy, data engineering, GIS, 3D models, dev and even embroidery patterns
The painful reality is that this is true, but only at work.
There is so much that you use written in web technologies that are no CRUD. Some of that is Electron apps like VS Code and some of it is applications packaged in docker containers. Almost all of this non-work and non-CRUD stuff is open source. If you aren't writing code outside of work, where its only CRUD, your perspective of the universe is about 2mm wide. That is where the Dunning-Kruger starts to set in and why all this shit gets reinvented every couple of years. Its easy to think that: 1) you are awesome and 2) the world is painful when your perspective of the universe is only 2mm wide.
For everybody else, these things that most developers complain about really aren't painful enough to warrant any call to action because there are other things that bring substantially greater pain.
Vue and others have had scoped styles for a long time. Now @scope is spec'd with improving browser support. All this pain in TFA is from people flailing with all of the many bad options that pervade the React ecosystem.
In a couple of years people will wonder why anyone would use something like Tailwind.
What a world we live on.
We stopped using these for a variety of reasons: they were difficult to make secure or cross-platform, GMail made building apps in JavaScript fashionable, and the iPhone (which explicitly would not support ActiveX/Java/Flash).
I think some things work better when they’ve evolved from simplicity to complexity, and application hosts seem to be one of them.
I don't think it's so much a question complexity than a question of using the "right tool for the job". Web technologies were never designed for that, never engineered to be extensible. Web apps is a hack, it's terrible, and that's all because of politics.
Like separating the text and widgets rendering engines, and placement engines with "stick" orientations.
If Tim Berners-Lee had made the web for apps and not documents, history would have been no different. Somebody besides Tim would have made a remote document system and we'd all be using that instead of something called the web.
The moment we do that; we can theoretically implement any GUI framework we like, rendering to a <canvas> tag, without the current (serious) downsides. I’m looking forward towards more exploration of that direction. Then, we can mostly be free of HTML, CSS, and JavaScript defining how apps can be built. Those three tools that have long outlived their original intentions and have gone into complete duct-tape territory.
AI however, might actually solve this sooner than we realize. Apple already uses AI to copy-paste text from images. I’m sure there’s plenty of R&D going on right now on using AI to describe what is on screen. In theory, maybe we can legitimately AI our way out of needing accessibility concessions, and off we go. Build your website in Flutter; or in MAUI; or in some DIY port of SwiftUI; whatever you want.
This is somewhat like the leap Figma has made. They were able to build their own walled-garden, offer value in it, and not have to worry about SEO. Most of the web is not in that position.
I'd imagine we'd be better off with more such fragmentation, though?
The internet was built to allow fragmentation, of protocols, of tech, of connections. It is just that, of course, most sites must flow to where the easy $ are. Let's just hope that enough good sites can escape the pull of easy $.
We might reach the point of saying, screw it, it hardly matters anymore. The web has been conquered by LOB apps, Paywalls, and Walled Gardens; and there’s no real way to fix that, but there is a way to fix the tech we are using.
If anything, if we fully embrace “web as app engine,” we can fix some of these issues ahead of time. Maybe we have a standard entry point for crawlers (or users) requesting the raw text of a document. It’s better than being stuck in this awful in-between which we are right now.
Silverlight, Applets, Flash, all have WebAssembly runtimes now.
On the upside, most people don’t build their own frameworks. Implement it right in Flutter, MAUI, etc. in such a scenario, and almost nobody will be harmed.
Also, for anyone who just says this is Java and Flash all over again - we’ve had plenty of technologies come full circle. WASM might be the one that gets us to full “web as app engine.” It already basically is, just badly.
My experience has been increased cognitive load when I come back to tailwind styles after a long time, when compared to dealing with handwritten CSS selectors and classes
When you say "handwritten CSS selectors and classes," what you really mean is learning a unique codebase with high levels of abstraction that map on to the DOM in a structured way that cannot be automatically inferred. It has to be learned by looking at both the CSS (often buried in many component files) and how the components are implemented in the DOM. In large projects, this is far from trivial.
And I think that's the key. When people say "handwritten" CSS is either, what they mean is that their small project, with no other contributors, is easier to manage.
When picking up a Tailwind project, what's to learn again? You might forget some of the class names, but if you already know the CSS properties, you're 80% there. With your IDE's completion, you're 90%. And crucially, no context switching whatsoever.
We should have left the Web be Web, and use native applications with Internet protocols for applications, like it has always been until the rise of Java applets, ActiveX and Flash.
Then HTML5 came to be, and we have yet to sort out all the mess, but hey should not complain too much, it pays most of the bills.
I don't know about react and vue, but svelte has a style tag that's scoped to the component.
in fairness to css, I think my team would struggle with most technologies they weren’t ready to learn.
https://developer.mozilla.org/en-US/docs/Web/CSS/Nesting_sel...
Browser support is here: https://caniuse.com/?search=nesting
IME, CSS is actually _just fine_ and would do as well as anything else at the job. The real problems arise from:
- People just not being aware of the affordances of modern CSS (like nested selectors, variables, fancy grid layout stuff, etc.). Of course CSS is going is suck if you insist on living with CSS3 like it's 1998.
- Inherent domain contradictions. "I want isolated styling!" "I want consistent theming!" and like the dog in the "no take, only throw!" meme, "I don't want interfaces. I want my styling to be isolated except when I don't want it to be!"
CSS is actually pretty elegant. We should be using declarative, composable configuration (e.g. CUE) in other domains too.
On the other hand, top LLMs are better at CSS than just about everyone so it's a top percentile expert opinion at least lmao.