I'd give anything to move our apps to the web. We're in the medical field (our apps connect to medical devices over Bluetooth), so publishing on Google Play is like a Kafkaesque fever dream. Two days ago they tell us our app fits into categories like:
Activity and Fitness
Nutrition and Weight Management
Sleep Management
Medical Device Apps
So we gotta update our policies, but today they said something like: "Actually, jk, you don't qualify as a Medical Device App anymore - app update rejected."
Meanwhile, Apple (who used to be the actual nightmare) has somehow turned into the reasonable one. They approve apps in minutes now. MINUTES.
It's like Google saw Apple's approval process from 10 years ago and thought, "Let's do that, but make it a circus." At this point, I dream of ditching native apps entirely. Too bad Bluetooth on the web is still a bit... fragile.
I somehow got my personal email associated with the classroom Google Play account from back when I was at university, so every app uploaded by all students for each new semester I get emails for still. Every few months I get a batch of 30+ emails telling my that my app is not in compliance and it's at risk of being removed.
Assuming that the device has an up-to-date browser available for it. And today, that usually requires having a multi-MHz multi-core processor and GiBs of memory. No matter how lean your actual application/website is.
I have a stack of E-Ink readers, all in terrific condition. My favorite is the B&N Nook Glowlight 3. When it was new just about five years ago, I could install a web browser on it via ADB and it would work reasonably well. Today, all the browsers are bloated beyond installable and usable.
I feel your pain, though I blame the websites more than the browsers. I can run full firefox on my OG pinephone as long as the sites I visit aren't running a pile of JS lunacy.
My Onyx Boox runs Firefox happily too, but for that and the pinephone I'd recommend trying out a Gemini browser (there are several on fdroid). It's lacking plenty, but has an old-web feel, no sites are slow, and you can handily use it on old devices.
> I feel your pain, though I blame the websites more than the browsers.
I blame the standards organizations.
I love the Boox devices as well. My Note Air 2 Plus is almost two years old, it is a terrific machine. I'd love to know what your use cases are. I mostly use it for taking notes and reading - including on the web - but I'm rather unhappy with most browsers on it including Firefox. For one thing, Firefox on Android has almost no keyboard support.
Oh yes, I think the web standards orgs are culpable (especially W3C) for not making it fast and simple to implement the features PHBs demand. This is surely in spite of the good people working on their behalf, and more a sad molochian consequence of regulatory capture big big adtech.
My Boox Color 7 was originally bought for terminal work and I connect it to my bluetooth keyboard and use tailscale and termux to make it a nice e-ink "dumb terminal". It's also nice for reading books on, and downloading said books (though I miss Kindle's email transfer method). I did try watching a YouTube video on it once, the result was almost watchable and far better than expected.
> Assuming that the device has an up-to-date browser available for it.
Not necessarily. You can target older devices with old browsers if you want, by carefully choosing JS/CSS versions and features, or just by making sure your code degrades gracefully.
The older browsers that would run on these devices have known exploitable security issues. The newer browsers are very heavy because they support navy features and expect that the hardware is newer.
The problems begin accruing before the user even types in your URL.
Developing apps on it still seems really, really primitive. HTML alone is not sufficient for a decent looking UI. Tailwind directives gunk it up rapidly. Component frameworks help some but still don’t seem quite as nice as something like SwiftUI. Server side functionality still requires a lot of manual serialization/deserialization (unless you use the newer crop of frameworks that have figured out this is pure noise).
And then there’s JS.
Rails, htmx, and a few others seem like the only ones who really get that a simple web app should be 50-100loc.
> It isn't even difficult if you have any skill at all.
Very constructive, thank you.
I'm talking about the defaults of HTML. There's no pit of success, just lots of div-wrapping and tweaking until things fall into place. Compare with SwiftUI, where you plop two controls and they're spaced sensibly from one another without you doing anything. This was also the case in VB6.
> And then there's another person who didn't take the time to learn JS and just hates it for reasons.
I've been writing TS for awhile now, it's mostly fine. Should've expanded further: npm is a bit of a madhouse, and JS culture basically consists of "we shove JS everywhere we can and say it is good because it is JS."
> Show me a native app with a polished UI and any useful functionality in only 50-100loc.
I'll concede that. At 50-100loc, you can have a decent looking native app for a simple task. Presentation layer for a webapp blows through that immediately. Some of that is accepting the medium as is and learning to work with it. Some of it is also the fundamental impedance mismatch of the web writ documents/apps.
>There's no pit of success, just lots of div-wrapping and tweaking until things fall into place.
If you don't know what you're doing and plan things out, sure that is what you might expect - but that's a choice. And that's the same in any language or framework or platform. It's possible to write bloated unmaintainable UIs outside of JS/HTML.
>npm is a bit of a madhouse, and JS culture basically consists of "we shove JS everywhere we can and say it is good because it is JS."
Every package manager for every language is a bit of a "madhouse". It's the nature of free software. I'm not sure why you would expect JS programmers to not want to use JS packages, I'm not quite sure how you arrived at this sentiment.
>At 50-100loc, you can have a decent looking native app for a simple task.
Same with Javascript. You might be surprised what can be achieved in a few bytes of Javascript. Ever visit dwitter.net ? I think you're also leaving CSS out of the equation, which has very powerful styling capabilities. 10 or 20 lines of CSS can achieve a lot of UI styling for a simple app. The HTML/CSS/JS combination is very expressive, extremely powerful and easy to use. Not sure how you think it's somehow incapable of UI similar to native applications, without bloat, and easy to implement. I suppose it depends on your skill level with these tools, because I find it extremely easy to do. YMMV.
I have learned JS & used it extensively in many projects. Including modern SPAs. And I absolutely despise it & wish I could use something like recently trendy GO or RUST.
JS has absolutely no rhyme or reason, single threaded nature makes it gunk up browsers crazy quickly & the insane bloat of "frameworks", which attempt to completely replace already great APIs, while working on top of them... IS CRAZY!
That's really false. The type coercion matrix does make sense for the job it is supposed to accomplish, even if you personally don't agree with it for whatever your reasons are.
If you haven't seen the info presented like this before, then I can understand why Javascript might seem "CRAZY" after reading so many blog posts by people who like to complain for clicks. If you think this chart doesn't have any "rhyme or reason", then please explain why.
>single threaded nature makes it gunk up browsers crazy quickly
That's one way to look at it. Another way is to learn how to work with the system you have, not the system you want. Improvements to the system can be slow, and can't be breaking changes. This is true about every system humans have ever devised.
Webworkers are great, you can absolutely do multi-threaded Javascript, I've done it, it was easy. If that solves the problem in a reasonable amount of time, great, if not then I'll probably do it in C and run it from Javascript since it's so easy to write the rest of the application with Javascript.
Not everything needs maximum performance. For some embedded systems I usually write 100% assembly language because every byte and clock cycle matters. But I know all of this really well, so maybe it seems easy for me. When I started with Javascript in Netscape in the early 90's, it wasn't as well documented and well supported as it is today. That version of Javascript was a bit rough around the edges. But today? Naaa. It's easy, it's got a huge support system, a lot of progressive enhancements, thousands of videos, millions of developers and about a billion blog posts on medium.com.
I switch back and forth from C to Javascript and it's a great combination. Less context switching, the syntax close to 1:1 as far as I'm concerned. But C is a pain in the ass in comparison to Javascript, and I know both languages extremely well. I've been writing software almost 50 years.
>the insane bloat of "frameworks"
I'm using Preact for my embedded IoT front-end and the complex web app it compiles is less than 50KB total gzipped. Bloat is a choice, not a requirement.
I have complex front-ends running "at web scale" based on jQuery (for business reasons). We decide every byte that gets included, and manage to score 100% on all page speed tests. No bloat.
>which attempt to completely replace already great APIs,
Citation needed.
> IS CRAZY!
People have been using Javascript successfully for decades. Sorry Javascript isn't your favorite language, but it's not as you describe it either.
> When I started with Javascript in Netscape in the early 90's, it wasn't as well documented and well supported as it is today. That version of Javascript was a bit rough around the edges
Best bug I saw there was how it would sometimes just...give up on running JS if you held it wrong (probably a Netscape thing) and you had to figure out why.
> I'm using Preact for my embedded IoT front-end and the complex web app it compiles is less than 50KB total gzipped. Bloat is a choice, not a requirement.
50KB sent to the client in total? What UI libraries do you use? Happy to try out things; I'm currently a fan of Svelte but haven't tried Preact yet.
I started the project with create-react-app a long time ago. I've since updated it to latest versions of webpack and switched from React to Preact. It's not using any hooks or any modern React conventions, but I don't really need it. I've kept it simple, the only two libraries I include are preact-easy-state and preact-router. Everything else is components I wrote. All images used are SVG, I'm using LESS to compile to CSS, and everything is bundled into a single HTML file that gets gzipped down to about 48KB. I've tweaked the default Webpack configs to get exactly the payload I want. This gets compiled into my ESP32 firmware and served directly from flash. The web app handles all devices configs as well as wifi access point config, and it controls all kinds of device functions using custom sliders and buttons, etc.
It’s important to note that it’s not a matter of effort for Firefox. They’ve decided that the it’s not something they want to implement[1]. The reasoning is that they think it allows low enough level access to potentially mess with devices who weren’t made to be resilient to malicious input, and didn’t like that the proposed method of allowing web Bluetooth is based on a default allow policy with a blocklist, which means as new Bluetooth device vulnerabilities are discovered, this blocklist has to be maintained.
Wouldn't the correct time to raise those concerns be during the web bluetooth design process? The idea that a browser decides "nah" about a web standard because they're mad about it seems like the road to ruin
Then again, almost every time a Firefox thread appears here it gets filled with comments pointing out how low its adoption is so I guess "well, yeah" sums it up (he said, commenting from Firefox)
Not just Safari and Firefox, on iOS all browsers are forced to use Safari's web view, because Apple wants to force developers to write apps so they can make 30% revenue from the app should any money exchange hands. They can't force developers to write apps if web browsers on iOS are allowed to access bluetooth and other modern browser APIs.
Isn't some of what you're describing a critique of walled garden platforms rather than web vs native? e.g. When I self-publish a native desktop app, I can pick the DRM, code updater, and payment processor I use.
Activity and Fitness
Nutrition and Weight Management
Sleep Management
Medical Device Apps
So we gotta update our policies, but today they said something like: "Actually, jk, you don't qualify as a Medical Device App anymore - app update rejected."
Meanwhile, Apple (who used to be the actual nightmare) has somehow turned into the reasonable one. They approve apps in minutes now. MINUTES.
It's like Google saw Apple's approval process from 10 years ago and thought, "Let's do that, but make it a circus." At this point, I dream of ditching native apps entirely. Too bad Bluetooth on the web is still a bit... fragile.