Live data from Hacker News

Write code for the web

mrmr.io

321–330 of 364 posts

Re: Write code for the web

#321

Earlier quoted context omitted.

> Of course, Apple's lackluster support or PWAs doesn't help. Holding the web back is entirely intentional and makes strategic sense from Apple's point of view. They're well aware that a majority of apps would work perfectly fine as web apps -- but that also removes Apple from the equation. Only allowing Safari on iOS and intentionally gimping it solves the problem. I mean, I can't even blame them. Can't lose out on…

Honestly if their new revenue share scheme stands up to the court I could see them taking 27% from PWAs as a possible future. It would be the only thing that spurs them to make it more robust. I don’t agree with it at all to be perfectly clear. I’m only postulating that realistically the only way Apple takes PWAs to first class status is if they get a cut. Its rather unfortunate

You're speaking like Apple will get away with their malicious compliance and petulant behavior.

I'm not so sure they will, now that the cat is (finally!) out of the bag.

Re: Write code for the web

#322
post #281

Earlier quoted context omitted.

I don’t think it’s just games. iOS users in general are more willing to pay for software than Android users and Android users are more willing to pay than web users.

This was my experience doing consulting/contracting for most of the 2010s. Clients would want both iOS and Android, and we’d release with full feature parity. In every instance the iOS apps brought in 2x-5x the revenue, even when our Android apps had more active users.

I’ve always wondered why that is. I’ve had both Android and iOS phones and I’ve spent far, far more on iOS apps. I don’t think I’ve ever paid for a web app. There’s something about the platforms themselves then encourage or discourage spending.

Re: Write code for the web

#323

Earlier quoted context omitted.

I find that developing with Electron is a much nicer experience than developing for Apple UIs. And I've written my share of iOS/iPad apps starting over 15 years ago. The nice thing about the Web is that there usually is a library/framework that fits your needs (Electron, for example). For Apple, often there is no good library. Also SwiftUI is so buggy. React just works, and is conceptually simpler (folks, two-way dat…

> For Apple, often there is no good library. Do you have examples? I’ve not often run into this in my projects. These days there’s Swift packages for most things, and in the worst case I’ll have to write a simple wrapper around some C or C++ library. SwiftUI is still green yes, which is why I’ve stuck to UIKit for anything moderately complex.

I stopped coding in Swift about 3 years ago, and SwiftUI was green then, too. I don't expect it to become much better soon.

Not much comes to mind right now in terms of libraries, I just remember constantly thinking that on the Web it is just an "npm install" away, while in Swift I would just have to code it up myself. UIKit is powerful, of course, but just requires too much ceremony most of the time. And SwiftUI is just not reliable. Writing wrappers for C libraries is not my thing, thinking about all implications of different memory models etc. is exhausting, and I'd rather not waste my time on low-level stuff like that if it can be avoided.

Mostly I am thinking about how easy it is to do UI stuff in React, it's much simpler and quicker. The ceremony that XCode and UIKit require are exhausting, as well. Why exactly do I have to give 100 different icons via drag'n'drop for my app? Funny, the Electron app only requires one icon, and I just place it in the right path.

What's a PITA in JavaScript is the commonjs / ecmascript modules mess, but I have a standard template now for coding up a module so that it works for both, and since then I much prefer npm over the Swift package manager, as well.

Coding in the Apple ecosystem just feels sluggish to me now. It feels like the equivalent of a luxury prison. Being able to access things like general compute shaders via Metal is the only thing I miss, but I think via WebGPU this will be fixed soon enough, and in a cross-platform way at that. Just like Electron runs everywhere, not just on my Mac. So what if it is 200MB large compared to a few kilobytes? That doesn't really matter. That's a one time price you pay, and it is well worth it.

Re: Write code for the web

#324

Earlier quoted context omitted.

1. A quick research would have shown that Apple don't support sideloaded software on iOS 2. I see that Photos on iOS has an "Export Unmodified Original" on the share sheet that send the picture to Files. So you could probably connect to SMB share and export that way. I agree that Apple products are not for you. But Apple has always specify a Right Way (tm) to use their products. You either like it or not. Anything el…

1. Yes, if it wasn't clear, I realized this in my attempts to install Retroarch. It was unintuitive to me as someone who uses Windows, Linux, and Android where I can install and run whatever I want to. 2. Chances are that was not obvious to me, or I tried and had no success. This was a while ago, so I may have forgotten other things I attempted. Still, I'm dumbfounded that these amazingly innovative silicon valley co…

I would absolutely love for companies to embrace standards and interoperate better. Apple products' limitations never make sense other than "Profit". But AFAIK, their products work well together. And I agree it's painful when you're not invested in the ecosystem. But their focus is that ecosystem and I can understand their line of business.

Re: Write code for the web

#325

Earlier quoted context omitted.

> For Apple, often there is no good library. Do you have examples? I’ve not often run into this in my projects. These days there’s Swift packages for most things, and in the worst case I’ll have to write a simple wrapper around some C or C++ library. SwiftUI is still green yes, which is why I’ve stuck to UIKit for anything moderately complex.

I stopped coding in Swift about 3 years ago, and SwiftUI was green then, too. I don't expect it to become much better soon. Not much comes to mind right now in terms of libraries, I just remember constantly thinking that on the Web it is just an "npm install" away, while in Swift I would just have to code it up myself. UIKit is powerful, of course, but just requires too much ceremony most of the time. And SwiftUI is…

Maybe we’ve just been writing very different types of software but as noted earlier, it’s been very unusual for there to not be built in or third party solutions to problems I’ve encountered in UIKit/AppKit.

The ceremony involved seems pretty minimal to me considering the trouble saved. It’s a relatively small front loaded cost that precludes problems further down the line.

As for icons there’s a bunch of shell scripts, AppleScripts, etc that will take care of minor one-time annoyances like icon scaling (though there’s actually good reason for 1x, 2x, and 3x versions of images to be distinct… scaling a single high rez icon down tends to look like a terrible smugdy mess on “normal” DPI displays).

Re: Write code for the web

#326

Earlier quoted context omitted.

Nah, the shitty parts of web dev are in basic building blocks other ecosystems handle without a problem. The fact that javascript can run anywhere doesn't mean it needs to have crappy build systems. It doesn't mean it needs to have constant breaking changes and flaky dependencies. CSS is crap for layouts. I've build apps with at least 10 layout systems, and CSS is the worst of all of them.

Correct, but HTML + JS + CSS is the standard we seem to have settled on, and having a globally accepted standard for anything is a unique and historic achievement, let alone for free, fast, and robust global distribution of Turing-complete computation and content delivery. Now we can hope that those building blocks improve over time, but the current situation is so much better than it could have been.

> having a globally accepted standard for anything is a unique and historic achievement, let alone for free, fast, and robust global distribution of Turing-complete computation and content delivery.

It really is amazing.

> Now we can hope that those building blocks improve over time, but the current situation is so much better than it could have been.

I think the web is under-appreciated in part because most people have never used internet connected GUI computers without it, but it's important to remember that there's no a priori reason for why the web had to exist.

In an alternate timeline we could be living in a world where all interactive software has to be reviewed by a gatekeeper. I wasted an inordinate amount of time playing with this a few days ago: https://news.ycombinator.com/item?id=39205020 and I remember thinking, it's pretty cool that you don't need anyone's approval to release something like this, nor do you need to pay excessive fees to distribute it, nor does it take any meaningful time to download/install, and yet it works on all my devices, and it's relatively secure.

Re: Write code for the web

#327

The $100 developer fee is very annoying, but understand it's there to add a small barrier to entry. It makes people think twice about whether they really want to launch an app on the app store and therefore stops many users from publishing junk apps.

To my knowledge, the fee is for the dev kit rather than the ability to publish on the app store. If it the aim was to prevent junk from being published, then surely the fee should apply at the point of submitting an app for review.

Re: Write code for the web

#328

Earlier quoted context omitted.

I wish PWA advocates were more intellectually honest. They don't care about the web and what is good for end users i.e. more APIs = less privacy. They simply want to build apps without Apple's fee and controls.

Well, I wish Apple advocates would stop strawmanning and posting incorrect generalizing accusations. I care deeply about privacy. That means I trust the browser sandbox a lot more than native apps. There's obviously a reason sites like Twitter and Reddit try to force their native apps on you as soon as you visit their web page on a phone -- it'll allow them to spy more on you.

> That means I trust the browser sandbox a lot more than native apps

You shouldn't.

The most privacy invading behaviour by far is the cross-site tracking that happens on the web. Where large data companies as well as Facebook/Google are building behavioural profiles with thousands of features and data is being packaged and sold to entities you have no knowledge of.

And all of which is being facilitated by browser fingerprinting courtesy of Google recklessly adopting APIs with little care about privacy.

Re: Write code for the web

#329

Earlier quoted context omitted.

Well, I wish Apple advocates would stop strawmanning and posting incorrect generalizing accusations. I care deeply about privacy. That means I trust the browser sandbox a lot more than native apps. There's obviously a reason sites like Twitter and Reddit try to force their native apps on you as soon as you visit their web page on a phone -- it'll allow them to spy more on you.

> That means I trust the browser sandbox a lot more than native apps You shouldn't. The most privacy invading behaviour by far is the cross-site tracking that happens on the web. Where large data companies as well as Facebook/Google are building behavioural profiles with thousands of features and data is being packaged and sold to entities you have no knowledge of. And all of which is being facilitated by browser fin…

You're not talking about a sandbox then?

A native app won't prevent Google or Facebook (or Apple) from tracking you. In my experience, native apps typically always require login, and then fingerprinting is unnecessary.

Avoiding their services, and using an open source and privacy respecting browser with uBlock Origin installed will protect you however.

The latter can be done on all OSes I've used -- except iOS.

Re: Write code for the web

#330

Earlier quoted context omitted.

I stopped coding in Swift about 3 years ago, and SwiftUI was green then, too. I don't expect it to become much better soon. Not much comes to mind right now in terms of libraries, I just remember constantly thinking that on the Web it is just an "npm install" away, while in Swift I would just have to code it up myself. UIKit is powerful, of course, but just requires too much ceremony most of the time. And SwiftUI is…

Maybe we’ve just been writing very different types of software but as noted earlier, it’s been very unusual for there to not be built in or third party solutions to problems I’ve encountered in UIKit/AppKit. The ceremony involved seems pretty minimal to me considering the trouble saved. It’s a relatively small front loaded cost that precludes problems further down the line. As for icons there’s a bunch of shell scrip…

Sure, you can streamline the process of icon creation. The point is that Apple often sets up things in a "simplified" way which is not really simpler, just more annoying. There are no "normal" DPI displays in Apple's ecosystem anymore, so one SVG should always be fine in many cases.

Again, my main point is that coding Apple apps just takes too much time and ceremony compared to what you get out of it (an app that only runs in Apple's ecosystem). The only way to justify writing an app specifically for Apple products is when you depend on their special hardware and ecosystem features. Or of course if you don't care if your app runs anywhere else. Or if you have resources to blow.

Apple treats software as an extension of their hardware: Generality and abstraction do not count for much, as long as this makes it possible to fit the software tightly to their current hardware. That's nice for Apple, but not so much for a developer who doesn't care for much more than generic hardware features.

Post reply on HN