Beyond the fact that almost all web "apps" are actually honest documents, let's not forget that operating systems 20 years ago were more "highly interactive, component-based, state-driven, design-system-heavy applications" and still globally (across all applications at once) themeable. So it seems to me that the problem is that modern UI in fact has lost the concept of modular components. e.g. every time someone comes out with light/dark mode as a feature, I can't help but feel like it's an insider joke that's been running so long that the new kids think it's serious. Every single application used to have a more powerful version of that by default. There were GUIs for users that were simple enough to find and use that my 90 year old grandma had customized the theme on her windows 98 machine.
Kinda like TUI in most terminals where you have 16 colors by default, but those are dependent of the user themes. And it’s quite easy to create a theme engine.
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.
Its not the GUI developers fault usually, it's the platform's fault.
Nobody can decide on standards because everyone is greedy. Microsoft has, like, a dozen GUI platforms and they're all Windows-only. Apple doesn't even use an off the shelf rendering API. And android is... Well, android.
Sure, I would like to use the OS provided controls. And then maybe after that we can all hold hands and sing Kumbaya.
You are 100% right, we have messy incompatible systems because there is no standardization. It is arguable that standardization of something that is so subjective is always going to be problematic. Design patterns are invented all the time and they start to infect other applications/platforms and mutate over time.
The only reason the original post think that "used to be a solved problem" was because we used to have a standard for guis: win32. But obviously people wanted more powerful/flexible UIs and more importantly, cross platform guis so it eventually died off.
A lot of design innovation came because the web is extremely flexible while at the same time being extremely non-standardized.
I honestly don't think it's really all down to being greedy. Even the Linux desktop suffers from this to some extent.
I think it's because UI design is very much something that can't really be "solved" in the traditional sense, so a lot of us use our own opinions when we inevitably find a corner case that isn't working exactly the way we want.
> a lot of us use our own opinions when we inevitably find a corner case that isn't working exactly the way we want.
Most standard toolkits provide escape hatches to have your custom components. I think most designers wants their view imposed to the users instead of following the platform constraints. Like instead of the standard play/pause button every player have, they want their own custom ones. Instead of using the standard tree widget, they want to create another that is the same, but behaves a bit differently. And then they say GTK is not good, let's go with HTML in Electron.
Linux has two application toolkits and they work pretty well together. Windows, again, has a dozen. And they're closed source. Microsoft could just... not... do that. They control the entire thing. But they chose to do it.
Greed is maybe not the right word, but maybe it's more like ideological greed. Like everyone wants things their way 100%. They won't settle for 99%!
Like okay, with Apple and vulkan and metal, is vulkan the best API? No. Is it the most performant? No.
But it's pretty fucking good. Its 95% of the way there. But for greedy apple, that's not good enough. So they say "fuck you, heres metal, good luck developers!"
And now people only make Mac apps if there's a gun to their head and they really need that tiny slice of market share.
Its the same thing with Qt versus bespoke UIs in ImGUI or whatever. Qt is really, really good. Its not perfect.
But we're really gonna burn it all down and start over for like... a 1% improvement in code architecture or something? Really? We're chopping off both our legs so that our pinky finger hurts slightly less?
Sigh. Okay. Such is the way of developers, I guess.
Furthermore, part of the unspoken role of the platform is showing off your brand’s personality with your flashy custom UI. For many, using standard components would be missing the point. Part of the product is the vibes and the website conveys the vibes.
edit: I forgot that it's not a "type" attribute, rather a boolean "multiple" one in the markup.
Also, don't forget that if you want to submit the values with something else than a GET wirh URL params or a POST with formdata mimetype for the body, you'll need JS anyway.
You can use it as backing for some JS component though (visually hidden), this is often done to have components work accessibly and with maximum interoperability. And to get functionality and tests right without implementing complex ARIA standards perfectly and running into constant issues with vanilla form submits (see above) or focus states and a11y.
I find that also in that regard there is a certain irony that now we have devs, with graphics cards that probably can do real time raytracing, but then they reach out to the same experience as my teenager self writing Turbo Vision and Clipper applications on MS-DOS, 30+ years ago!
User interfaces were mostly solved around 2000s. Almost everything after that was gimmicky. And if you don’t need images that much, text interfaces are quite powerful and fast.
I think it was OK for web to have custom designs as it was things that you interact with on a needed basis (like reserving a ticket). Your desktop was a permanent place where programs were used daily, so you expect consistency there.
> Every single application used to have a more powerful version of that by default
Kinda. Having tried to use various dark themes before in that era of theming, it was always a mess of broken applications, since you could easily get a dark-against-dark or a light-against-light contrast if one part of the UI picked up the theme but another part did not. If careful use of the theme colors is not enforced or tested, then themes will tend to be broken in enough cases to not make them worthwhile.
(I'm very pro themeing and customisation, but it's a lot of effort that everyone needs to be on board with to make it work, it's not enough to just make the tools available, you need to actively push them into use, and I think very few people have found that worthwhile: there's just about enough utility to dark modes for enough people for some developers to consider it worthwhile, but I think the longer tail becomes very unpalatable in terms of cost/benefit tradeoff)
This would be less of a problem now that dark/light mode has become a mainstream thing. Both normal users and developers often switch between light and dark, so bugs would be found quickly and solved with high priority.
The reason theming back in the day was often broken is because it was very niche. That one sysadmin using Linux with a satanic theme complaining about some dark-on-dark text won't even get a reply, but a customer's executive running macOS using its built-in automatic dark/light switcher complaining will be the top priority.
It's a shame the implementation went to a boolen dark/light instead of exposing a bunch of semantic color variables like old toolkits used to do, but we can "thank" designers for that one.
"Beyond the fact that almost all web "apps" are actually honest documents, ..."
The www is a document publishing scheme
The documents can contain links ("URLs") pointing to files of any type, text or binary
The documents can contain hyperlinks to each other
Option #1: Publish HTML with visible hyperlink to source code, the www user chooses whether or not to download the code, compile it and run it on their computer
Option #2: Publish HTML with hidden link to executable code, presume that the www user is using a program that contains an interpreter for the code, downloads it to temporary storage and runs it automatically without any www user interaction
Option #2 exposes www users to endless surveillance and monotonous annoyances
It is amusing to watch so-called "technical" people try control this default behaviour in popular browsers, the automatic running of other peoples' Javascripts
Their "solution" is to write their own Javascripts, e.g., "browser extensions"
Whoever maintains the browser software can limit or disable this "solution" at any time for any reason;
Currently companies engaged in online surveillance-based, programmatic, targeted advertising are the browser maintainers
But that nonsense only applies to Option #2
Option #1 is still in heavy usage
Although the number of www users aware of it may be relatively small
For myself as a document consumer, the www still functions well as a document publishing scheme
The problem goes further back than CSS - we're trying to write applications using the DOM. There needs to be a universal Motif-style windowing stack for browsers, but I don't have much confidence that browsers writers will ever agree on any sort of a standard there.
With wasm and canvas you are free to do what you want if you like to re-implement typical GUI behaviors that DOM provides. You could probably compile motif to webasm.
the problem is that every piece of navigation on a site turns a document into an application. separating actual document content from a "frame" that includes navigation and site styling has always been a problem. take hackernews for example. it is not a document. but every message is its own document and the rest is an application to view those documents. you practically can not avoid using application techniques if you have a site with multiple documents.
Hacker News is very much a collection of documents and forms with hyperlinks creating the whole concept of applications. No need to add desktop interactivity (which is already provided by the browser: loading documents, submit the form,...).
Most SPAs are reinventing the browser features (history, routing, navigation state, submitting forms, showing request's responses). When you really needs a full fledged application, those don't really matter (Figma, music players, document viewers,..).
a single document, yes, but once i have more than one document and i want to add additional documents, i need navigation so that i can browse and find those documents. if each document only links back to the parent, and that parent lists all the documents, fine. but if i want to have the same navigation available on all documents, then i need to start making a distinction. that menu to choose the document should not be part of the document itself. the menu is an application used to navigate between documents.
the distinction i make is that a document is static, an application is dynamic. that menu needs to be regenerated every time a new document is added. if i include the menu in each document then every time i add a new document, i have to edit every other document to update the menu.
that has implications, including the timestamp when that document was last changed. therefore the distinction matters. i do not want to have to touch every document in order to update a menu. the menu should be distinct and be changeable without touching existing documents.
current html standards do not allow that because they do not support include. and http does not support directories. that's one advantage gopher had over http.
i can include the menu with javascript, or i could use xslt. but either way, the menu is an application, and it's not part of the document.
no being able to make this distinction is what forced me to build dynamic websites already in the early 90s. back then we didn't even have javascript, we only had serverside includes and eventually servers that could generate whole pages dynamically. it is in part what led me to a search for better webservers than the ones ncsa and cern were offering. but that's another story.
The menu is a templated document fragment, and XSLT runs completely before anything on the page exists (so it's not usable for interactive applications unless you run it in a javascript processor). What you're claiming is like saying a linked CSS file somehow makes the page an application. The application is the browser, and it knows how to put together linked fragments, templates, and styles to form a document. XSLT is exactly how current HTML standards allow static client-side includes just like CSS is how they allow styles.
and that still doesn't work for cases where you want multiple document in one view though.
it is at least a step in the right direction. it allows me to keep the document separate and free of navigation artifacts (the linked example is not ideal in that case, but it can be done).
but the same is achived if i build an SPA with javascript. the browser first loads the SPA application, and then the application loads the documents to be displayed. that allows me to keep the documents as original on the server. and unlike xslt this also works for multiple documents in the same view.
[1]: for those reading that thread to the end, the chromium issue turns out to be limited to the fedora build of chromium, nightly builds from the chromium website and chrome work.
> except that the browser does not provide enough interface for navigation. only back/forward, and clicking on links.
And that is all that needed. If you want to provide a common structure for navigation, usually a menu, it should be sent as part of the page. Which means the document and the navigation needs to be composed server side (either on the fly, or generated once). Then you can enhance the page client side (which is rarely needed).
> let's not forget that operating systems 20 years ago were more "highly interactive, component-based, state-driven, design-system-heavy applications" and still globally (across all applications at once) themeable. So it seems to me that the problem is that modern UI in fact has lost the concept of modular components. e.g. every time someone comes out with light/dark mode as a feature, I can't help but feel like it's an insider joke that's been running so long that the new kids think it's serious
?
It would be possible to have this, by building all apps on the web platform exclusively from native input elements.
For forms. With no fancy things like combo boxes or multi selects!
Window interface, menu bar: using native controls there is ofc a power that web apps don't have.
Regarding the rest, I think you are painting the past with rose-colored glasses.
Yes, UI kits for native applications are more powerful than the web platform in many regards.
But the Windows applications I remember often were a mix of native controls and custom (of course, unthemable) elements.
Many applications even went out of their way to avoid native controls. E.g. SAP, Winamp, and loads of other programs I don't remember now.
Reinventing UI controls is not exclusive to the web platform and "the new kids" have no OS UI framework to build on. They have the web platform.
I too remember the styling options in Windows pre Windows 7.
I loved to play with the ones in Win98.
Most of them would have unpredictable effects on most desktop applications, because of the unpredictable mix of native controls and custom GUI.
If you want to improve web apps, why not argue for better native HTML interactive elements? E.g. menu, multi-select, date-picker...
What I agree with is that handling zoom, font size, color schemes should never be eschewed or ignored.
Oddly enough, in my work history, the Venn diagram of the people who argued for "just make it look like the design, nobody zooms" and the people being smug at web UI was very large. Smug at CSS too, the next moment cheering for obscure and inaccessible, bug-ridden "CSS-only" solutions that the one person who can write CSS proposed as a joke, because a styled toggle switch "shouldn't require JS" (I somewhat agree with this, although the programming language is unimportant).
Rant over... nostalgia is a nice thing.
But web apps are not Windows applications or GTK applications or macOS applications, and these all habe never been as perfect as you make them out.
Sure, large, data-driven applications with good developers for native UI did many things better than many web applications do.
But that's not because web app programmers are too stupid to just do the same thing. That's a tired trope.
Sure, web development has a low barrier to entry. Ranting about it has an even lower one though.
Customization was ok for the web because it was documents and forms. But then they bring those ideas inside the desktop space where you used to have consistent interfaces for your computation.
I kind of wish that the OS provided to the browser the following pieces of theme information...
1. is dark mode
2. primary background color
3. primary forground (text) color
4. primary accent color
5. secondary accent color
6. warning accent color
7. danger accent color
Then the application could use those to apply overall skin/theme to the web application(s). However, you will still have those sites/apps that want their own. The biggest example imo is Slack.
Even material or fluent are similar enough that applications using either tools with the above values for an overall theme would be easy enough to apply throughout an application.
> Fast-forward a couple of decades and we’re building highly interactive, component-based, state-driven, design-system-heavy applications
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.
> 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.
Explain what about Gmail is "highly interactive" because I'm genuinely not seeing it. You receive like an email a minute? There's a Web 1.0 form for sending emails. Where's this "high levels of interactivity"? It's a form and a list of emails that updates occasionally.
It's literally basic web 2.0 junk from the early 2000s, the UI has barely changed since it launched.
Shortcut keys, auto-complete, custom-GUI elements for which no comparable standard element exists, drag and drop, image insertion/resizing, rich text formatting, auto-updates for new items, etc.
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.
> Explain what about Gmail is "highly interactive" because I'm genuinely not seeing it.
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.
Yeah, he's completely clueless and has been commenting like he knows what he is talking about. Or is rage baiting on purpose. Sometimes its impressive the lengths people can go. Nonetheless, I've seen so many people on Hacker News beg for "simple websites" and that they are just "CRUD apps that don't need complexity" while completely dismissing what you've pointed out in the previous comment.
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.
I’ve seen the general public using those “improved” UI and UX and at best not giving a damn. At worst, they are very annoyed when things are hidden or jumping all over the place.
A linear form with help messages is better than any gimmicky design one can think of.
My memory is getting hazy, but wasn't Gmail originally just (something like) the simple HTML version, and it supported tags and classification from the beginning? Like I'm pretty sure I had filters to tag and skip inbox for newegg emails circa 2005 so I could have a separate "inbox" for them. Likewise for some mailing lists I was part of.
> 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.
This. I fully get the in-theory argument that a thick SPA can make for a smoother experience, but that just makes it all the worse that all but the most exceptional SPAs are significantly worse in terms of responsiveness than a series of server-side rendered pages. (even gmail, which is pretty good they go, is laggy and can easy eat up 1GB of RAM)
The fact that people will copy/pasta from stack exchange, or add in massive packages from npm that do things other packages in other areas already do doesn't mean it has to be that way.
A dresser can be hand crafted from solid oak and built to last centuries, or it can be flat-pack barely better than cardboard with fake plastic oak veneer.
You can make a fully functional SPA with less than 1mb of payload, or you can create the hot garbage that is Jack In The Box's menu website, that delivers 48mb of insanely bloated JS garbage. And I only harp on them because it's the single worst SPA example I've seen to date.
For that matter, I think with some nice tooling HTMX can be a pretty great experience for most in-between usage.
I totally agree, maybe 1 in 100 web pages actually NEED any of the code they run. Mostly it's reinventing the wheel. Where a flat site with fixed HTML and pretty CSS would be fine, they add a splash page so they can show a logo, they'll break navigation and reimplement the browser inside the page with JS so you can't use the back button, they'll style everything on the fly when nothing is dynamic, etc. Nonsense.
I don't see how that's related. The HATEOAS idea was that you send the client the relevant data and next set of possible actions with each response (e.g. a web page with forms for possible things they can do). If they try to perform in invalid action, you still just reject on the server. The client doesn't tell the server what it can do.
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.
Easy. It's just about any react/angular/vue based site written these days. Take GMail, Jira, your health insurance portal, TurboTax, and a littany of other sites.
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.
The tax one is especially funny: those "applications" just walk through the same information you'd write on the paper forms! I do free filing every year and "paper forms on the screen with a 'calculate' button for some fields" is the literal UI.
Jira itself does bulk editing with traditional web forms. I'm thinking of that "wizard" flow: The bulk edit operation itself is the "HTTP resource" the user builds up and submits.
All of your examples could've been built using traditional HTML web forms.
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.
I feel exactly the same way as you, and I get flashbacks to every time someone talks about the new framework on the block that serves to fix a problem that 0.1% have, while making things worse for the other 99.9%.
Even though your first instinct might be to immediately pull away when people talk about SPAs, remember that this discussion is about how using a SPA feels vs a server-rendered app that refreshes on every user action. It's not a discussion about the technologies used to build it.
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 really depends on what you call CRUD, but for instance, in the past, I've had frontends hiding the crud behind more "friendly" gestures. For instance, a write such as rescheduling a sale could be done with drag&drop, reads would feed a local store of events/sales that could be browsed either as a workweek panel of which sales are happening, or as a monthly calendar aggregating sales and showing which day is a "hot" day and which day is quiet and needs more blockbusters to drive sales. Add in search features, graphs of forecasted sales and a news feed on the sales a specific user was managing.
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.
You can have interactivity within a single form, whithout having a whole app code humming in the background. And with the drag and drop example, I often see designers missing the obvious accessibility issue where the user can’t use a mouse.
You're mixing two things here: having an app with more than just CRUD interactions, and making that app an SPA.
My point was giving an example of an app that's a bit more featured than just some forms in a CRUD interface, not that you can only do that with a SPA.
> And why not have the DnD and the more complete change form?
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 file comes from wherever you have it stored in the first place (FTP, S3, SFTP, virtually anything) and viewer are plugins implementing various interfaces which are packaged up onto a zip file. With this approach, to add support for psd, I just implemented the image viewer interface (https://github.com/mickael-kerjean/filestash/blob/a605988d5c...), to add support for parquet files I implemented the table viewer interface (https://github.com/mickael-kerjean/filestash/blob/a605988d5c...) and still have the freedom for custom stuff like this docx editor based of libre office wasm: https://github.com/mickael-kerjean/filestash/tree/master/ser... Most of the actual implementations of the base interfaces are done in C, compiled to wasm and running via a web worker
> I haven't seen anything like that. 99.9% of applications I interact with are just a series of simple CRUD operations.
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.
The solution is already here, and it's totally fine: Use utility classes just for layout (margin, padding, etc); use scoped styles for your components; use a small set of globally available classes for styling native elements (buttons, etc) -- and you're good!
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.
Except that tailwind is a huge dependency. Not only it requires a compiler, but editor extensions, plugins, and learning a whole new language to express css.
I think this is good advice. I would say many people end up in that style. Downside is that you have to be pretty experienced with CSS to get this right as it doesn't always give obvious solutions. It's often "it depends".
Here we go. Let's spin the wheel of front-end framework fortune once again. The article correctly identifies that CSS isn't the problem, but just giving up on elegance is premature.
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.
You know, none of the mobile developers I work with ever complain about layout and styling. I rarely see fussing about it online either. Makes me think there is indeed something better out there.
If people were actually creating applications, you would see less fussing on the web too. CSS is fine and you can always use a framework like bootstrap or bulma. But they want to reinvent every thing under the sun to make their custom widgets.
Not only does that not make any sense in the context of this discussion, "it's easy to do layout right for 1 billion devices instead of 4 billion" isn't a very compelling argument.
First you said a mobile app developer doesn't have to worry about various screen sizes. But Android devices come in a ton of sizes and form factors. iPad apps are windowed and resizable, and a native Mac app runs on a system that connects to a monitor of arbitrary size.
So give that point was completely bunk, you changed it to something about the total number of internet connected devices. I have absolutely no clue why that is relevant, and you haven't explained why it is either.
Both BEM and Cascade Layers mentioned in the article in the list under the heading "Every Option Solves One Problem. None Solve All of Them." are "just writing the CSS"
The problem is not reinventing CSS, rather misusing a platform designed for interactive documents as application platform.
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.
There _was_ an outlet for this during the era of Windows hegemony: the object and embed tags. You had your choice of ActiveX, Java, or Shockwave/Flash in the 90s to write applications that you could then embed in the web browser.
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).
Flash was terrible for producing documents, I suppose, but for highly interactive things, nothing matches it, even today (we are getting close in terms of what the web is capable of, performances are getting good, but the tooling and implementation effort/complexity is ridiculous in comparison).
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.
Web technologies were designed to be extensible, for documents. e.g. HTML has had a built in templating engine and support for websites defining their own custom tags for 25 years.
We had a web for applications. It was called telnet. AOL, Prodigy, and others all had actually-pretty-sophisticated remote application deployment systems with vector graphics and fancy input processing. In the early days of the web, it was also common to write line-of-business apps using tools like Visual Basic, Hypercard, and even Excel (some things never change). The web won over all of them because, as history tells us, there are fitness advantages (e.g. platform agnosticism, easy introspection, and gradual enrichment) to evolving application capabilities into a widget toolkit that you just don't get if you try to make the optimal widget toolkit up front.
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.
One day, someone just needs to build an accessibility system for WASM; and maybe (additionally) an overlay system telling the browser that pixels X1, Y1 to X2, Y2 are selectable text.
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.
While I am somewhat entranced by the ideal, presumably the realities of SEO and how most of the web is funded would put a stop to it?
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 $.
I think the short answer, is SEO is dying rapidly in the age of AI search engines. Search traffic is anecdotally being severely damaged when everyone can just get an AI answer; ad revenue is down especially after the pandemic; SEO spam is increasing from AI-generated websites.
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.
We already back there, apparently many haven't yet noticed that all those systems have been ported into WebAssembly, the main issue is that tooling experience is yet to follow along.
Silverlight, Applets, Flash, all have WebAssembly runtimes now.
We’re already getting there. At one point we’re just ripping off the bandage.
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.
How's your experience maintaining styles written in this manner?
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
To the contrary, far less cognitive load. I don’t have to internalize a class name and where it lives in a style sheet and then context switch between the two.
No one does. You either use the web inspector if you need a global view or do a grep to find where the class is being defined.
Tailwind is only useful if you have some kind of templating system where you can define components. And in this case, it’s very easy to scope your css.
I don't see how that's possible. My experience has been the exact opposite.
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.
Classic CCS styles have zero maintenance burden, because they're never maintained. They're treated as read-only and every dev just tacs on and then you have 20 different buttons. In my experience.
All the cognitive load you save is immediately burdened by scanning 60-100 CSS classes in a 200-300 line length HTML element. And this repeated over and over and over in a ginormous number of lines. Giving you a massive migraine.
Turns out HTML size also increase by 7-20x in tailwind CSS.
Tailwind CSS is "write-only" code. Maintaining a site developed by someone else who has gone full-blown worship of the Tailwind Dao is a nightmare.
I guess Tailwind Dao masters are outmatched only by HTML Vice Police :)
Look, it's strictly pragmatic approach, i end up creating utility classes anyway and i'm really glad someone did this for me.
Maintaining Tailwind (or a mix of Tailwind and CSS) is routine, just like it should be.
And i'm talking about web app development, markup is cluttered anyway (tsx or whatnot), semantic effort is already put in components and such. So yeah, saving some cognitive load works and helps in case of Tailwind.
> React, Vue, Svelte. They all put components at the core. Scoped logic. Scoped templates. Scoped state. Then we hand them a stylesheet that’s global, cascading, and inherited by default.
I don't know about react and vue, but svelte has a style tag that's scoped to the component.
All of them have both global and component-scope styles. Not having that flexibility would make a UI framework not viable for modern web dev. Just like with any code, you want to scope as much as possible, but an escape hatch is essential to avoid hacks for those edge cases.
CSS is kudzu, growing wild and untameable. The complexity has long since reached the point that implementing a new browser engine would be nearly impossible. The fact that the maintainers don't even any sort of releases, shows just how out of control it is.
Ah dangit. I was expecting a deeper conclusion. Then I checked on GPTZero and turns out the article is very likely to be AI-made. The header, too (you can tell). I'm not sure I should be taking advice from an LLM...
Maybe it's the author's style but this whole thing feels almost stereotypically written by an LLM. Bullet point overuse, "The real question" "Here’s the uncomfortable truth" "this isn't just X it's a Y"
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.
EDIT: the nested selector popped up without me noticing; removing my comment because I was working from faulty information (and clearly was missing from the blog post)
Thanks! I legitimately missed this not having done intensive CSS work for a few years. Odd that it doesn't appear much in blog posts. I suppose the patterns are still being worked out?
Someone had some thoughts and chose to share them with the internet. I think that's cool. If anything about the internet sucks, it's the inevitable unconstructive criticism from anonymous strangers.
The article is neither vapid nor pointless. You're just reading it as a technical proposal when the author didn't mean it to be one. Articles like this are meant to be nucleating points for vibe shifts, usually in the form of a preference cascade.
Remember how the similarly vapid and pointless Agile Manifesto mysteriously got everyone talking about writing software more flexibly? You're not looking at technical engineering. You're looking at social engineering.
In this instance, if the vibe shift attempt is successful (most are not) we'll stop whining about how much CSS sucks and blaming it for our failures and start talking about how to fill CSS's functionality gaps and make it do what practitioners actually need.
Unpopular opinion: we should treat the web sites less like apps and more like documents with forms. I'm so tired of devs trying to recreate the browser inside of the browser and all the bugs that comes with it
It's a vendor-lock problem that's being solved (by google) by all that complexity. Effectively, it's too expensive to maintain core browser (approx. $1B/year for chromium) engine because of all that css and other standards published (and adopted by some developers) every month.
I thought this was the other way ‘round: Chromium announces it’s adopting/deprecating some tech, and web devs scramble to adapt their websites so they will still work as-expected in Chrome.
This too. Add or remove features from de-facto standard. Both works, to keep the barrier of maintaining any modern browser engine at the skyhigh $1B/year price tag.
This results in only two modern browser engines available: chromium (by google), and FF (mostly sponsored by google). Very sad state.
Beyond the fact that almost all web "apps" are actually honest documents, let's not forget that operating systems 20 years ago were more "highly interactive, component-based, state-driven, design-system-heavy applications" and still globally (across all applications at once) themeable. So it seems to me that the problem is that modern UI in fact has lost the concept of modular components. e.g. every time someone comes out with light/dark mode as a feature, I can't help but feel like it's an insider joke that's been running so long that the new kids think it's serious. Every single application used to have a more powerful version of that by default. There were GUIs for users that were simple enough to find and use that my 90 year old grandma had customized the theme on her windows 98 machine.
Kinda like TUI in most terminals where you have 16 colors by default, but those are dependent of the user themes. And it’s quite easy to create a theme engine.
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.
Its not the GUI developers fault usually, it's the platform's fault.
Nobody can decide on standards because everyone is greedy. Microsoft has, like, a dozen GUI platforms and they're all Windows-only. Apple doesn't even use an off the shelf rendering API. And android is... Well, android.
Sure, I would like to use the OS provided controls. And then maybe after that we can all hold hands and sing Kumbaya.
You are 100% right, we have messy incompatible systems because there is no standardization. It is arguable that standardization of something that is so subjective is always going to be problematic. Design patterns are invented all the time and they start to infect other applications/platforms and mutate over time.
The only reason the original post think that "used to be a solved problem" was because we used to have a standard for guis: win32. But obviously people wanted more powerful/flexible UIs and more importantly, cross platform guis so it eventually died off.
A lot of design innovation came because the web is extremely flexible while at the same time being extremely non-standardized.
I honestly don't think it's really all down to being greedy. Even the Linux desktop suffers from this to some extent.
I think it's because UI design is very much something that can't really be "solved" in the traditional sense, so a lot of us use our own opinions when we inevitably find a corner case that isn't working exactly the way we want.
> a lot of us use our own opinions when we inevitably find a corner case that isn't working exactly the way we want.
Most standard toolkits provide escape hatches to have your custom components. I think most designers wants their view imposed to the users instead of following the platform constraints. Like instead of the standard play/pause button every player have, they want their own custom ones. Instead of using the standard tree widget, they want to create another that is the same, but behaves a bit differently. And then they say GTK is not good, let's go with HTML in Electron.
Linux has two application toolkits and they work pretty well together. Windows, again, has a dozen. And they're closed source. Microsoft could just... not... do that. They control the entire thing. But they chose to do it.
Greed is maybe not the right word, but maybe it's more like ideological greed. Like everyone wants things their way 100%. They won't settle for 99%!
Like okay, with Apple and vulkan and metal, is vulkan the best API? No. Is it the most performant? No.
But it's pretty fucking good. Its 95% of the way there. But for greedy apple, that's not good enough. So they say "fuck you, heres metal, good luck developers!"
And now people only make Mac apps if there's a gun to their head and they really need that tiny slice of market share.
Its the same thing with Qt versus bespoke UIs in ImGUI or whatever. Qt is really, really good. Its not perfect.
But we're really gonna burn it all down and start over for like... a 1% improvement in code architecture or something? Really? We're chopping off both our legs so that our pinky finger hurts slightly less?
Sigh. Okay. Such is the way of developers, I guess.
[dead]
Furthermore, part of the unspoken role of the platform is showing off your brand’s personality with your flashy custom UI. For many, using standard components would be missing the point. Part of the product is the vibes and the website conveys the vibes.
Have fun selling your stakeholders
edit: I forgot that it's not a "type" attribute, rather a boolean "multiple" one in the markup.Also, don't forget that if you want to submit the values with something else than a GET wirh URL params or a POST with formdata mimetype for the body, you'll need JS anyway.
You can use it as backing for some JS component though (visually hidden), this is often done to have components work accessibly and with maximum interoperability. And to get functionality and tests right without implementing complex ARIA standards perfectly and running into constant issues with vanilla form submits (see above) or focus states and a11y.
I find that also in that regard there is a certain irony that now we have devs, with graphics cards that probably can do real time raytracing, but then they reach out to the same experience as my teenager self writing Turbo Vision and Clipper applications on MS-DOS, 30+ years ago!
User interfaces were mostly solved around 2000s. Almost everything after that was gimmicky. And if you don’t need images that much, text interfaces are quite powerful and fast.
And those native web widgets generally match the OS theme
I think it was OK for web to have custom designs as it was things that you interact with on a needed basis (like reserving a ticket). Your desktop was a permanent place where programs were used daily, so you expect consistency there.
> Every single application used to have a more powerful version of that by default
Kinda. Having tried to use various dark themes before in that era of theming, it was always a mess of broken applications, since you could easily get a dark-against-dark or a light-against-light contrast if one part of the UI picked up the theme but another part did not. If careful use of the theme colors is not enforced or tested, then themes will tend to be broken in enough cases to not make them worthwhile.
(I'm very pro themeing and customisation, but it's a lot of effort that everyone needs to be on board with to make it work, it's not enough to just make the tools available, you need to actively push them into use, and I think very few people have found that worthwhile: there's just about enough utility to dark modes for enough people for some developers to consider it worthwhile, but I think the longer tail becomes very unpalatable in terms of cost/benefit tradeoff)
This would be less of a problem now that dark/light mode has become a mainstream thing. Both normal users and developers often switch between light and dark, so bugs would be found quickly and solved with high priority.
The reason theming back in the day was often broken is because it was very niche. That one sysadmin using Linux with a satanic theme complaining about some dark-on-dark text won't even get a reply, but a customer's executive running macOS using its built-in automatic dark/light switcher complaining will be the top priority.
It's a shame the implementation went to a boolen dark/light instead of exposing a bunch of semantic color variables like old toolkits used to do, but we can "thank" designers for that one.
"Beyond the fact that almost all web "apps" are actually honest documents, ..."
The www is a document publishing scheme
The documents can contain links ("URLs") pointing to files of any type, text or binary
The documents can contain hyperlinks to each other
Option #1: Publish HTML with visible hyperlink to source code, the www user chooses whether or not to download the code, compile it and run it on their computer
Option #2: Publish HTML with hidden link to executable code, presume that the www user is using a program that contains an interpreter for the code, downloads it to temporary storage and runs it automatically without any www user interaction
Option #2 exposes www users to endless surveillance and monotonous annoyances
It is amusing to watch so-called "technical" people try control this default behaviour in popular browsers, the automatic running of other peoples' Javascripts
Their "solution" is to write their own Javascripts, e.g., "browser extensions"
Whoever maintains the browser software can limit or disable this "solution" at any time for any reason;
Currently companies engaged in online surveillance-based, programmatic, targeted advertising are the browser maintainers
But that nonsense only applies to Option #2
Option #1 is still in heavy usage
Although the number of www users aware of it may be relatively small
For myself as a document consumer, the www still functions well as a document publishing scheme
s/advertising/& services/
The problem goes further back than CSS - we're trying to write applications using the DOM. There needs to be a universal Motif-style windowing stack for browsers, but I don't have much confidence that browsers writers will ever agree on any sort of a standard there.
With wasm and canvas you are free to do what you want if you like to re-implement typical GUI behaviors that DOM provides. You could probably compile motif to webasm.
A lots of those applications should be standard forms and documents, but they’re adopting application techniques for one reason or another.
the problem is that every piece of navigation on a site turns a document into an application. separating actual document content from a "frame" that includes navigation and site styling has always been a problem. take hackernews for example. it is not a document. but every message is its own document and the rest is an application to view those documents. you practically can not avoid using application techniques if you have a site with multiple documents.
Hacker News is very much a collection of documents and forms with hyperlinks creating the whole concept of applications. No need to add desktop interactivity (which is already provided by the browser: loading documents, submit the form,...).
Most SPAs are reinventing the browser features (history, routing, navigation state, submitting forms, showing request's responses). When you really needs a full fledged application, those don't really matter (Figma, music players, document viewers,..).
No, a hypertext document is still just a document and not an application.
a single document, yes, but once i have more than one document and i want to add additional documents, i need navigation so that i can browse and find those documents. if each document only links back to the parent, and that parent lists all the documents, fine. but if i want to have the same navigation available on all documents, then i need to start making a distinction. that menu to choose the document should not be part of the document itself. the menu is an application used to navigate between documents.
the distinction i make is that a document is static, an application is dynamic. that menu needs to be regenerated every time a new document is added. if i include the menu in each document then every time i add a new document, i have to edit every other document to update the menu.
that has implications, including the timestamp when that document was last changed. therefore the distinction matters. i do not want to have to touch every document in order to update a menu. the menu should be distinct and be changeable without touching existing documents.
current html standards do not allow that because they do not support include. and http does not support directories. that's one advantage gopher had over http.
i can include the menu with javascript, or i could use xslt. but either way, the menu is an application, and it's not part of the document.
no being able to make this distinction is what forced me to build dynamic websites already in the early 90s. back then we didn't even have javascript, we only had serverside includes and eventually servers that could generate whole pages dynamically. it is in part what led me to a search for better webservers than the ones ncsa and cern were offering. but that's another story.
The menu is a templated document fragment, and XSLT runs completely before anything on the page exists (so it's not usable for interactive applications unless you run it in a javascript processor). What you're claiming is like saying a linked CSS file somehow makes the page an application. The application is the browser, and it knows how to put together linked fragments, templates, and styles to form a document. XSLT is exactly how current HTML standards allow static client-side includes just like CSS is how they allow styles.
The application is the browser
except that the browser does not provide enough interface for navigation. only back/forward, and clicking on links.
compare that to an email client or really any other application. hackernews is a messaging application.
a linked CSS file somehow makes the page an application
no, to keep with the analogy, the CSS part IS the application.
XSLT is exactly how current HTML standards allow static client-side includes
well, kind of. you need a lot of code to describe a simple template: https://news.ycombinator.com/item?id=44398626 [1]
and that still doesn't work for cases where you want multiple document in one view though.
it is at least a step in the right direction. it allows me to keep the document separate and free of navigation artifacts (the linked example is not ideal in that case, but it can be done).
but the same is achived if i build an SPA with javascript. the browser first loads the SPA application, and then the application loads the documents to be displayed. that allows me to keep the documents as original on the server. and unlike xslt this also works for multiple documents in the same view.
[1]: for those reading that thread to the end, the chromium issue turns out to be limited to the fedora build of chromium, nightly builds from the chromium website and chrome work.
> except that the browser does not provide enough interface for navigation. only back/forward, and clicking on links.
And that is all that needed. If you want to provide a common structure for navigation, usually a menu, it should be sent as part of the page. Which means the document and the navigation needs to be composed server side (either on the fly, or generated once). Then you can enhance the page client side (which is rarely needed).
> let's not forget that operating systems 20 years ago were more "highly interactive, component-based, state-driven, design-system-heavy applications" and still globally (across all applications at once) themeable. So it seems to me that the problem is that modern UI in fact has lost the concept of modular components. e.g. every time someone comes out with light/dark mode as a feature, I can't help but feel like it's an insider joke that's been running so long that the new kids think it's serious
?
It would be possible to have this, by building all apps on the web platform exclusively from native input elements.
For forms. With no fancy things like combo boxes or multi selects!
Window interface, menu bar: using native controls there is ofc a power that web apps don't have.
Regarding the rest, I think you are painting the past with rose-colored glasses.
Yes, UI kits for native applications are more powerful than the web platform in many regards.
But the Windows applications I remember often were a mix of native controls and custom (of course, unthemable) elements.
Many applications even went out of their way to avoid native controls. E.g. SAP, Winamp, and loads of other programs I don't remember now.
Reinventing UI controls is not exclusive to the web platform and "the new kids" have no OS UI framework to build on. They have the web platform.
I too remember the styling options in Windows pre Windows 7.
I loved to play with the ones in Win98.
Most of them would have unpredictable effects on most desktop applications, because of the unpredictable mix of native controls and custom GUI.
If you want to improve web apps, why not argue for better native HTML interactive elements? E.g. menu, multi-select, date-picker...
What I agree with is that handling zoom, font size, color schemes should never be eschewed or ignored.
Oddly enough, in my work history, the Venn diagram of the people who argued for "just make it look like the design, nobody zooms" and the people being smug at web UI was very large. Smug at CSS too, the next moment cheering for obscure and inaccessible, bug-ridden "CSS-only" solutions that the one person who can write CSS proposed as a joke, because a styled toggle switch "shouldn't require JS" (I somewhat agree with this, although the programming language is unimportant).
Rant over... nostalgia is a nice thing.
But web apps are not Windows applications or GTK applications or macOS applications, and these all habe never been as perfect as you make them out.
Sure, large, data-driven applications with good developers for native UI did many things better than many web applications do.
But that's not because web app programmers are too stupid to just do the same thing. That's a tired trope.
Sure, web development has a low barrier to entry. Ranting about it has an even lower one though.
Your comment kind of reminds me of old school Winamp and its skins.
Someone’s never used the old MacOS before OS X. Anyone remember Kaleidoscope?
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.
Customization was ok for the web because it was documents and forms. But then they bring those ideas inside the desktop space where you used to have consistent interfaces for your computation.
I kind of wish that the OS provided to the browser the following pieces of theme information...
Then the application could use those to apply overall skin/theme to the web application(s). However, you will still have those sites/apps that want their own. The biggest example imo is Slack.Even material or fluent are similar enough that applications using either tools with the above values for an overall theme would be easy enough to apply throughout an application.
> Fast-forward a couple of decades and we’re building highly interactive, component-based, state-driven, design-system-heavy applications
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.
> Are we, in fact, if we're being honest?
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.
Explain what about Gmail is "highly interactive" because I'm genuinely not seeing it. You receive like an email a minute? There's a Web 1.0 form for sending emails. Where's this "high levels of interactivity"? It's a form and a list of emails that updates occasionally.
It's literally basic web 2.0 junk from the early 2000s, the UI has barely changed since it launched.
Shortcut keys, auto-complete, custom-GUI elements for which no comparable standard element exists, drag and drop, image insertion/resizing, rich text formatting, auto-updates for new items, etc.
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.
There used to be a basic HTML version of gmail but it seems it just redirects you to normal gmail now.
No one in their right mind who does a lot of emailing would use it compared to the normal one besides for ideological reasons.
> Explain what about Gmail is "highly interactive" because I'm genuinely not seeing it.
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.
Yeah, he's completely clueless and has been commenting like he knows what he is talking about. Or is rage baiting on purpose. Sometimes its impressive the lengths people can go. Nonetheless, I've seen so many people on Hacker News beg for "simple websites" and that they are just "CRUD apps that don't need complexity" while completely dismissing what you've pointed out in the previous comment.
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.
I’ve seen the general public using those “improved” UI and UX and at best not giving a damn. At worst, they are very annoyed when things are hidden or jumping all over the place.
A linear form with help messages is better than any gimmicky design one can think of.
My memory is getting hazy, but wasn't Gmail originally just (something like) the simple HTML version, and it supported tags and classification from the beginning? Like I'm pretty sure I had filters to tag and skip inbox for newegg emails circa 2005 so I could have a separate "inbox" for them. Likewise for some mailing lists I was part of.
It was. And it was glorious. Fast and snappy, loaded instantly and felt responsive. Then they did the full SPA redesign…
> 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.
Petty sniping is not welcome.
Is Hey a WebApp or CRUD app ( with added interactivity )?
When people say CRUD App, I assume they mean web page + sprinkle of JavaScripts.
And yet 90+% of those SPA-apps have worse performance.
This. I fully get the in-theory argument that a thick SPA can make for a smoother experience, but that just makes it all the worse that all but the most exceptional SPAs are significantly worse in terms of responsiveness than a series of server-side rendered pages. (even gmail, which is pretty good they go, is laggy and can easy eat up 1GB of RAM)
The fact that people will copy/pasta from stack exchange, or add in massive packages from npm that do things other packages in other areas already do doesn't mean it has to be that way.
A dresser can be hand crafted from solid oak and built to last centuries, or it can be flat-pack barely better than cardboard with fake plastic oak veneer.
You can make a fully functional SPA with less than 1mb of payload, or you can create the hot garbage that is Jack In The Box's menu website, that delivers 48mb of insanely bloated JS garbage. And I only harp on them because it's the single worst SPA example I've seen to date.
For that matter, I think with some nice tooling HTMX can be a pretty great experience for most in-between usage.
I totally agree, maybe 1 in 100 web pages actually NEED any of the code they run. Mostly it's reinventing the wheel. Where a flat site with fixed HTML and pretty CSS would be fine, they add a splash page so they can show a logo, they'll break navigation and reimplement the browser inside the page with JS so you can't use the back button, they'll style everything on the fly when nothing is dynamic, etc. Nonsense.
> 99.9% of applications I interact with are just a series of simple CRUD operations.
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.
Only if you trust the client, presumably.
I don't see how that's related. The HATEOAS idea was that you send the client the relevant data and next set of possible actions with each response (e.g. a web page with forms for possible things they can do). If they try to perform in invalid action, you still just reject on the server. The client doesn't tell the server what it can do.
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.
Easy. It's just about any react/angular/vue based site written these days. Take GMail, Jira, your health insurance portal, TurboTax, and a littany of other sites.
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.
All of those examples boil down to very simple forms, web 1.0 style forms. CRUD.
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.
The tax one is especially funny: those "applications" just walk through the same information you'd write on the paper forms! I do free filing every year and "paper forms on the screen with a 'calculate' button for some fields" is the literal UI.
Wow I see you never had to edit more than 20 things on a list in a Web 1.0 submit form style.
Like go over 20 jira tickets to update the names or adjust different properties on different ticket.
Jira itself does bulk editing with traditional web forms. I'm thinking of that "wizard" flow: The bulk edit operation itself is the "HTTP resource" the user builds up and submits.
Bulk editing yes.
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.
Jira is a horrible tool I only use because I am forced to.
The old way was ctrl-clicking to open the form in a new tab/windows. And when AJAX, it was easy to use jQuery to make update request.
All of your examples could've been built using traditional HTML web forms.
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.
I feel exactly the same way as you, and I get flashbacks to every time someone talks about the new framework on the block that serves to fix a problem that 0.1% have, while making things worse for the other 99.9%.
Even though your first instinct might be to immediately pull away when people talk about SPAs, remember that this discussion is about how using a SPA feels vs a server-rendered app that refreshes on every user action. It's not a discussion about the technologies used to build it.
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 really depends on what you call CRUD, but for instance, in the past, I've had frontends hiding the crud behind more "friendly" gestures. For instance, a write such as rescheduling a sale could be done with drag&drop, reads would feed a local store of events/sales that could be browsed either as a workweek panel of which sales are happening, or as a monthly calendar aggregating sales and showing which day is a "hot" day and which day is quiet and needs more blockbusters to drive sales. Add in search features, graphs of forecasted sales and a news feed on the sales a specific user was managing.
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.
You can have interactivity within a single form, whithout having a whole app code humming in the background. And with the drag and drop example, I often see designers missing the obvious accessibility issue where the user can’t use a mouse.
So you’d need to select a sale, enter a change form, select a new date and validate the change. As opposed to moving the item on your planning.
Accessibility issue is a good point, but the accessible way doesn’t need to be the only way.
> So you’d need to select a sale, enter a change form, select a new date and validate the change. As opposed to moving the item on your planning.
That's pre-javascript workflow. You can have your DnD without making your app an SPA. And why not have the DnD and the more complete change form?
You're mixing two things here: having an app with more than just CRUD interactions, and making that app an SPA.
My point was giving an example of an app that's a bit more featured than just some forms in a CRUD interface, not that you can only do that with a SPA.
> And why not have the DnD and the more complete change form?
It was, in fact, what we did.
It's all the buzzwords to justify the overcomplexity of web frontends.
I work on exactly this kind of app, and it’s open source: https://github.com/mickael-kerjean/filestash.
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
Where do these files come from? And the viewer?
The file comes from wherever you have it stored in the first place (FTP, S3, SFTP, virtually anything) and viewer are plugins implementing various interfaces which are packaged up onto a zip file. With this approach, to add support for psd, I just implemented the image viewer interface (https://github.com/mickael-kerjean/filestash/blob/a605988d5c...), to add support for parquet files I implemented the table viewer interface (https://github.com/mickael-kerjean/filestash/blob/a605988d5c...) and still have the freedom for custom stuff like this docx editor based of libre office wasm: https://github.com/mickael-kerjean/filestash/tree/master/ser... Most of the actual implementations of the base interfaces are done in C, compiled to wasm and running via a web worker
> I haven't seen anything like that. 99.9% of applications I interact with are just a series of simple CRUD operations.
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.
The solution is already here, and it's totally fine: Use utility classes just for layout (margin, padding, etc); use scoped styles for your components; use a small set of globally available classes for styling native elements (buttons, etc) -- and you're good!
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.
This is how I write css.
In a couple of years people will wonder why anyone would use something like Tailwind.
The utility classes can be tailwind
Except that tailwind is a huge dependency. Not only it requires a compiler, but editor extensions, plugins, and learning a whole new language to express css.
not when you use unocss (and tailwind4, I think, but I don't use it).
I think this is good advice. I would say many people end up in that style. Downside is that you have to be pretty experienced with CSS to get this right as it doesn't always give obvious solutions. It's often "it depends".
Here we go. Let's spin the wheel of front-end framework fortune once again. The article correctly identifies that CSS isn't the problem, but just giving up on elegance is premature.
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.
You know, none of the mobile developers I work with ever complain about layout and styling. I rarely see fussing about it online either. Makes me think there is indeed something better out there.
If people were actually creating applications, you would see less fussing on the web too. CSS is fine and you can always use a framework like bootstrap or bulma. But they want to reinvent every thing under the sun to make their custom widgets.
Ask that mobile developer to deploy to different OSes, desktop, wide-screen and you'll find out
Seems pretty common in mobile dev, the iPad is hugely popular and widescreen. Many apps also run on Mac desktop.
That would amount to a total of 25% of the devices connected to the internet.
I have no idea what point you're trying to make here
It's easy to do layout right for such a small subset of the market.
Not only does that not make any sense in the context of this discussion, "it's easy to do layout right for 1 billion devices instead of 4 billion" isn't a very compelling argument.
Oh my. Yeah. Your app working only on 1/4 of the devices in place of 100% is not compelling. What a waste of time.
First you said a mobile app developer doesn't have to worry about various screen sizes. But Android devices come in a ton of sizes and form factors. iPad apps are windowed and resizable, and a native Mac app runs on a system that connects to a monitor of arbitrary size.
So give that point was completely bunk, you changed it to something about the total number of internet connected devices. I have absolutely no clue why that is relevant, and you haven't explained why it is either.
Aren't we still using CSS3?
Oh, man. The article doesn't even give "just writing the CSS" as an option...
What a world we live on.
Both BEM and Cascade Layers mentioned in the article in the list under the heading "Every Option Solves One Problem. None Solve All of Them." are "just writing the CSS"
The problem is not reinventing CSS, rather misusing a platform designed for interactive documents as application platform.
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 wonder how different things would be today if the web browser was originally designed for applications rather than documents.
There _was_ an outlet for this during the era of Windows hegemony: the object and embed tags. You had your choice of ActiveX, Java, or Shockwave/Flash in the 90s to write applications that you could then embed in the web browser.
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).
That’s what Flash was, and it was terrible.
I think some things work better when they’ve evolved from simplicity to complexity, and application hosts seem to be one of them.
Apparently not, given that it is exactly what WebAssembly folks are after, unfortunely with much worse tooling than Flash Studio had at our disposal.
Flash was terrible for producing documents, I suppose, but for highly interactive things, nothing matches it, even today (we are getting close in terms of what the web is capable of, performances are getting good, but the tooling and implementation effort/complexity is ridiculous in comparison).
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.
Web technologies were designed to be extensible, for documents. e.g. HTML has had a built in templating engine and support for websites defining their own custom tags for 25 years.
Absolutely, the context there was "extended from simple Document/Markup jobs and into rich applications toolkits".
Flash was amazing and we lost a good amount of fun online when Apple killed it
The PRD for Flash was amazing, the implementation was pure crap. It had more bugs than functioning code, and more security issues than APIs.
Would you please stop trying to execute code on my computer just to show me a document?
We had a web for applications. It was called telnet. AOL, Prodigy, and others all had actually-pretty-sophisticated remote application deployment systems with vector graphics and fancy input processing. In the early days of the web, it was also common to write line-of-business apps using tools like Visual Basic, Hypercard, and even Excel (some things never change). The web won over all of them because, as history tells us, there are fitness advantages (e.g. platform agnosticism, easy introspection, and gradual enrichment) to evolving application capabilities into a widget toolkit that you just don't get if you try to make the optimal widget toolkit up front.
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.
I'm really not sure. People tend to follow that comment with a list of requests for stuff that CSS does, exactly on the way that CSS does.
Like separating the text and widgets rendering engines, and placement engines with "stick" orientations.
Or, imagine if they just froze the CSS spec at some point and allowed tools and methodologies to catch up.
One day, someone just needs to build an accessibility system for WASM; and maybe (additionally) an overlay system telling the browser that pixels X1, Y1 to X2, Y2 are selectable text.
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.
While I am somewhat entranced by the ideal, presumably the realities of SEO and how most of the web is funded would put a stop to it?
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 $.
I think the short answer, is SEO is dying rapidly in the age of AI search engines. Search traffic is anecdotally being severely damaged when everyone can just get an AI answer; ad revenue is down especially after the pandemic; SEO spam is increasing from AI-generated websites.
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.
Can't you already do this by creating a tree of invisible DOM elements with the right ARIA attributes?
And then we'll return to Java Beans and ugly, inflexible text layout, isn't it?
We already back there, apparently many haven't yet noticed that all those systems have been ported into WebAssembly, the main issue is that tooling experience is yet to follow along.
Silverlight, Applets, Flash, all have WebAssembly runtimes now.
We’re already getting there. At one point we’re just ripping off the bandage.
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.
I embrace the mess of tailwind-cluttered markup to eliminate context switching and save up some cognitive load.
How's your experience maintaining styles written in this manner?
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
To the contrary, far less cognitive load. I don’t have to internalize a class name and where it lives in a style sheet and then context switch between the two.
No one does. You either use the web inspector if you need a global view or do a grep to find where the class is being defined.
Tailwind is only useful if you have some kind of templating system where you can define components. And in this case, it’s very easy to scope your css.
I don't see how that's possible. My experience has been the exact opposite.
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.
Classic CCS styles have zero maintenance burden, because they're never maintained. They're treated as read-only and every dev just tacs on and then you have 20 different buttons. In my experience.
All the cognitive load you save is immediately burdened by scanning 60-100 CSS classes in a 200-300 line length HTML element. And this repeated over and over and over in a ginormous number of lines. Giving you a massive migraine.
Turns out HTML size also increase by 7-20x in tailwind CSS.
Tailwind CSS is "write-only" code. Maintaining a site developed by someone else who has gone full-blown worship of the Tailwind Dao is a nightmare.
I guess Tailwind Dao masters are outmatched only by HTML Vice Police :)
Look, it's strictly pragmatic approach, i end up creating utility classes anyway and i'm really glad someone did this for me.
Maintaining Tailwind (or a mix of Tailwind and CSS) is routine, just like it should be.
And i'm talking about web app development, markup is cluttered anyway (tsx or whatnot), semantic effort is already put in components and such. So yeah, saving some cognitive load works and helps in case of Tailwind.
> React, Vue, Svelte. They all put components at the core. Scoped logic. Scoped templates. Scoped state. Then we hand them a stylesheet that’s global, cascading, and inherited by default.
I don't know about react and vue, but svelte has a style tag that's scoped to the component.
Vue has had scoped css for a decade. I was very pleased moving to Vue from zope templates and jQuery spaghetti.
All of them have both global and component-scope styles. Not having that flexibility would make a UI framework not viable for modern web dev. Just like with any code, you want to scope as much as possible, but an escape hatch is essential to avoid hacks for those edge cases.
CSS is kudzu, growing wild and untameable. The complexity has long since reached the point that implementing a new browser engine would be nearly impossible. The fact that the maintainers don't even any sort of releases, shows just how out of control it is.
> The complexity has long since reached the point that implementing a new browser engine would be nearly impossible
There are people building new browser engines
Ah dangit. I was expecting a deeper conclusion. Then I checked on GPTZero and turns out the article is very likely to be AI-made. The header, too (you can tell). I'm not sure I should be taking advice from an LLM...
"Cascade Layers […] give you more control, if your team is ready to learn them"
in fairness to css, I think my team would struggle with most technologies they weren’t ready to learn.
Maybe it's the author's style but this whole thing feels almost stereotypically written by an LLM. Bullet point overuse, "The real question" "Here’s the uncomfortable truth" "this isn't just X it's a Y"
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.
EDIT: the nested selector popped up without me noticing; removing my comment because I was working from faulty information (and clearly was missing from the blog post)
We have had nested style rules in native CSS for a couple of years already.
https://developer.mozilla.org/en-US/docs/Web/CSS/Nesting_sel...
Thanks! I legitimately missed this not having done intensive CSS work for a few years. Odd that it doesn't appear much in blog posts. I suppose the patterns are still being worked out?
Sorry if you know about this, I can't tell from your post. But nesting CSS has been added. Here's the MDN article: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_nesting
Browser support is here: https://caniuse.com/?search=nesting
Impugning CSS and not knowing that nested selectors work fine everywhere is just perfect example of what I'm discussing here: https://news.ycombinator.com/item?id=44876345
Didn't they do it? https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_nesting...
BEM is a naming convention and SCSS is a preprocessor, they're completely different things.
[flagged]
Someone had some thoughts and chose to share them with the internet. I think that's cool. If anything about the internet sucks, it's the inevitable unconstructive criticism from anonymous strangers.
The article is neither vapid nor pointless. You're just reading it as a technical proposal when the author didn't mean it to be one. Articles like this are meant to be nucleating points for vibe shifts, usually in the form of a preference cascade.
Remember how the similarly vapid and pointless Agile Manifesto mysteriously got everyone talking about writing software more flexibly? You're not looking at technical engineering. You're looking at social engineering.
In this instance, if the vibe shift attempt is successful (most are not) we'll stop whining about how much CSS sucks and blaming it for our failures and start talking about how to fill CSS's functionality gaps and make it do what practitioners actually need.
Unpopular opinion: we should treat the web sites less like apps and more like documents with forms. I'm so tired of devs trying to recreate the browser inside of the browser and all the bugs that comes with it
It's a vendor-lock problem that's being solved (by google) by all that complexity. Effectively, it's too expensive to maintain core browser (approx. $1B/year for chromium) engine because of all that css and other standards published (and adopted by some developers) every month.
I thought this was the other way ‘round: Chromium announces it’s adopting/deprecating some tech, and web devs scramble to adapt their websites so they will still work as-expected in Chrome.
This too. Add or remove features from de-facto standard. Both works, to keep the barrier of maintaining any modern browser engine at the skyhigh $1B/year price tag.
This results in only two modern browser engines available: chromium (by google), and FF (mostly sponsored by google). Very sad state.
No-one tell Ladybird.