when a framework author says the framework is “for apps and not content sites” 🚩🚩🚩
52 replies
apps are not allowed to have content, you see
-
@isaacs this emoji is the venn diagram of apps and content: 👀
-
@DavidDarnes wow now I’m starting to understand the SPA white screen
@DavidDarnes @zachleat A blank object, you say? Well, that's often very true if you turn off JS
@Robb @DavidDarnes we may have stumbled into the unified theory of JS
@zachleat no posting allowed
-
@zachleat sounds like said framework author is trying to create drama content on the internets
@p1xelHer0 I now realize that OP source here was indeed from twitter 🧐
@zachleat "I challenge you to define the difference between a webapp and a website that isn't just a vague list of best practices that "apps" are for some reason allowed to disregard." -- https://jakearchibald.com/2013/progressive-enhancement-still-important/ Nothing has changed about that in the ten years since @jaffathecake wrote it :-)
@sil @jaffathecake time is truly a flat circle 😭
arguably, a website has actual discrete hypertext pages that are often read only, while a webapp fetches and/or manipulates data while often performing actions
so really, a webapp that shows content is just a browser-in-a-browser.
but there are actual webapps that don't show content. stuff like figma maybe
@trwnh @sil @jaffathecake I guess (arguably) I think that a web site can fetch and manipulate data while performing actions. Why aren’t Figma designs content?
@zachleat @sil @jaffathecake well "content" is probably a meaningless word but typically in the context of the web i meant "hypertext" and even if you extend the idea to embedded media, figma design files are not really "web" in any meaningful way (unless you create a sharing link). you could have it all native and nothing would change
as for websites that fetch and manipulate data while performing actions, i think those cease to be websites. maybe hybrid website/webapp, but not purely a site.
@zachleat @sil @jaffathecake like the test for website is "does it have pages (as opposed to views)", "can it be edited (or is it only consumed)", stuff like that. it's all about programmatic functionality vs. viewing linked resources
well, why can’t a web site fetch or manipulate data?
just fair warning it will take more than “because it would be a webapp” to convince me 😅
@sil @zachleat @jaffathecake the best division I can think of is: Websites *display* content, but webapps also *create* content
what benefit does this dichotomy provide?
@jaffathecake @juandjara @sil @zachleat “sites” can be archived?
@hans @jaffathecake @sil @juandjara apps can’t be archived?
@zachleat @jaffathecake @juandjara @sil I would say if an “web address” can be meaningfully preserved as a PDF, it’s a site, otherwise an app.
I find that distinction meaningful, most other ways if drawing a line feel like purity policing. (Which I am sometimes guilty of, myself.)
- @zachleat @jaffathecake @juandjara @sil probably I'm being an old, though, and should just give up on the content web and move to Gemini.
@hans sorry to 5 whys you but I think the question I’d like an answer to is: meaningful how? for what? I think there is more gold in those answers
@zachleat no worries!
Meaningful because a “site” is meant for information sharing across both space and time. It’s made of URLs that represent long-lived information resources meant to be linked to. It’s the WEB, FFS.
Apps are pieces of software that use www infrastructure for deployment. Which is a cool hack but should not be confused for being a member of the web-of-URLs.
They may coexist on a domain, mind you. But usually don’t.
(I am growing to think ActivityPub heralds a third category, of conversational “social” apps.)
@zachleat @sil @jaffathecake I don't see it exactly as a dichotomy. I think apps can do everything sites can or should do, but something cataloged as an "app" is generally more interactive, whereas "sites" tend to be more "read-only"
@juandjara @sil @jaffathecake sure, I could get on board with that, if it hadn’t been used almost exclusively as an excuse to cut corners on architecture
@zachleat @sil @jaffathecake and what is wrong with cutting corners if your use case is simpler ?
@juandjara in this particular case, it originally manifested as a mess of client side rendered “single page apps” with a lot of bad side effects and continues to manifest as giant JavaScript bundles serving very little user benefit.
@zachleat wow those are very big issues you are right
@juandjara I… can’t tell if you’re being sarcastic 😅
@zachleat I was not. It's true those are the problems of so called "app frameworks". But sometimes you have to decide what gets worked on if you have many features to ship and optimize later
@sil @zachleat @jaffathecake Nice quote. I've long had an inkling to write a treatise on the false dichotomy between "doc" and "app". This one sentence spares me paragraphs.
@zachleat Only spinners here, thanks
@philhawksworth @zachleat It all makes sense when you substitute "the rich" for "apps" and "mere plebes" for "content sites"
-
-
@andy tfw when the developer in developer experience is the framework author and not the app developer 🫠
@zachleat toxic JSculinity
@sstephenson Tony Stark wasn’t the only Toxic Avenger
@sstephenson @zachleat wait what have I missed?
@natik @sstephenson when did you check in last 😅
@zachleat @sstephenson I _think_ that was yesterday? Anyway.
@zachleat 🫤 I’d be happier if more frameworks made the distinction, honestly. Different paradigms with different goals that result in different architectural decisions. It’d be better to expose those assumptions as early as possible.
@iamEAP to be clear—I agree with the first and third sentences—I want to see those red flags as early as possible in the marketing material
@zachleat THIS AIN’T YOUR GRANDPA’S FRAMEWORK