This is interesting for sure. Kudos for bringing this capability to the web!
One issue the demos reveal is, it doesn't _feel_ like the web. That is, I can't hit Ctrl+F to find text on a page. I can't select text with my cursor. I can't copy the address of a hyperlink. On my phone, I can't hard press on an image and share it to others. Screen readers can't handle it. I can't press a shortcut key to make everything larger.
These all may seem pedantic, but they contribute to the feeling "this is not the real web."
This is the same problem with Java applets in the late '90s, Flash and Silverlight in the early 2000s. They are islands of richness within a web page, but those islands are, well, opaque to browsers, search engines, and virtually all web tooling.
That's not pedantic at all! Indeed, without these capabilities, it is by some definition not the real web.
This hits into that concept of what exactly the "web" is. Is it just a media transport system? Or is it something more than that. Of course, we could cite Tim Berners-Lee here or Roy Fielding in this discussion.
But at minimum, I think a lot of us are tired of the app-lification of the web and somewhat wish we could have a bit of the old.
It's also an interesting question, why, in traditional rich desktop applications, I can't say I have ever missed the ability to select and copy text from the UI chrome - whereas on the web I'd definitly miss it and in badly designed mobile apps, I often do.
I think some part of UI design degraded with the web, where there used to be a clearer distinction between "user data" and "app chrome" areas than there is today.
I'd also like if we could get back to selections of more complex data types at some point and not just treat everything as text. UI toolkits have all kinds of lists and treeviews to model selectable entities, whereas in the browser, there just a single huge wall of text for everything.
> why, in traditional rich desktop applications, I can't say I have ever missed the ability to select and copy text from the UI
I do miss this on an almost daily basis and I have stopped paying for services that force me to use an app without offering a website.
The last instance of this was just a couple days ago when I could not copy a tracking number from an e-commerce app (to then paste it into the shipping company website) but at least this e-commerce company has a web UI so I could rely on that.
Oh and the other one that I miss almost daily is cmd-F / ctrl-F
This is why technology is becoming garbage. In 2025 instead of copy paste, we fire up a gpu in a datacenter. it feels like "software engineering" is just becoming a BS contest for "how much AI can we shoehorn into everything"
Not fully disagreeing, but this lack of copypaste is not an intended ai feature.
- The “magic ocr thingy” exists for things like taking a picture of the real world and grabbing text from it, or grabbing text from a video from something you saw recorded there. Think translating a foreign sign or whatever.
- interfaces have, for unrelated reasons, become more hostile to standard actions like copypaste.
As a result people end up having to ocr-scan interfaces with the tool.
Some of it is because how people interact with and use tech has changed.
Mobile users have completely outpaced laptop/desktop users, and mobile users don't think in terms of files and text, so to them copy & paste is less important. The mythical "average user" moves arbitrary text and data around using screenshots and screen recordings instead of text and files.
Yes, it's incredibly inefficient, but I think it's evolved that day because selecting text is a real pain on a small touch screen, and companies have been trying to abstract away any concept of a filesystem for a long time.
So you or I might care and be bothered that we can't copy & paste something from UI chrome or content in a "web app" but the average person won't care, they'll just take a screenshot.
"E commerce apps" are very much not the sort of traditional desktop application they were referring to. Note that they add "in badly designed mobile apps, I often do."
They're referring more to things like "you can't copy the text labeling the brush width field in Photoshop" (but you CAN copy the text out of that editable field). It's a part of app design people are extremely lazy with today, as you note.
In any sensibly designed desktop package tracking app that number would've been selectable or copy-able text, like how an email subject is in a desktop email app. (Thunderbird, say.)
(Interestingly, ctrl-f to find is one that many apps/OSes have now borrowed back, with the ability to "find" items in menus through a Help menu -> Search action.)
> I can't say I have ever missed the ability to select and copy text from the UI chrome
Good heavens. I boggled at this.
It's not every single day, but probably at least once a week I am frustrated by this, and have been since the rise of PC GUIs -- so, coming up on 35 years now. It was often doable on DOS-era PCs, especially if you had a mouse, or a multitasking environment like DESQview, or best of all, both.
> in traditional rich desktop applications, I can't say I have ever missed the ability to select and copy text from the UI chrome
I forgot what desktop application it was, but there was a time that I repeatedly needed to copy texts from a dialog, which didn't support text selection. It frustrated me so much, that I put together a script to do OCR on the dialog.
Supporting complex data types for copy & paste is good; but it is almost trivial to also support plain text copying as a fallback when it already supports copying of other mimetypes. The problem is that some UI has no support of copying in any format at all.
If it was a standard Windows dialog box by any chance, you could just have pressed Ctrl+C with the dialog in focus to copy the message. It's one of these subtle things that go almost completely overlooked.
There's a lot of nice little things like that in desktop OSes that we completely lose with everyone shifting to using electron, and I'm increasingly frustrated by it as time goes on.
on macOS, anything that uses the OS text input box has emacs keybindings. Universal text editing bindings across the entire OS for all native apps. You lose that with electron, just like you lose a lot of the windows niceties the moment apps stop using win32 and start overriding with their own custom UI toolkits in the name of "branding."
It's part of the big reason computers started to be perceived as difficult to use, and it's not because of the various operating systems. It's because desktop apps stopped respecting the OS and the user, so instead of only needing to learn the operating system's conventions, which would apply to every app built for it, you now have to learn every individual app's quirks and conventions.
The web just continued to make it worse where now every app is it's own little special snowflake.
Thanks, doesn't help me, but you're right, a good tip to know. Though I'd still prefer a similar option to start selection directly in the UI instead of finishing the job in a text editor, this would also help highlight text in a screenshot without having to do image post-processing! I'd even accept some arcane finger-breaking ctrl-alt-win-x-y-z (which I could rebind) for the privilege
All the more annoying when such years-old fundamentals are broken in all the new "supposedly better" frameworks
While I do occasionally miss it there as well, I think the main difference is that I very rarely use desktop applications for information gathering.
I never "read" a desktop application, whereas that is mostly what I use a browser for. And if I can't properly interact with text on a website, then I would likely reach for something else.
Back in ye olden days desktop applications for information gathering like Encarta let you select and copy text because they were thoughtfully designed and knew that "information you were gathering" should be different than "application chrome" - that's the distinction being made here.
Information-oriented desktop apps still do this - any good email client, for instance, should make it trivial to copy a subject line or "to"/"from" address even if it's in the UI chrome.
I've had the same thoughts as I watch YouTube slowly but steadily subsume "podcast."
We were all worried about something like Spotify killing off open RSS feeds for them, but there's a growing number of people who have no idea what a podcast is because people are using the term for YouTube channels with full video and no RSS feed (video or audio) to match it. Sometimes language drift is good, but not when it's done on purpose to get rid of a free and open technology in favor of silos.
"Wherever you get your podcasts" only works as long as it's built on top of an open method of syndication.
IMHO there's no gatekeeper of what the "real" web is or should be. It grew organically - regular people building things they liked or needed. It's certainly more of a life necessity than it used to be, but that happened organically too.
I know there are strongly held opinions about this, but I for one see no reason why the "application web" can't peacefully coexist, and interlink with, the document web. In my opinion it therefore makes sense to allow for different models for the application web, ones that do not revolve around a document.
On the other hand, if we're just bashing on javascript being the lingua franca of the web, that's a train I'll happily board!
Not using the standard web stuff usually means it's also an accessibility nightmare, tried using a screen reader on the demo and it doesn't work at all unfortunately
I wonder if at any point browsers will offer a low level accessibility API for you to manually describe components. I’ve worked in the web for years and I’m a big believer but it’s also indisputable that Canvas offers more performant UI rendering than HTML when done correctly. I don’t think it should ever be used for web “documents” but web apps already bastardize HTML and CSS to achieve their aims anyway. Accessibility remains the missing component.
It's HTML imagemaps from the 90s, when we could not style buttons and navbars where GIFs with links in the right places. Browsers still have the code to render them.
OTH, we are still failing to provide a bare minimum for accessibility. Heck, we even needed a law (in the EU, that than needed to be translated to national law), so that companies providing crucial end user services would care about accessibility.
I want every app and every web page to be 100% navigable if I do not have a pointing device attached to my computer.
And I want this enforced by law, by large rich countries. Accessibility to people with disabilities would be a good way: if your product or service is not accessible to people who can't see, can't use a mouse, or can't use their hands at all, then you can't sell it.
I'm not aware of any screen reader that works by continuously feeding screenshots of user interfaces into a remote expensive image LLM, which is an absolutely insane and impractical idea for many reasons, but I used standard TalkBack on Android
MAUI was never intended for the web. This is not what Microsoft wants you to use it for.
WASM is just one of the platforms that Avalonia supports and so, if you run MAUI on Avalonia, you can run it on WASM.
If you do that though, it is going to be like rendering any other desktop GUI toolkit in WASM. It is not a web app. I mean, it is cool you can do it and MAUI in WASM is better than no web capability at all I guess. But you would never set out to create a web app in MAUI.
MAUI on Avalonia on WASM is really a modern replacement for Silverlight. And it will likely be about as popular.
The really cool thing is being able to target the Linux desktop finally. A lot of people will love that.
And, while MAUI was meant to use native controls on each platform, many people may prefer the Avalonia approach of having your app render the same everywhere.
Blazor+MAUI has absolutely been a focus of development from the start. What Im seeing with this is that MAUI is somewhat throwing in the towel and hoping to offload to avalonia to take the torch of development. I'm sad, because I was pretty in the weeds with MAUI at the start, as I was building a greenfield app at the time. It had a ton of potential to be a reimagining of Xamarin and how it fit into the broader .net ecosystem but they just shot themselves in the foot (both MAUI team and the broader MS dev efforts).
I havent been in that space for a couple years now so maybe they have gotten better, but I doubt that. I appreciate the heroic efforts of the MAUI team, but I think its just the unfortunate reality.
I think it's the same problem that flutter web has, and probably any other canvas/wasm based backend? Those features still need to be implemented, while still missing out on accessibility?
>One issue the demos reveal is, it doesn't _feel_ like the web. That is, I can't hit Ctrl+F to find text on a page. I can't select text with my cursor. I can't copy the address of a hyperlink.
That's because MAUI is intended for mobile and desktop apps.
If you want to use .NET for front-end web SPA, you can use Blazor which will behave exactly like you asked.
1000% - as a dotnet developer with 20 years under my belt, I currently don't see the reasoning behind this. With modern browsers, CSS/JS/HTML does SO much, you just don't have XAML. I like XAML (conceptually), but there is JSX for similar functionality, and it is at least compiled into real HTML, not just a applet.
I felt the same with silverlight as well. Why do we keep trying to reinvent Flash? We already have a far superior C# Flash in Unity compiled for Web (kind of a joke, but also not).
Yeah. I think you need to render to actual DOM nodes when targeting the web if you want a first class experience.
We're betting on this over at https://github.com/DioxusLabs/dioxus where we're building a cross-platform UI solution that enables you to do this by having a web-centric API (we are developing our own custom HTML/CSS renderer for native platforms).
I get the value in this and realize it's not for your polished -$500 ARPU consumer social apps, but man this is weird.
(Also if anyone who worked on it is here, it's crashing for me on OSX 26, Chrome 142.0.7444.135, if I run an animation and hit back as the animation finishes)
The ADL, the left-wing Jewish human rights group not aligned with Musk in the slightest, called out that Musk's gesture was merely an awkward salutation, not a Nazi seig heil[0].
The left wing Jewish human rights group isn't the arbiter of what a nazi salute is. Actual Nazis around the world took it as a nod towards their ideology, and he's desperately trying to start a civil war in the UK, so I would say it walks like a duck and it quacks like a duck.
Seems like a useful resource to help devs understand PWA support across platforms. Thank you!
I help run PWABuilder.com, which packages PWAs for app stores. I think it would be helpful to our users to see your pwascore.com site. Maybe we can link to your site from ours.
Conservative, but definitely not alt-right. Kirk was a strong supporter of Jews and Israel, which put him at odds with the antisemitic alt-right.
Kirk regularly spoke out against antisemitism on both the left and right. So much so, in fact, Israeli Prime Minister tweeted[0] his condolences, praising Kirk as a strong, positive force for Jewish and Christian values.
Cache is super useful for making web apps available offline.
I run a guitar chord chart site[0] that uses cache to enable offline experience; any chord charts you view while online are then available offline thanks to cache. It works pretty great. You service worker intercepts HTTP requests and can first check the cache for cached request/responses.
You know, you could just improve this. All you need to go is find the github link for the article at the bottom of the page, find the edit button, and github will guide you through the rest of the process.
(I've done so myself a few times)
If you prefer you can also clone and make a pull request using standard git tools.
My app works fine online or offline. If you're offline and you ran out of disk space and the cache got evicted, ok, you can't use my web app offline.
(And, if you're out of disk space, all bets are off. You're gonna have other, more significant problems beyond a guitar chord chart site not working offline.)
I work on PWABuilder, Microsoft's open source dev tool that packages PWAs for app stores.
I can say with certainty Apple has been hostile to PWAs.
Unlike Google Play and Microsoft Store, iOS App Store doesn't allow publishing PWAs. (You instead have to build a native web view app to load your PWA.) And many of the PWA features just don't work on mobile Safari.
Looks like it's done using standards-based web components[0]. The page says these components don't require any existing JavaScript framework; because web component support is built-in to the browser.
We use web components at the hook for my company's advertising code but I've found them pretty thoroughly disappointing, personally. They make it simple to trigger code execution but their API isn't really that good
The whole point is to make it simple to trigger code and to be interoperable. Then you write whatever code you want to implement the component.
Web components are not analogous to frameworks because frameworks tightly couple the component interface and lifecycle hooks with the component implementations. Those are properly decoupled in web components and you bring whatever rendering layer you prefer.
Yes but their choice to abandon constructors as a primary part of the lifecycle means that adding some kind of member field to the class will leave it inherently uninitialized in the `connectedCallback`. All fields basically have to be declared as `| undefined` if you're using typescript, which leads to reall ugly code:
class MyComponent extends HTMLElement
{
private width: number | undefined; // must be | undefined or
// you'll get a typescript error
constructor()
{
// useless, unpredictable
}
connectedCallback()
{
this.initAttributes();
// using this.width will still require an undefined check at some point
}
initAttributes()
{
this.width = Number(this.getAttribute('width'));
}
}
If you could reliably load attributes in the constructor instead of being forced to do everything in connectedCallback (or even better, load them automatically with decorators), it would make typescript implementations much cleaner. Just some way to validate attributes before connectedCallback, or work with typescript guarantees would make this much more attractive
The constructor is a part of the lifecycle, and always has been. It wasn't abandoned.
The lifecycle of custom elements reflects the behavior of the HTML parser and DOM APIs. Attributes aren't consistently available in the constructor because the HTML parser is streaming and may yield to the main thread at any time. So the element is constructed first, possibly before attributes are parsed. Attribute also aren't available because when element are constructed imperatively they will never have attributes at first, ie:
// ctor is called, no attributes!
const el = document.createElement('my-element');
// now there will be an attribute:
el.setAttribute('width');
You also shouldn't ever consider attributes to be fixed in a web component, since they may be added and removed at any time, and of course may never be set in the first place. You should implement attributeChangedCallback() and give your element defined behavior for any set of possible attributes.
Or you can use a helper library like Lit which does let you declare and consume your attributes via decorators.
I understand all these things, I think they are weaknesses. They make web components less generally useful, and really only useful for one thing. Constructors are only useful for dependency injection.
This has been soooooooo long in the making, i remember playing with webcomponents for personal stuff years ago when i didn't care about compat. Good to see mainstream libraries finally picking it up
12 years I’ve been saying this… 12, damn, years. React graduates look at me crazy. Angular devs say it’s not needed anyway. Svelte bros say get bent. I’m so happy that someone is paying attention.
You don’t need a shadow dom, you don’t need rerendering of everything when a simple value changes. You simply need web components and scoped js/ts with vite or whatever rollup you use.
I remember toying with Polymer circa 2014, for some reason the word "transclusion" jumps into my mind, I remember being excited about it at the time. I barely remember what it means today though.
Polymer still haunts me to this day. It never made sense. It was literally designed to be deprecated. It's a big nasty polyfill for web components and it had/has a huge perf overhead. Not to mention it's ergonomics are just bad.
On the contrary, the issue is that Harvard allowed pro-Hamas students to attack and persecute Jewish students. Harvard failed to protect the Jewish students, even rewarded those students who intimidated Jewish students on campus. Pro-Hamas students barged into classrooms with bullhorns. Camped out on campus and prevented Jewish students from reaching their classrooms, forming lines and locking hands outside of classrooms to prevent Jews from attending classes.
Harvard recently released a 311-page report detailing these issues[0].
It's for this reason that the federal government is withholding its funding: we don't want to fund open racism and race-based discrimination on American campuses.
> Harvard recently released a 311-page report detailing these issues[0].
Can you be more specific about what was detailed in the report and where? Because the things you mention aren't in your linked article at all.
There were protests that got way too heated, but calling them "pro-Hamas students" has me, uh, doubting your take on this a bit. The highlights called out in your article are wholly different, focused instead on campus behavior that seems drawing back from embracing diversity and is instead alienating whole cultures.
> It's for this reason that the federal government is withholding its funding
We aren't talking about funding, though? We're talking about denying attendance by any international student.
Sure. One example in the opening paragraphs of the report: a Jewish student was set to give a presentation on how his grandfather survived the Holocaust and found refuge in Israel after the war.
He was told not to give the presentation because it would "justify oppression."
The report also details Jewish students were called out in classrooms, told they were oppressors, that their history is a sham, and that anti-racism norms do not apply to supremacists.
Protests on campus pressured Jews to disavow allegiance to Israel and the right of Jews to return to their historic homeland; Zionism. Those who didn't comply were harassed and deemed complicit in supposed crimes of the world's only Jewish state.
Pro-Hamas groups on campus disseminated cartoons of a hand with a star of David holding nooses around the neck of Blacks and Arabs.
After Hamas invaded Israel on October 7th, 33 Harvard student groups praised Hamas and blamed Israel.
Harvard invited commencement speakers who blamed Israel for the genocide in the Congo.
The Harvard page report contains all this and more, and found that over 60% of Jewish students at Harvard had faced discrimination.
One issue the demos reveal is, it doesn't _feel_ like the web. That is, I can't hit Ctrl+F to find text on a page. I can't select text with my cursor. I can't copy the address of a hyperlink. On my phone, I can't hard press on an image and share it to others. Screen readers can't handle it. I can't press a shortcut key to make everything larger.
These all may seem pedantic, but they contribute to the feeling "this is not the real web."
This is the same problem with Java applets in the late '90s, Flash and Silverlight in the early 2000s. They are islands of richness within a web page, but those islands are, well, opaque to browsers, search engines, and virtually all web tooling.
reply