Java has it's place but it was delivered in such a way that it created an immense amount of collateral damage and lasting technical debt.
pavlov 3 days ago [-]
WebObjects was originally written in Objective-C.
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.)
firecall 3 days ago [-]
I was kinda trying being funny or sarcastic or something like that :-)
And amusing to myself how many people actually remember or know what WebObjects was!
karel-3d 3 days ago [-]
All I know about is it the great box art. It always looked so cool and mysterious to me as a young developer.
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.
dzonga 5 days ago [-]
sourcemaps should be enabled -- that's how people learn.
a lot of people learned to code on the web via viewsource - now we are obfuscating the code
zerr 3 days ago [-]
Probably due to usage of fat front end frameworks which also include whole business logics.
namegulf 3 days ago [-]
sourcemaps are not for learning, it's for debugging
embedding-shape 3 days ago [-]
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 :)
samdoesnothing 3 days ago [-]
I love shipping source maps for my stuff bc it lets other developers take a peek and I love doing that with other peoples sites :)
samtheprogram 3 days ago [-]
Idk why you are getting downvoted.
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.
silverwind 3 days ago [-]
Yep, sourcemaps are essential to get usable error stack traces, and that's their only purpose.
As a frequent user of the backend (Connect), I am skeptical that this is source that you want to reproduce (unless you're a scammer).
numpy-thagoras 3 days ago [-]
The source code had a very elegant and systematic use of intents (including prefetched intents) and a dependency injection container.
The pattern itself is a little bit different, has some conceptual overhead, but it's also fairly clean and scaleable.
ChrisMarshallNY 2 days ago [-]
Yeah, it was a bit of a joke.
I’ve been staring at Apple source code (the stuff they let The Great Unwashed see), for almost forty years.
It’s always been very polished, well-structured, well-documented, succinct, and beautifully written.
It’s been an inspiration for my own work. I have always striven to emulate them.
That’s why it’s so shocking for me to encounter the terrible quality of the Connect backend. It’s quite painful, and disappointing.
JimDabell 2 days ago [-]
I remain convinced App Store Connect is the project they put interns on. It also explains why they keep redesigning / reimplementing it, then losing interest and leaving it part-finished and incoherent. It’s because the interns working on it go back to school.
aitchnyu 3 days ago [-]
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.
dominicrose 2 days ago [-]
If obfuscating code is a necessity then sourcemaps are a necessity as well, they should just not be available in production.
madeofpalk 2 days ago [-]
That's if your goal is to obfuscate code.
Often though, Javascript is hard to read not because it's been obfuscated, but because its been transpiled and/or minified for smaller network payloads.
I can understand why some don't want to ship their sourcemaps to prod, but also it really doesn't matter all that much.
dominicrose 1 days ago [-]
If your goal isn't to obfuscate code as you said you still need to do some kind of transformation so sourcemaps are necessary.
It's possible to debug code that's been converted from ES2025 to ES3 without them but it's really annoying to have to do that.
Let's be honest, when a company makes a website they want you to see the website not the code. Of course front-end code is less private in nature but still, showing it could expose some vulnerabilities.
prmoustache 2 days ago [-]
When can it be a necessity?
paulddraper 3 days ago [-]
I remember when all websites “exposed” their source code.
johanbcn 2 days ago [-]
And some webmasters were pretty keen on interfering with the context menu and your shortcut keys in order to prevent you to see it (and failing).
> It exposes all your frontend source code for everyone. If you don't want to open source your frontend, you might want to remove those source maps from public access.
I wonder how much difference LLMs today have on being able to turn minified JS into something easily readable? JSNice already worked pretty well and I guess that was comparatively naive. You won't really stop anyone motivated to reverse-engineer it by not providing source maps, but you'll definitely stop at least some curious people from understanding how websites work. Your frontend also doesn't suddenly turn "open source" just because you shared the original source via source maps, that part sounds kind of FUD.
lanyard-textile 2 days ago [-]
Oof! You certainly did, I remember reading this and not thinking that much of it at the time.
paulddraper 2 days ago [-]
What’s the issue?
namegulf 3 days ago [-]
Still not sure What was the excitement about.
Was it, HTML, CSS & Javascript?
Yaina 3 days ago [-]
It's written in Svelte, which personally I'm excited about just because it means that a pretty big tech company is using it :)
And the "leak" is fun for me because you can see how they write their components haha
icar 3 days ago [-]
Apple Music web is written in Svelte as well. At least last time I checked.
tbolt 2 days ago [-]
Last I checked it was Ember. That was several years ago though.
qn9n 2 days ago [-]
They updated Podcasts and Music to Svelte in the last couple of years.
arvinsim 3 days ago [-]
Can you tell me what is the number 1 feature that Svelte has over the incumbents like React?
scosman 2 days ago [-]
Not so much features as design.
Svelte files look like HTML+TS files. You aren’t learning some abstraction to HTML, you are just using HTML. But it adds the modern bits you need: reactivity, loops, components, routing, etc. Nothing react doesn’t have, but the devex is great.
Other benefits:
- your app is compiled. You don’t ship the framework to clients, they just get a minimal compiled app.
- The rendering modes are pretty great. Any page can be server side rendered, or client side, with per page flags. You also can easily setup SSR for the first page, and CSR for later pages - both the fastest option. It will even pre-fetch the next page when you hover a link, making most nav instant.
troupo 3 days ago [-]
Radically simpler reactivity that doesn't require 20 different hooks to do the same thing.
Same goes for most modern frameworks (Solid, Vue, Preact) and even old ones experiencing a renaissance like Angular.
flowerthoughts 3 days ago [-]
(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.
no_wizard 3 days ago [-]
I wonder what the heck @jet is. Never heard of that before. Must be an internal lib?
p0w3n3d 3 days ago [-]
How DMCA can take down code that was published in the web?
scosman 2 days ago [-]
Copyrighted content is copyrighted content. It doesn’t matter if/how Apple published it, others don’t have a right to redistribute it without a license.
plq 3 days ago [-]
The (non-existing) license doesn't say it was to be "published in the web"
zb3 3 days ago [-]
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)
OCTAGRAM 4 days ago [-]
There was Cappucino by ex-Apple employees, and actual Apple devs had SproutCore. So where did they go? Why some unknown libraries?
afavour 3 days ago [-]
It's using Svelte, I wouldn't exactly call that unknown. Why maintain your own library when a third party one does exactly what you need?
frou_dh 3 days ago [-]
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.
stephen_g 2 days ago [-]
Didn’t SproutCore become Ember [1]? Just my vague recollection, not sure if that was the case though. Anyway, Ember is still used and maintained, despite not being very well known.
I don't know if it's still true, but Apple Music was indeed Ember at a point.
andoando 5 days ago [-]
App store uses svelte? :o
zote 5 days ago [-]
Apple Music uses Svelte too
wiseowise 3 days ago [-]
Apple Music desktop “app” is a crime against humanity.
qn9n 3 days ago [-]
And Apple Podcasts
theshrike79 3 days ago [-]
Waiting for the Fireship video :)
silverwind 3 days ago [-]
And MacOS Settings uses react.
sunaookami 3 days ago [-]
Only for the iCloud webviews, not for the whole settings app.
ranger_danger 3 days ago [-]
And the Windows 11 start menu is just React Native. Strange times indeed.
dlivingston 3 days ago [-]
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]
Personally I love it. HTML/CSS is still the best, most well documented and familiar gui framework
ranger_danger 3 days ago [-]
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.
Rohansi 3 days ago [-]
> requiring a web browser to draw a UI takes a LOT of CPU and memory
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?
troupo 3 days ago [-]
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.
Rohansi 2 days ago [-]
> It's a system to display text and a couple of images on a 2D plane
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?
troupo 2 days ago [-]
> And how is that different from a UI framework?
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.
Rohansi 2 days ago [-]
> In none of them text is primary and all other incidental?
This is a pretty outdated way of thinking. If we were only speaking about (old) HTML then maybe. But these days HTML and CSS are basically inseparable and go far beyond "text is primary".
> In which UI framework actions like "set focus on an element" triggers a full page re-layout?
I don't see why a browser would need to re-layout for just a focus change. Unless, of course, the CSS changes require a re-layout after the focus has changed (`:focus` selector).
Every UI framework can run into performance issues with layout and/or painting if they're complex enough (or poorly made). There is fundamentally very few differences between HTML+CSS and other UI frameworks.
troupo 1 days ago [-]
> But these days HTML and CSS are basically inseparable and go far beyond "text is primary".
That "inseparable" is building on top of a bunch of legacy cruft, hacks and workarounds for a system that is stilm barely suitable to layout some simple text.
Just because CSS is there it doesn't make the browser a UI framework.
> I don't see why a browser would need to re-layout for just a focus change.
Indeed. No one does. And yet you'd be surprised: https://gist.github.com/paulirish/5d52fb081b3570c81e3a (note: unfortunately there's no up-to-date list as some of these issues are fixed in all or some engines, and a bunch of other gotchas are introduced).
> There is fundamentally very few differences between HTML+CSS and other UI frameworks.
Lol. There's almost no other UI framework that struggles with as many trivial performance issues as HTML + CSS [1]. No other UI framework has so many gotchas and issues with even the simplest layouts and animations. No other UI framework has warnings of "you have 800 nodes, it's too big, and will cause issues". No other UI framework has so few ways of telling the framework "delay painting" or "I will take over painting" or "do these paints in batches" or...
> 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...
Rohansi 2 days ago [-]
> The fact that each app carries their own copy of the browser engine.
This has nothing to do with the browser itself. Ideally everything would use the same browser instead of shipping their own. On Windows it's already possible with WebView2 but developers need to choose to go that route. Teams should already be using it.
3 days ago [-]
shooly 3 days ago [-]
> 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.
edoceo 3 days ago [-]
There are slim webviews, that can do core HTML and CSS, make a nice UI and not chew all the RAM.
ranger_danger 2 days ago [-]
Could you provide some examples?
samdoesnothing 3 days ago [-]
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.
nish__ 3 days ago [-]
Same here. I've grown to really love Jetpack Compose. Personally, I'd say I like it better than any other framework I've tried before.
NooneAtAll3 3 days ago [-]
html/css yes
js? get that thing off of me
ranger_danger 3 days ago [-]
From what I have seen, most of the current GNOME UI is in fact just javascript. And any plugins people write for it are also javascript.
skydhash 2 days ago [-]
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.
ConfuSomu 1 days ago [-]
Same thing with KDE Plasma and its UIs being written in QML, which allows better separation of business logic (written in C++) and graphical interface (QML Javascript).
It confirms that indeed React Native is used, and not React.js/WebView, in case someone got confused.
010101010101 2 days ago [-]
It's used for a specific component in the start menu, it doesn't power the entire start menu.
hebelehubele 3 days ago [-]
What the fuck. Does that mean alternative start menus (e.g. Stardock Start11) are provably faster & lighter on resources?
Chabsff 3 days ago [-]
Not by virtue of that alone.
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.
burntice 3 days ago [-]
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?!
cyral 3 days ago [-]
This is the source for the web version of the app store
elpakal 3 days ago [-]
which is definitely not buttery smooth, I use it every day
jen729w 2 days ago [-]
It only came out yesterday.
elpakal 2 days ago [-]
App Store Connect did not come out yesterday
bl0rg 2 days ago [-]
I see no contradiction here.
socalgal2 3 days ago [-]
which is the same as they use in their native app. It's just a webview
javawizard 3 days ago [-]
Source?
dewey 3 days ago [-]
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.
lloeki 3 days ago [-]
The iTunes Store, which was embedded in iTunes, sure was a webview, but I don't think Apple Music ever was a webview?
(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.
lapcat 3 days ago [-]
I downloaded the code from the repository yesterday, but it's really not very interesting.
5 days ago [-]
zb3 3 days ago [-]
Damn, I was about to clone this but it's now taken down :(
“GitHub processed the takedown notice against the entire network of 8,270 repositories, inclusive of the parent repository“
m4rtink 2 days ago [-]
Is that a problem if the design is good & secrets did not leek as well ? :)
AbstractH24 5 days ago [-]
Just came here to post this.
Curious if it was done intentionally or simply due to hurrying.
rxliuli 5 days ago [-]
It appears to have been an accident now - they fixed the issue two hours after I posted on Reddit.
AbstractH24 4 days ago [-]
Curious if you get any sort of takedown notice.
accmade4post 3 days ago [-]
the page is dmca unavailable on github now as i write this message
rxliuli 4 days ago [-]
Haven't received it yet.
isodev 4 days ago [-]
It's not a bug! Websites are supposed to have human-readable markup and scripts.
efilife 2 days ago [-]
the sourcemap has been removed and repos DMCAd
phillipseamore 5 days ago [-]
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.
galad87 2 days ago [-]
Nowadays it's all AppKit/UIKit/SwiftUI. It's no longer a webview.
wackget 3 days ago [-]
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.
Just checked, and it's pretty snappy... under Firefox... on 10-year old hardware... that was originally a Chromebook.
Have you tried visiting the site on a worse machine?
3 days ago [-]
3 days ago [-]
conradfr 2 days ago [-]
I don't know, there's an annoying (constant) delay when you click on anything.
prmoustache 2 days ago [-]
Did they consult with Atlassian to build this?
DecoySalamander 2 days ago [-]
I wanted to write, 'They have to load the entire catalogue for a category, including all the images. What did you expect?' However, having looked into it a bit more, it seems that they didn't particularly care about optimising load times.
samdoesnothing 3 days ago [-]
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.
cyberax 3 days ago [-]
Nope. Skeletons are the worst. Down with the necromancy!
They try to create a _perception_ of a quick answer while adding overhead and distracting people.
bastawhiz 3 days ago [-]
Skeletons are a loading state. Get rid of skeletons and you either have unresponsiveness or flashes of nothingness
themafia 3 days ago [-]
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.
shooly 3 days ago [-]
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.
themafia 2 days ago [-]
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.
bastawhiz 2 days ago [-]
> The flashes signify actual changes
The loading state is indistinguishable from the page crashing. Did the JavaScript fail, or is the connection just slow?
> animated skeleton boxes or element level spinners
Good news! Browsers have low motion settings. Any programmer worth their salt will respect this and the skeletons won't be animated.
> Then the flash of content actually means something.
On the contrary, if the content is loaded in multiple parts (in my own application, I split the loading into multiple requests: one is cacheable across multiple pages, one is cheap, one is expensive), you either need to not render anything until everything is loaded (bad: the user can't interact with the parts that loaded first), or the page jumps around as content loads in. Skeletons fix this. UI elements in the middle don't end up being 0px tall and moving the stuff below them around nearly as much. How annoying is it to nearly click on something and the page jumps violently and you mis-click?
It honestly sounds like you just don't like lazy programming. That's very fair. Skeletons done right just mean the page is the correct layout while they're partially loaded. Without that, the content is literally unusable (you can't read it interact with things that are jumping all over the place).
pier25 3 days ago [-]
Either you wait to get all the data to display the new UI, you show spinners, or you show skeletons.
Personally I prefer to wait than having multiple flashes of content but I do agree no approach is perfect.
cyberax 3 days ago [-]
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.
bastawhiz 2 days ago [-]
1. You load nothing, and the page is broken and unusable. A slow network means you see a header and a footer smooshed together.
2. You show a spinner, which is functionally equivalent to a spinner
3. You wait until the content is loaded and the page feels completely broken, because nothing is happening until it's loaded.
> sometimes skeletons also break scrolling, so you end up even more frustrated because your controls don't work.
This is just lazy programming. The skeleton should be the minimum height of the content it will be replaced by.
cyberax 2 days ago [-]
Again, I don't see any upsides for me compared to a blank page. Skeletons in the best case just show a useless intermediate state, and in the worst case just force me to pay attention to a non-functional page for an indefinite amount of time.
A blank page does not try to keep grabbing my attention.
Skeletons also have a toxic effect on web developers by letting them get sloppier.
eviks 3 days ago [-]
It's not a perception if partial load shows some information faster than waiting for the full load
samdoesnothing 3 days ago [-]
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...
kid64 3 days ago [-]
That's not the only alternative, there are a range of options between those extremes.
halapro 3 days ago [-]
If you let the browser change page, then you do have feedback. Super native.
T3RMINATED 2 days ago [-]
[dead]
nacozarina 3 days ago [-]
hilarious —- great score !
danesparza 2 days ago [-]
A DMCA takedown is inappropriate, as no copyright was circumvented. It was freely distributed (albeit briefly) on Apple's own website. A DMCA takedown at this point is entrapment: https://en.wikipedia.org/wiki/Entrapment.
JimDabell 2 days ago [-]
That is not how copyright nor entrapment work. Somebody putting something on their website does not grant anybody a license to distribute copies. Filing a DMCA takedown is not entrapment.
Rendered at 20:24:08 GMT+0000 (Coordinated Universal Time) with Vercel.
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.
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.
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.
I’ve been staring at Apple source code (the stuff they let The Great Unwashed see), for almost forty years.
It’s always been very polished, well-structured, well-documented, succinct, and beautifully written.
It’s been an inspiration for my own work. I have always striven to emulate them.
That’s why it’s so shocking for me to encounter the terrible quality of the Connect backend. It’s quite painful, and disappointing.
Often though, Javascript is hard to read not because it's been obfuscated, but because its been transpiled and/or minified for smaller network payloads.
I can understand why some don't want to ship their sourcemaps to prod, but also it really doesn't matter all that much.
Let's be honest, when a company makes a website they want you to see the website not the code. Of course front-end code is less private in nature but still, showing it could expose some vulnerabilities.
This issue is very wide-spread.
I wonder how much difference LLMs today have on being able to turn minified JS into something easily readable? JSNice already worked pretty well and I guess that was comparatively naive. You won't really stop anyone motivated to reverse-engineer it by not providing source maps, but you'll definitely stop at least some curious people from understanding how websites work. Your frontend also doesn't suddenly turn "open source" just because you shared the original source via source maps, that part sounds kind of FUD.
Was it, HTML, CSS & Javascript?
And the "leak" is fun for me because you can see how they write their components haha
Svelte files look like HTML+TS files. You aren’t learning some abstraction to HTML, you are just using HTML. But it adds the modern bits you need: reactivity, loops, components, routing, etc. Nothing react doesn’t have, but the devex is great.
Other benefits:
- your app is compiled. You don’t ship the framework to clients, they just get a minimal compiled app.
- The rendering modes are pretty great. Any page can be server side rendered, or client side, with per page flags. You also can easily setup SSR for the first page, and CSR for later pages - both the fastest option. It will even pre-fetch the next page when you hover a link, making most nav instant.
Same goes for most modern frameworks (Solid, Vue, Preact) and even old ones experiencing a renaissance like Angular.
However, they recently added runtime reactivity to be more flexible, so it seems to me they are becoming VueJS.
(note it won't work on apps.apple.com because apple has removed these sourcemaps)
1. https://emberjs.com/
[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?
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.
This is a pretty outdated way of thinking. If we were only speaking about (old) HTML then maybe. But these days HTML and CSS are basically inseparable and go far beyond "text is primary".
> In which UI framework actions like "set focus on an element" triggers a full page re-layout?
I don't see why a browser would need to re-layout for just a focus change. Unless, of course, the CSS changes require a re-layout after the focus has changed (`:focus` selector).
Every UI framework can run into performance issues with layout and/or painting if they're complex enough (or poorly made). There is fundamentally very few differences between HTML+CSS and other UI frameworks.
That "inseparable" is building on top of a bunch of legacy cruft, hacks and workarounds for a system that is stilm barely suitable to layout some simple text.
Just because CSS is there it doesn't make the browser a UI framework.
> I don't see why a browser would need to re-layout for just a focus change.
Indeed. No one does. And yet you'd be surprised: https://gist.github.com/paulirish/5d52fb081b3570c81e3a (note: unfortunately there's no up-to-date list as some of these issues are fixed in all or some engines, and a bunch of other gotchas are introduced).
> There is fundamentally very few differences between HTML+CSS and other UI frameworks.
Lol. There's almost no other UI framework that struggles with as many trivial performance issues as HTML + CSS [1]. No other UI framework has so many gotchas and issues with even the simplest layouts and animations. No other UI framework has warnings of "you have 800 nodes, it's too big, and will cause issues". No other UI framework has so few ways of telling the framework "delay painting" or "I will take over painting" or "do these paints in batches" or...
Etc. etc.
[1] A good article that dives into just the animation side of things https://motion.dev/blog/web-animation-performance-tier-list
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
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...
This has nothing to do with the browser itself. Ideally everything would use the same browser instead of shipping their own. On Windows it's already possible with WebView2 but developers need to choose to go that route. Teams should already be using it.
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
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.
[0]: https://en.wikipedia.org/wiki/Jeff_Atwood
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.
Curious if it was done intentionally or simply due to hurrying.
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.
The loading state is indistinguishable from the page crashing. Did the JavaScript fail, or is the connection just slow?
> animated skeleton boxes or element level spinners
Good news! Browsers have low motion settings. Any programmer worth their salt will respect this and the skeletons won't be animated.
> Then the flash of content actually means something.
On the contrary, if the content is loaded in multiple parts (in my own application, I split the loading into multiple requests: one is cacheable across multiple pages, one is cheap, one is expensive), you either need to not render anything until everything is loaded (bad: the user can't interact with the parts that loaded first), or the page jumps around as content loads in. Skeletons fix this. UI elements in the middle don't end up being 0px tall and moving the stuff below them around nearly as much. How annoying is it to nearly click on something and the page jumps violently and you mis-click?
It honestly sounds like you just don't like lazy programming. That's very fair. Skeletons done right just mean the page is the correct layout while they're partially loaded. Without that, the content is literally unusable (you can't read it interact with things that are jumping all over the place).
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.
2. You show a spinner, which is functionally equivalent to a spinner
3. You wait until the content is loaded and the page feels completely broken, because nothing is happening until it's loaded.
> sometimes skeletons also break scrolling, so you end up even more frustrated because your controls don't work.
This is just lazy programming. The skeleton should be the minimum height of the content it will be replaced by.
A blank page does not try to keep grabbing my attention.
Skeletons also have a toxic effect on web developers by letting them get sloppier.