|
|
|
|
|
|
by tmpz22
458 days ago
|
|
|
Sandboxing giveth and sandboxing taketh away. The security value of sandboxing, particularly in a web browser, is obvious. But as a result web apps can't access a meaningful filesystem (not counting React Native, don't get me started on IndexDB or OPFS) and this has a significant impact on application development - pushing developers to build much more complicated client-server architectures which increases the cost of making a great app. Swift and SwiftUI are seductive for building cross-platform iOS/Mac/IpadOS applications but despite Apple's marketing have significant frictions when building real-world apps. There's a reason large companies are still using Objective-C and UI-Kit - SwiftUI, and DEFINITELY SwiftData, are arguably not ready for production yet in direct contradiction to Apple's community messaging. Look you can build a great app with any of these stacks, there's a lot of nuance in choosing between them, and the most cost effective and quality effective path will be decided by the developers strengths and weaknesses not the latest blog article or what happened to be "successful" for somebody else. |
|
|
One of the "eternal September" moments of web app development was in the late 1990s when Microsoft went "all-in" and Microsoft-oriented developers flooded forums with tearful laments about how "MY BOSS NEEDS TO ME TO BE ABLE TO ACCESS LOCAL FILES IN A WEB APPLICATION!"
From the viewpoint of a web-native developer though, you need local files about as much as Superman needs a Kryptonite sandwich. (You didn't lose local files, you gained the universe! Look at how multimedia software on CD-ROM was utterly destroyed by the world wide web!)
That image sorter, for instance, has a million images sampled from a practically infinite pool all available instantly to any device anywhere in the world that's attached to my TailNet -- though you'd better believe I keep RAWs from my Sony on local file systems. [1]
I had a boss who ran a web design company circa 2005 which had a great spiel about how with web applications small businesses could finally afford custom software, I had my own technical version of it which went something like. "Back in the Windows '95 age obsolete desktop applications kept their state as a disorganized graph of pointers that inevitably gets corrupted just like cheese goes bad and crash; modern web applications keep their state in a transaction-protected database (if you're smart enough to NOT GET SEDUCED BY SESSION VARIABLES PROVIDED BY YOUR RUNTIME) so your application state is refreshed with every page update"
[1] Adobe's relationship to the local filesystem drives me nuts even though I've talked w/ people there like Larry Masinter and deeply studied file formats enough to understand their point of view. My first instinct, having worked at a library, is that you want to associate metadata with an object, in fact I really want to "name" an object after a hash of the contents and have the object be immutable.
On the other hand, XMP which stuffs a metadata packet into a file, is a good fit for the way people use desktop apps. Still, my #1 complaint about Photoshop is thinks a file has a changed (some metadata has changed) when I do some operation that I don't think of as a mutation such as making a print or exporting a compressed and scaled JPG with the "Save to Web" Dialog. Since I do a lot of different things with my machine I am always forcing shutdowns which means Photoshop is always harassing me to recover files that I "didn't save" even though I didn't really change them. Sometimes I just save files that I don't really want to save but it feels icky because the source file might be a JPG which might not round trip perfectly, where I might feel compelled to save at a higher quality than the original file and all of that.