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