41–50 of 451 posts
Earlier quoted context omitted.
If you're referring to the pre-App Store iPhone OS, have you considered the possibility that they were just late with the SDK?
Apparently according to the Jobs biography, Steve Really did oppose native apps https://9to5mac.com/2011/10/21/jobs-original-vision-for-the-...
Earlier quoted context omitted.
This kind of scares me to. The vibe that I have is that (web)developers want to make JS into a silver bullet to solve every problem (backend nodeJS, apps react native cordova etc). But I also wonder why they don't want to learn a new language. Some languages really make you look at a problem from a different perspective and to be honest also work better then JS.
The vibe you have is wrong. It's not about learning a new language. Most web developers are comfortable in many languages. Plase stop attacking a straw-man. Not many web developers say stuff like "omg these new things are web scale" or "oh javascript is everything I need, I hate everything else". Yeah the author didn't want to learn a new language. Which is not an insane decision at the very beginning of a project. T…
Earlier quoted context omitted.
I've never met a single end user who wants desktop notifications for web "apps," including myself. In fact I wish I could turn it off globally and more easily. I'm sure there are a number of legitimate uses but as of now, every craptastic "news" website I visit now wants to pester the hell out of me with notifications when they post new clickbait.
Im comfortable with the current system where websites request permission for notifications, but they are as useful as phone notifications. Message in a webchat, new email, new private notification on Twitter, &c. It should always be opt in, but it is a useful thing for many use cases.
As an iOS user, I'm actually quite glad that websites can't send me push notifications on it. And app loading screens are a feature? If people _insist_ on making phone apps as websites, there's Cordova and all that. Such apps are never very good, of course. I still haven't seen a website-based desktop/phone app that wasn't a clunky non-native-looking resource-hogging mess.
IMO convoluted JavaScript hacks aren't the solution to "cross platform development" I'd want to settle on. Do I really want my weather app to be running on top of the browser app? And as far as cross-platform compatibility goes, we're now at a point where websites tell you to please load them with Chrome for the "full experience", that just reminds me of when websites used to tell you to please use Internet Explorer.…
Walled gardens with one app per platform with 1000 different rules per platform so users don't spend more than 100ms to understand a layout shouldn't be the solution as well. Javascript apps being convoluted isn't even an objective observation.
> Do I really want my weather app to be running on top of the browser app?
It's yet another VM with more abstractions. What's the big deal?
> So much for "Apple mobile Safari is the new Internet Explorer", lol.
I never had any significant app work only on one browser since years but even if this was a big problem, why make it worse?
> Push notifications for browsers are a weird concept, anyway.
I don't see the big deal? You are asked to allow it, no?
Earlier quoted context omitted.
> web apps are reaching for feature parity with native Not even remotely close.
This is Papa Pear: https://king.com/game/papapear The HTML5 version is compiled from the same source that the App that goes to the Apple App Store ( https://itunes.apple.com/us/app/papa-pear-saga/id572542612?m... ). What's so different? It is literally the same code base (minus some platform specific code).
Officially Apple's reasoning for barring Flash was that web should be pushed forward. Now, almost 8 years later when web is "almost there" - its still hindering real web-app experiences in the iOS browser. Its pretty clear what this was always about. -- (Please lets not do the fanboy "Flash is garbage" here - even if you do feel that it was heating up your CPU with ads - it would have taken a lot less than 8 years to…
They had more than 8 years to fix it on the desktop and didn't. They had more than 8 years to make the Mac version perform at rough parity with the Windows version and didn't.
Either way... "it's fine, we'll make it work well within a decade" is NOT a good message to your users.
I can see why apple is hesitant to do this. But there is definitely a middle ground. Require the same developer registration process as they currently do for iOS apps. Then require some apple provided javascript to provide access to these needed functions. App review as before. At that point they can do interesting things: charge per 1000 installs, enforce the use of apple pay. They can operate a business model that…
Earlier quoted context omitted.
Is there a reason for users to care about this at all? Because it seems to me that this just solves problems for developers while making the user experience worse or not as good as it could be. The same goes for Electron-based apps.
Watch the State of the Web talk from Google IO 2017. Certain native apps (Twitter, OLA) are 70-100MB in size when downloaded from the app stores. Their progressive web app version are 0.2-0.6MB. Extremely important in countries with very limited and/or expensive mobile data.
According to this, Facebook was 32 MBs 4 years ago. It's similar with Twitter.
It's their fault that they keep adding stuff to track you. And Facebook contains just about every library that has ever existed now.
All browsers still suck at basic functionality. Here's a quick short list of things that developers still have to write because the current implementations are broken, buggy, inconsistent or absent: - Date pickers. - Image upload [1]. - Autocomplete and datalist. - Range pickers. - Upload time remaining without javascript. - Number min/max/step, use up/down keys to increment/decrement. - Form elements that are unable…
Original www is very successful at mouse-based UX, but horrible at touch based.
Actually browsers could agree on a dozen touch based standard input elements and we don't need 80% this JS framework cruft.