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.)
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.
> 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.
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.
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.
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.
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.
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.
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.
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]
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)
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.
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.
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.
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.
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.
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.
You mean it's no longer built with WebObjects!
https://en.wikipedia.org/wiki/WebObjects
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.
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.)
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!
1 reply →
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
Probably due to usage of fat front end frameworks which also include whole business logics.
sourcemaps are not for learning, it's for debugging
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 :)
1 reply →
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.
Yep, sourcemaps are essential to get usable error stack traces, and that's their only purpose.
Told ya: https://news.ycombinator.com/item?id=30337690
This issue is very wide-spread.
Oof! You certainly did, I remember reading this and not thinking that much of it at the time.
> 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.
What’s the issue?
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.
If obfuscating code is a necessity then sourcemaps are a necessity as well, they should just not be available in production.
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.
When can it be a necessity?
OP here..
Here's the original post by the author of the repo himself: https://old.reddit.com/r/webdev/comments/1onnzlj/app_store_w...
The github link in the reddit post is taken by DMCA
Yes, but the full source code was archived here: https://archive.softwareheritage.org/browse/origin/directory...
1 reply →
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).
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.
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.
1 reply →
Still not sure What was the excitement about.
Was it, HTML, CSS & Javascript?
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
Apple Music web is written in Svelte as well. At least last time I checked.
2 replies →
Can you tell me what is the number 1 feature that Svelte has over the incumbents like React?
3 replies →
I wonder what the heck @jet is. Never heard of that before. Must be an internal lib?
I remember when all websites “exposed” their source code.
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).
How DMCA can take down code that was published in the web?
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.
The (non-existing) license doesn't say it was to be "published in the web"
There was Cappucino by ex-Apple employees, and actual Apple devs had SproutCore. So where did they go? Why some unknown libraries?
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?
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.
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.
1. https://emberjs.com/
I don't know if it's still true, but Apple Music was indeed Ember at a point.
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?!
This is the source for the web version of the app store
which is definitely not buttery smooth, I use it every day
3 replies →
which is the same as they use in their native app. It's just a webview
1 reply →
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.
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.
1 reply →
App store uses svelte? :o
Apple Music uses Svelte too
Apple Music desktop “app” is a crime against humanity.
And Apple Podcasts
Waiting for the Fireship video :)
And MacOS Settings uses react.
Only for the iCloud webviews, not for the whole settings app.
And the Windows 11 start menu is just React Native. Strange times indeed.
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]
[0]: https://gjs.guide/
22 replies →
This was a false rumor: https://news.ycombinator.com/item?id=44124688
2 replies →
What the fuck. Does that mean alternative start menus (e.g. Stardock Start11) are provably faster & lighter on resources?
1 reply →
Is that a problem if the design is good & secrets did not leek as well ? :)
I downloaded the code from the repository yesterday, but it's really not very interesting.
Damn, I was about to clone this but it's now taken down :(
https://archive.softwareheritage.org/browse/origin/directory...
LOVE U!
1 reply →
“GitHub processed the takedown notice against the entire network of 8,270 repositories, inclusive of the parent repository“
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)
Just came here to post this.
Curious if it was done intentionally or simply due to hurrying.
It appears to have been an accident now - they fixed the issue two hours after I posted on Reddit.
Curious if you get any sort of takedown notice.
2 replies →
It's not a bug! Websites are supposed to have human-readable markup and scripts.
the sourcemap has been removed and repos DMCAd
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.
Nowadays it's all AppKit/UIKit/SwiftUI. It's no longer a webview.
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.
1: https://apps.apple.com/
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?
I don't know, there's an annoying (constant) delay when you click on anything.
1 reply →
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.
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.
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.
13 replies →
[dead]
hilarious —- great score !
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.
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.