tolmasky

I am in basic agreement with everyone that the core app sucks. It just means that I use Reddit less in general instead of going out of my way to fix their problem for them by finding an app that works. That is another failure case that isn't really considered: there's a bunch of opportunity cost just in people who have a bad experience and then switch to YouTube or whatever.

1. Scroll down to "Girard's Paradox" here: https://en.wikipedia.org/wiki/System_U

Any sort of document-based app benefits tremendously from tabs, and thus it would be unfortunate to have to lose that feature when making it a Web App. I for example often need a couple Google Docs open at once. I would very much like to have Google Docs as a separate item in my Dock though. However, I don't want to be forced to have each individual Google Document in a separate window like it's Mac OS 9 just because it's a "Web App".

Or for example Airtable. I have a few Airtables that I basically always have open. I currently have them "pinned" just because if not they become impossible to find in the sea of other windows and tabs in my browser. I would love to command-tab to Airtable and bring these up, but not have them in an overlapping mess of windows.

Another great example is social media "Web Apps" (like Elk for Mastodon), which basically get "stacks" for free by leveraging tabs. Instead of the Elk team having to develop an "internal tabbing" feature, I can just have a tab for each hashtag I am following. But this does not mean that I want all these tabs mixed in with random other unrelated websites.

Literally any app (vs. "page") that uses multiple windows that you would personally prefer to group into tabs is a good candidate. Tabs are a window organizational tool, they have no inherent "webness" to them aside from that being the first place they originated. macOS's AppKit framework has built-in support for automatically making document-based apps support tabs with zero additional programming. I assure you this feature wasn't added in to allow anyone to write a web browser. In fact, I think the opposite of your assertion is true: the more like an "app" the thing you're turning into a Web App is, the more likely it is to use multiple windows, and thus the more it can benefit from tabs. I agree that if you are for some strange reason turning a blog into a Web App, then tabs don't make any sense, but it also doesn't make sense to turn it into a Web App.

To separate this from the emotionally-charged subject for a second: just look at Google vs. Oracle. It took over a decade to decide whether APIs are covered by copyright or not. And the reality is that that was closer to a coin toss than any of us would like to admit, since it was trying to apply a law that in no way imagined something like APIs to APIs, and relied heavily on the judge/etc being able to wrap their heads around it. The verdict could have easily gone the other way. When it comes to how regulations apply to new technologies, the uncomfortable truth is that there is no "objective truth" to the law, and unfortunately comes down more to how much money the parties throw at the problem and legal process. I am sure on the Oracle side there were plenty of people talking just like you: "these people don't respect copyright and flagrantly copy APIs that are obviously protected IP and they think just because they're in hippy open source land the law doesn't apply to them". The reality is that until the verdict, there effectively was no rule around copyright and APIs.

For an opposite example: look at the famous case of Diamond v. Chakrabarty (1980). The patent agency rejected an application for a genetically engineered bacteria that could break down oil, saying you can't patent living organisms. It went to the Supreme Court, that decided 5-4 that they could. Are you going to sit here and tell me this was obvious from the beginning? Given that the patent agency had the opposite opinion than the Supreme Court, and that the Supreme Court was basically split 50/50 on the decision? Do we think they made the right decision given no background in biology? Do we think Chakrabarty was a wannabe biology bro that didn't care about the law, given that almost every lawyer at the time would have told you was commonly accepted did not allow patenting living organisms?

* > tonsbof law firms, counsultants and experts out there explaining the rules and how to follow them.*

Hopefully you see now that a ton of those law firms are out there telling you "I think we can win on this, it has happened many times before, and the reality is that law really isn't written until we make our case".

Similarly, if your actual goal is to reduce the occurrences of "bad behaviors" (which is presumably the whole point of creating these rules to begin with), then it doesn't seem that unreasonable to have someone try to lay it out clearly, right? If for no other reason than maybe a bunch of people negatively affected by these behaviors would have been spared since there wouldn't have been this grey area to operate in for so long? That's who we're ultimately doing this for, right? The public that is hurt by securities that are misrepresented? Now, if your goal is to punish people, then yes, the current system makes more sense.

With respect to the CEO of that company, I mean, sure. But you kind of take that as a given. It's not like he's only been right, and certainly his leadership so far has been business oriented, vs. "wave of the future" oriented. A good example is how the AirPods ended up being an arguably bigger success than the Watch (and how that hasn't really been fully capitalized on). The good news is that the world's biggest company is precisely the kind of place that can afford to iterate on something like this in the public. So if the theory is that the "dream" of AR is only possible by getting stuff out there to iterate on, then they certainly now have a good shot.

If browsers hadn’t removed the shared cache for script resources, there might be an argument here. But they did, putting each domain its own cache to avoid fingerprinting, so even that goes out the window.

On the one hand people worry about the massive node_modules folder in the cases where it doesn't matter (when it's just files on disk in a local node app), and on the other hand, we create things like import maps that will literally take this dependency graph and translate it one-to-one to a higher latency HTTP version, where it absolutely will be a problem.

ESM imports have fallen into the C++ trap: every year the determination is made that "if we just add these 5 extra features (both to the the ECMAScript spec and W3C spec), then they'll finally be great out of the box!" This is how we ended up with import.meta and dynamic import and import maps and import assertions and preloadmodule link tags, which are all still less flexible than require/bundler, and somehow still don't have any answer whatsoever to integrity checksums that originally shipped in 2015. It's absurd.

To be clear, I am not saying there shouldn't have been "an" import spec. I am saying this one is tragically flawed and remains realistically a bad option (unless you are using a compiler that is just going to turn it into roughly the same minified mumbo jumbo it was turning your requires into before). This is fairly well accepted at TC39. The spec was rushed. Nothing would be allowed to ship with that level of consideration anymore. Usually someone at this point asks "well what would you have done?!". I would have punted on import until after async/await. Many of the most fundamental issues in imports come from having to have conceived them in a pre-async/await world. They are essentially a "top-level-await-ish" statement, in a world with async/await. However, had async/await and top-level-await shipped first, and then import was introduced, you could have started with the expression form of import (await import()), which would not have required any new syntax (you could just use destructuring, the same way you do now), and not required a "exercise left to the host environment" hand-waivy async-link resolution system, but instead used the actual existing semantic of the language. We ended up having to do it anyways with dynamic import. It is so weird that `x as y` becomes `{ x: y }` and `x` becomes `{ default: x }` merely by moving the entrypoint around in the file. It would also be a lot more transparent to the user: by typing `const x = await import("blah")`, you aren't (erroneously) lead to believe that this is a synchronous action when it isn't. It's also way easier to add additional features to a function (such as integrity hashes or assertions or whatever), vs. in a statement where it requires a parser level change, and for no real benefit other than causing people to have to learn a bunch of weird new syntax that increasingly feels out of place.

    Many people want to skip bundling altogether for as long as is possible. It's really nice to have a build-free (or almost build-free) app, especially when you're starting a greenfield or personal project. Why get mired down in researching the latest third-party build tools before writing code?

Import maps are a perfect representation of this. It's essentially asking you to hand-write a manifest file just to be able to type "import 'lodash'". This is not an improvement or simplification to the web ecosystem. In my experience, the people who are actually using any of this stuff, are doing so through some build pipeline. And again, this is unfortunate since no one should be shipping this to production since it is both slower and less secure.

1. Import maps are basically a compile-time feature. I thought the point of all of this was to not have to have toolchains?

2. Imports significantly lag behind "old school" scripts in security. You can't use integrity hashes with them, and yet most the examples you see are about importing random scripts from all over the web. This is actually hilariously related to point (1), since you can only escape the realization that this is a feature a compiler is supposed to spit out if you direct the imports to some third party resource. So in order to contrive a situation where you would manually craft an import map, they are forced to show an example that is less secure than the stuff that has worked in every browser for 10 years.

3. Not directly related to import maps, but you'll probably end up using them together: in order to attempt to achieve similar performance to just bundling your code, the amazing solution we've come up with is to... put a <link rel="modulepreload"> tag in your head element for each script you want to be fetched immediately. Yes, so much better than the ridiculous old method of using a script tag for each script. Now you just use a link tag for each script instead. I'm sure someone will tell you that this is better because you don't have to do that. Yes, yes, so much better that the default behavior of script loading is slow unless you go read about a bunch of "tips and tricks" to get it working with reasonable performance.

It's always great to take one concept like "importing a script" and turn it in a an entire ecosystem of terminology that spans languages and platforms, custom JavaScript syntax for the imports themselves, a set of different HTML tags for actually getting them into your page (script, link, etc.), and JSON for mapping names to URLs. Great. Super simple.

ESM has always suffered from a weird shifting argument. Whenever you point out that the performance and security isn't great, all of a sudden it's a developer ergonomics feature, not meant to be for production. Then when you point you the ergonomics suck (like not being able to do bare imports), you're told you should be using it in tandem with a toolchain that auto-generates import maps or something. So what's the benefit? I already had a tool that could do that, and it worked in every browser and didn't ignore the the security advancements we made 10 years ago.

However, they then bizarrely and deliberately refuse to actually police the store, to an alarming and almost cartooninsh level. We’ve seen this time and time again: scan apps remain on the store for months despite being reported. Take just last month when fake Authenticator apps flooded the AppStore to take advantage of Twitter getting rid of mobile phone based 2FA, and not only were those apps allowed on the store, but often managed to get top recommendation.

At least on the web the expectation is that it’s the wild west and you should be careful what you install. On the AppStore it’s as if Apple has purposefully invested effort into creating the perfect mark for von artists: convincing their customers that a shark infested pool is totally safe to swim in.

And this is the undeniably bad stuff, it doesn’t even touch on the “grey area” of these disgusting children’s casino apps that dominate the AppStore, and that Apple shares the profit on to the tune of 15-30%. The incentives are all broken. Apple profits when scam apps buy ad-placement using real apps names for keywords. Apple profits from apps that convince kids to buy garbage IAP.

It would be one thing if the AppStore actually lived up to its supposed principles, at the cost of hurting competition, innovation, and the occasional frustrating developer rejection. There’s actually be a trade-off to discuss, and we’d actually be arguing about principles, and whether safety matters vs. freedom blah blah blah. Hell, as a parent, there’s versions of a well managed AppStore that I’d probably begrudgingly accept.there be a “can’t argue with the results” thinking there.

But that’s not what this is, and I’m tired of pretending toy is in arguments that defend the AppStore. It’s been 15 years, the AppStore isn’t in beta, it’s not “a work in progress”, there’s no room for arguing about its vision vs it’s “current” reality. The AppStore has shown us what it actually is: a supremely lazy and un creative business cudgel that serves neither developers nor customers, and instead serves Apple first and ironically Apple competitors and criminals second. How does it serve Apple competitors you ask? Consider that companies like Amazon are offered special AppStore rates. Little developers don’t get that, big companies do. So not only does the AppStore exhibit monopolistic behavior, it also props up other monopolies.

Also, the search sucks and it’s ugly. It feels like a free samples booth at a Costco. No one at Apple has any taste anymore. Not really relevant to the argument, but just want to point out there’s zero to be proud of in that product.

As to why everyone else uses base64, I figure it's because base64 is what you'd have to inline in the URL since it's the only natively supported data URL encoding.

In other words, in order to take advantage of the size savings of base83, you would have to send it in a data structure that was then decoded into base64 on the page before it could be placed into an image (or perhaps the binary itself). Whereas the size savings of the base64 can be had "with no extra work" since you can inline them directly into the src of the image (with the surrounding data:base64 boilerplate, etc.) Of course, there are other contexts where the base83 gives you size savings, such as how much space it takes up in your database, etc.

How can a static number make sense given the existence of inflation? We've been told for the last year that inflation is "out of control," and yet in the case of the FDIC cap, $250K in 2012 dollars makes the same amount of sense as in 2023 dollars? To save anyone the work, $250K in 2012 is equivalent to $350K in today's dollars, so, a change of $100K, or 40%. Did TARP, which is repeatedly criticized for being passed too hastily, and also included this $250K cap, have secret future knowledge of interest rates and specifically intend for the cap to reduce in value by 40% over the following 10 years? The FDIC limit started at $2,500 in 1966 and has been increased several times. Have we magically arrived at the final number now?

> Deposit sweep accounts cover up to $3M (and diversify across banks, exactly the point of FDIC limits).

These numbers remain arbitrary. Your argument is only that there needs to exist an FDIC limit, not this particular limit. Why is $3M the right amount for sweep accounts? Saying "you can combine accounts to stack FDIC limits like video game power buffs" is true regardless of the base FDIC limit, it doesn't explain why this limit is correct, too high or too low. Look, it works for $50,000 too: "You can have deposit sweep accounts that cover up to $600K. Money market funds provide short term-term treasury bonds above that". And hey, it works for $500K: "You can have deposit sweep accounts that cover up to $6M. Money market funds provide short term-term treasury bonds above that". See, the surrounding multiplier system has nothing to do with justifying the base number. It seems much more likely that a number that was set 10 years ago when money was worth 40% more, and that has a history of needing to be raised, probably doesn't make sense today and needs another update.

> The FDIC limit is not just some technicality that businesses abuse with many accounts, it is a recognition of that fact that banks like SVB, which hold large deposits from a small number of highly correlated depositors, are fundamentally more risky than banks with a large number of smaller uncorrelated depositors. Sweeping large deposits across banks and properly investing in treasuries reduces systemic risk and prevents bank runs in the first place. The de facto removal of FDIC caps defeats this diversification and protection.

If it is so critical to the integrity of the system, then why aren't accounts required by law to be sweeps above the FDIC limit, and not allowed past the "natural sweep multiplier FDIC limit" at all? You just said it yourself: the purpose is to reduce systemic risk. Then let's actually reduce it instead of "planting the seeds of reducing it if everyone gets sophisticated enough," and then getting angry when they fail to do it. The current system is like purposefully trying to create a tragedy of the commons, where individual mistakes are rarely very rarely punished but together contribute to bringing down the entire system. Allowing below FDIC limit accounts seems to be a weird landmine for both the depositor doing it, and for the larger system it operates in. It's the worst of both worlds. It's like when an API doesn't work, and instead of fixing the API, the author updates the documentation to include a workaround and is baffled why people keep running into this problem. Don't they read the docs? These uses are supposedly supposedly so smart but can't be bothered to find this simple workaround buried in my documentation?