Now that's a fine language for a server. It combines the type safety of Ruby, the memory safety of C, and the terseness of Java.
(I'm joking, mostly... Actually I was a big fan of Obj-C for desktop apps. Fond memories of times when I didn't have to care about servers and ever-changing web frameworks.)
Is there any reason sourcemaps are a genuine problem? I'm out of touch with the JS world, but I wonder if code is shared between server and client and server code may show in sourcemaps.
Some sites want to ship small bundles to the client by default, sourcemaps enables that + you get to introspect it because it's downloaded only when requested. Literally best of both worlds :)
To elaborate on your comment, if you just ship sourcemaps in production, that means you can ship minified code and track down what _actual_ source that you _aren't_ shipping to users is getting called, is in stack traces, etc.
(Not a user, just evaluated it previously. Please correct what I got wrong.) They compile the reactivity statically, so instead of tracking effects at runtime, they generate code for it. I'd guess it means slightly more JS to download, but less initialization in runtime.
However, they recently added runtime reactivity to be more flexible, so it seems to me they are becoming VueJS.
It's pretty clear to me that JavaScript is becoming the de facto standard for UI/UX programming, regardless of platform, and regardless of web vs. native targets. Even GNOME has JavaScript bindings. [0]
The problem is performance... requiring a web browser to draw a UI takes a LOT of CPU and memory, and not all devices have enough power to deliver a smooth experience across all potential workloads.
I worry that every year we keep increasing our processing requirements and bloat without good reason for it.
Why should every Windows release require a faster and faster CPU, and more and more RAM?
The recommended amount of memory for Windows 95 was 8 megabytes, and for Windows 11 it is 8 gigabytes. Why is this not horrifying?
My small Linux system with openbox GUI barely cracks 100MB memory usage in 2025.
> What makes a browser so much more inefficient vs. other UI frameworks?
The fact that each app carries their own copy of the browser engine.
Teams, Chrome, Steam - that's at least three Chromium engine embeds that all take up hundreds of megabytes each. Not to mention Steam is in the background and has no windows visible, and yet it has the Chromium helper processes gobbling up RAM. WTF is this shit.
Life used to be easier in the Windows 98 days with OCX, you just dragged a webview in the VB6 application designer and that was it, and IIRC it was even possible to embed Firefox in the same way for a while...
What makes the browser slow and inefficient is the fact that it's not a UI framework. It's a system to display text and a couple of images on a 2D plane where every element depends on every other element.
Almost every single interaction and change requires the browser to recalculate the layout of the entire page and to redraw it. It's basically Microsoft Word, with nearly the same behaviors.
And there are no proper ways to prevent that behaviour. No lower and low level control over rendering. Awkward workarounds and hacks that browsers employ to try and minimize re-layouting and redrawing. Great rejoicing when introducing yet more hacks for basic things: https://developer.chrome.com/docs/css-ui/animate-to-height-a... etc.
In none of them text is primary and all other incidental?
> What UI frameworks don't do this?
In which UI framework actions like "set focus on an element" triggers a full page re-layout?
Also, in which UI framework there's even a discussion of "try to not trigger re-paint/re-flow"?
And yes, I know about immediate mode UI where the entire layout is re-calculated every frame. But then they can usually render thousands of elements at 60fps.
> Why should every Windows release require a faster and faster CPU, and more and more RAM?
I don't know. But does it? It doesn't seem like you verified that yourself - you're comparing stated recommended specs of Windows to actual usage of Linux.
Have you used other ones? Not a dig, I've primarily used HTML/CSS for UIs and have been playing around with Compose recently and haven't made up my mind what I like more.
GNOME has its own interpreter, kinda how React Native does it for mobile. But performance all boils down to the layout engine. Most native UI components take shortcuts with text which is the most difficult thing to render. And the widget tree is simpler.
And there’s the whole inspector in web browser, meaning that the layout is not done once and forget. There’s various sub components still present for whatever features. Great in the browser, not great for standalone apps.
A choice of tech stack can never be enough to prove anything. It only establishes a lower bound on resource usage, but there is never and upper bound as long as while() and malloc() are available.
Dumb question but Apple’s apps are buttery smooth. I just assumed they were using swift and not a web stack to render their UI. Am I completely wrong?!
Apple Music is not buttery smooth and was just a web view for a long time. I feel like I read that this changed a few years ago. This didn’t change the fact that it’s very slow.
There's also some parts of System Settings that were always web views, which I always found surprising for a company trying to make the case for native apps.
Unsurprisingly there are many frameworks/initiatives that end up falling by the wayside over the years, e.g. MacRuby was being lined up to supersede Objective-C for app development at one point.
In case you want to save sources with the ability to fetch all possible lazy chunks, last year I made a tool to do exactly that:
https://github.com/zb3/getfrontend
(note it won't work on apps.apple.com because apple has removed these sourcemaps)
Honestly the site[1] is very basic and pretty damn slow. When I click into a different category there is a noticeable delay of 1-2 seconds before the new page loads. I don't want to replicate this in any of my own projects.
That's what this type of SPA architecture leads to unfortunately. Routers should immediately display the navigated to route with place holder content / skeletons, but instead all the frameworks basically wait for all the data to load before transitioning. You can technically stream the data in but even a single awaited promise will block the navigation until it succeeds. And it's not an issue that shows up in dev because typically the data loading is instant.
The flashes signify actual changes. It's a secondary signal to resume paying attention to the page.
What I truly hate are animated skeleton boxes or element level spinners. Why are you trying to hold my attention on something that's not even loaded yet? We all understand the UI paradigm and implicitly understand network delay, you don't need "comfort animations" to keep me happy. I'd rather use the time to look at any of the other tabs or applications across my screens. Then the flash of content actually means something.
The point of skeleton loaders is to prevent the page from jumping around furiously, which would force the user to re-parse the layout (possibly) multiple times.
In my experience it's just amateur UI design that causes this. Your display areas shouldn't change size unless the browser changes size. There should be nothing that is "content fitted." That's a historical mistake of early HTML but it's something easily overcome. You really do have to get the HTML+CSS to work like a desktop app before you layout your SPA.
Worse still, applications like microsoft outlook on the web, use the skeleton boxes with comfort animations. What they don't do is pre layout their icons. And different icons will appear in different contexts. I often get the case where I aim for one icon, something will load in, create a new icon, and push my intended target out of the click.
Skeleton loaders are a bad kludge over an initially ignored problem.
Which is fine. Nothingness, or a generic spinner actually don't lie to me.
Skeletons lie by making an impression that the data is just about ready. So there's this failure mode where data is NOT ready because of a slow app/network, and I end up staring at a fake. Even worse, sometimes skeletons also break scrolling, so you end up even more frustrated because your controls don't work.
It far and away beats the alternative which is clicking on a link and nothing happening. Feedback should be within a frame or two of latency, not seconds...
The web version of the App Store? It's always been web and webview based, there used to be a preferences/default command to enable web inspector for App store, Music and more Apple apps on MacOS.
https://en.wikipedia.org/wiki/WebObjects
Now that's a fine language for a server. It combines the type safety of Ruby, the memory safety of C, and the terseness of Java.
(I'm joking, mostly... Actually I was a big fan of Obj-C for desktop apps. Fond memories of times when I didn't have to care about servers and ever-changing web frameworks.)
And amusing to myself how many people actually remember or know what WebObjects was!
The same with everything called "XSan" and "Mac OS X Server". I don't know what any of it was, but the box art was always so cool.
Here's the original post by the author of the repo himself: https://old.reddit.com/r/webdev/comments/1onnzlj/app_store_w...
The pattern itself is a little bit different, has some conceptual overhead, but it's also fairly clean and scaleable.
a lot of people learned to code on the web via viewsource - now we are obfuscating the code
To elaborate on your comment, if you just ship sourcemaps in production, that means you can ship minified code and track down what _actual_ source that you _aren't_ shipping to users is getting called, is in stack traces, etc.
I'm not aware of a point of sourcemaps otherwise.
Was it, HTML, CSS & Javascript?
And the "leak" is fun for me because you can see how they write their components haha
However, they recently added runtime reactivity to be more flexible, so it seems to me they are becoming VueJS.
Same goes for most modern frameworks (Solid, Vue, Preact) and even old ones experiencing a renaissance like Angular.
[0]: https://gjs.guide/
I worry that every year we keep increasing our processing requirements and bloat without good reason for it.
Why should every Windows release require a faster and faster CPU, and more and more RAM?
The recommended amount of memory for Windows 95 was 8 megabytes, and for Windows 11 it is 8 gigabytes. Why is this not horrifying?
My small Linux system with openbox GUI barely cracks 100MB memory usage in 2025.
What makes a browser so much more inefficient vs. other UI frameworks? Is it really the browser's fault or the website's you're visiting?
The fact that each app carries their own copy of the browser engine.
Teams, Chrome, Steam - that's at least three Chromium engine embeds that all take up hundreds of megabytes each. Not to mention Steam is in the background and has no windows visible, and yet it has the Chromium helper processes gobbling up RAM. WTF is this shit.
Life used to be easier in the Windows 98 days with OCX, you just dragged a webview in the VB6 application designer and that was it, and IIRC it was even possible to embed Firefox in the same way for a while...
Almost every single interaction and change requires the browser to recalculate the layout of the entire page and to redraw it. It's basically Microsoft Word, with nearly the same behaviors.
And there are no proper ways to prevent that behaviour. No lower and low level control over rendering. Awkward workarounds and hacks that browsers employ to try and minimize re-layouting and redrawing. Great rejoicing when introducing yet more hacks for basic things: https://developer.chrome.com/docs/css-ui/animate-to-height-a... etc.
And how is that different from a UI framework?
> Almost every single interaction and change requires the browser to recalculate the layout of the entire page and to redraw it.
What UI frameworks don't do this?
In none of them text is primary and all other incidental?
> What UI frameworks don't do this?
In which UI framework actions like "set focus on an element" triggers a full page re-layout?
Also, in which UI framework there's even a discussion of "try to not trigger re-paint/re-flow"?
And yes, I know about immediate mode UI where the entire layout is re-calculated every frame. But then they can usually render thousands of elements at 60fps.
Here's a deeper dive. It's about animations, but it explains issues in a nice way that "even ChatGPT" can understand: https://motion.dev/blog/web-animation-performance-tier-list
I don't know. But does it? It doesn't seem like you verified that yourself - you're comparing stated recommended specs of Windows to actual usage of Linux.
js? get that thing off of me
[0]: https://en.wikipedia.org/wiki/Jeff_Atwood
And there’s the whole inspector in web browser, meaning that the layout is not done once and forget. There’s various sub components still present for whatever features. Great in the browser, not great for standalone apps.
A choice of tech stack can never be enough to prove anything. It only establishes a lower bound on resource usage, but there is never and upper bound as long as while() and malloc() are available.
(Except maybe the "Home"/"For Me" pages which are just "discovery page" extensions of the store and the Apple Music service that's built on top of it)
The macOS one descends from iTunes and the iOS one descends from the original iPhone which sure as hell wasn't a webview.
There's also some parts of System Settings that were always web views, which I always found surprising for a company trying to make the case for native apps.
(note it won't work on apps.apple.com because apple has removed these sourcemaps)
1: https://apps.apple.com/
Have you tried visiting the site on a worse machine?
They try to create a _perception_ of a quick answer while adding overhead and distracting people.
What I truly hate are animated skeleton boxes or element level spinners. Why are you trying to hold my attention on something that's not even loaded yet? We all understand the UI paradigm and implicitly understand network delay, you don't need "comfort animations" to keep me happy. I'd rather use the time to look at any of the other tabs or applications across my screens. Then the flash of content actually means something.
Worse still, applications like microsoft outlook on the web, use the skeleton boxes with comfort animations. What they don't do is pre layout their icons. And different icons will appear in different contexts. I often get the case where I aim for one icon, something will load in, create a new icon, and push my intended target out of the click.
Skeleton loaders are a bad kludge over an initially ignored problem.
Personally I prefer to wait than having multiple flashes of content but I do agree no approach is perfect.
Skeletons lie by making an impression that the data is just about ready. So there's this failure mode where data is NOT ready because of a slow app/network, and I end up staring at a fake. Even worse, sometimes skeletons also break scrolling, so you end up even more frustrated because your controls don't work.
Curious if it was done intentionally or simply due to hurrying.