Hacker News Reader

Comment by javajosh | Hacker News Reader

It's really interesting to me that, in the end, we build interactive screens. Consider all the complexity it takes to build one of those for Android (or iOS), and what it takes to make a a screen for the browser. One requires a whole stack of big, complicated, brittle tools. The other can be achieved in a single html file.

View on HN

You forget that web browsers are very complex programs running on operating systems which in turn also are complex programs.

If you can boot an entire operating system with a single html file, THAT would be impressive.

It really depends where you want to draw the line between the code which is part of the "OS" and the part that is the "app". The web platform puts as much as possible into the "OS", while android has far less, so the app has to include much more.

I'm not a defender of the "modern web" recursive dependencies approach to building js sites, but the one thing the web platform seems to do better than Android is let the developer focus more onto their own logic, rather than reimplementing basic boilerplate activities. Sadly I've never really found a "one layer higher" overlay for the Android APIs to let developers take advantage of good boilerplates by default - I'd rather not pretend I'll implement data loading from an array or db into a scroll view better than someone else that has thought it through and understands the platform, because I know I won't!

An SDK is nothing more than dependencies bundled for a specific version.

The "one layer higher" for Android is Jetpack: https://developer.android.com/jetpack

Eg for "I'd rather not pretend I'll implement data loading from an array or db into a scroll view better than someone else" that'd be the Paging library: https://developer.android.com/topic/libraries/architecture/p...

I will take a look at Jetpack - it does sound promising as the "next layer up". I was hoping Flutter might try to fill this space - it feels to me that there's no inherent need for the "higher layer" to be platform specific, although there's probably an impetus for Google/Apple to make it so, from the perspective of ecosystem control, developer mindshare, and simply reducing effort to build and maintain.

At least skimming the docs and watching the introduction videos, it does sounds like JetPack might be what I'm looking for! Thanks

That's a ridiculous bar for being impressive. And yet, totally possible. https://bellard.org/jslinux/vm.html?url=win2k.cfg&mem=192&gr...

The current version of jslinux is wasm, but the original was just a few JavaScript files and could easily have been a single HTML file.

I think there are 2 issues with Android and iOS development here - first is the steepness of the "on ramp". I learned web development using the "edit html page in text editor, switch to browser, press F5 and look" approach. That was really it unless you wanted to wait a few years then go down the FrontPage route. Android and iOS have a much steeper on-ramp, and the work required to get something simple (but not straight from the docs as an example) on your screen is considerably higher than in HTML. Part of this is due to web browsers benefitting from a full stack and complex browser, as another commenter said.

The second issue is around the abstractions used to make apps - I'll speak for Android here but I believe iOS is quite similar in outline. In Android, abstractions are incredibly leaky and require you to understand much more about the internal workings than HTML does. I can build a site in HTML without worrying about how the browser implements the functionality - for example, I can make an un-numbered list, or create a list box and populate it with items, fairly easily, even doing so dynamically from JavaScript.

In contrast, on Android, you need to start understanding ListView versus RecyclerView (apparently the latter is better to use?). Then to understand Adapters. Then to figure out how to get content into that ContentAdapter. At some point invariably you'll discover issues with whether your code is running on the UI thread (and blocking the UI from updating while it runs, which is obviously bad), or running off the UI thread (and thus unable to update the UI elements)... You can't (at least in my experience) just get down to focusing on your business logic, without reinventing the wheel a fair bit here. You'll also need to discover the "de-facto go-to library" sometimes, where the built in API isn't good. Bluetooth springs to mind, where I believe most people would recommend using a third party library rather than the included one. That's a discoverability challenge.

I don't think we should take this level of control away from anyone wanting it, but I think it's important we recognise mobile development seems to favour the approach of "bring your own batteries, soldering iron, and flux, as we don't provide any", whereas web has some available batteries and equipment you are free to use, or alternatively to build your own. It would be nice to see some default "batteries" pre-installed, so people can get started without having to learn the details of all the leaky abstractions needed to understand how to get an app to show up and respond to input etc.

That's interesting. I am an iOS developer, and find development for browser deployment to be a mountain of hokey crap and flavor-of-the-week frameworks all so you can kind of cajole MOST browsers to more-or-less show what you want where you want it on the screen.

And then you have to write all the serialization and back-end support on the server side, or use yet another flavor-of-the-week stack to broker all of the back-and-forth.

But all of that is optional stuff for the web, even though it isn't presented as such. You don't actually need a transpiler, bundler, fancy libraries etc to write interactive programs for the browser. You really can do everything in an HTML file with some html, javascript, and some css. You can draw pictures declaratively with svg, or programmatically with canvas. And so on. You can see some nice work done in this way in places like codepen.io

Oh the browser/JS world is far from perfect too - the NIH-isms and re-invention of the wheel in stacked and layered frameworks is definitely a problem on the web.

I think it will come down to the level of abstraction that works and makes sense, while helping enable building things, though still focusing on the business logic, not the boilerplate.

I guess this is still one of the many un-solved problems!

> At some point invariably you'll discover issues with whether your code is running on the UI thread (and blocking the UI from updating while it runs, which is obviously bad), or running off the UI thread (and thus unable to update the UI elements)...

FWIW, this exact same issue comes up in web development, only it is harder to spawn threads (in this case, web workers) to solve issues.

Very true, and harder to really work around in JS, although I guess you can get a fair bit further along the "runway" before encountering this issue.

With Android, you'll probably need to be using UI and non-UI thread work for anything that makes a network request or does more than a "hello world".

A single HTML file would be an absolute nightmare for anything even slightly nontrivial. This oversimplification falls down almost immediately.

I've built many useful tools as single HTML files. And several of my larger projects have started as single HTML files and stayed that way for quite a while. Even when they get bigger they don't grow all the cruft that a "Hello World" Android app has right out of the new project wizard.

I think the issue is just about app scale. Android development is designed around medium or large apps, and doesn't at all try to optimize for small apps, and certainly not a Hello World app.

And honestly, I'd prefer that an IDE generate a Hello World app with all the random stuff in it that a full-blown app would need, even if it isn't required for Hello World. It makes the learning experience a lot more useful.

Single HTML files are a nice unit of component for building UIs. See the BrickLink store-front. Each part is defined in its own HTML file and then these are concatenated before being served. At dev time each component can be put through its paces in isolation ("explore the characteristic state space"). At runtime you can `clone()` the DOM to make more, modify it and so on. It worked really well.

So then it's... not a single HTML file for you application anymore.

For anything complex, your "single html file" would look horrible. If anything doing iOS work after decade and a half of web was a breath of the fresh air and felt way less brittle.

You can create a view in android in XML just as easily as you do for the web in HTML.

Not even close. You need a whole directory tree of random junk and a whole passel of build tools before that XML file does anything. Meanwhile on the web I can open any text editor, type some random HTML without any boilerplate, possibly even with some inline JavaScript code, save it with a .html extension and it's already a single page app.

As a bonus, all the tools to debug it (even with a device simulator or remotely on a real Android device) are already installed as part of the browser, and the browser itself is a download of less than 100 MB.

It literally takes a minute or two to create an entire Hello World android application. At that point, all you have to do it edit your one xml file. The IDE does as much for me as the browser does for you.

The is the classic web vs native debate. What are we optimizing for? Making it as easy as possible for someone with no experience to throw something together? Sure, the web is great for that. I would rather prioritize performance and the user experience.

I spun up an Android project 2 days ago and it took me much longer. I already had IntelliJ installed. So I had to answer all the prompts about API level and emulator settings, but then gradle completely failed. It took me an hour to research and fix it - it turns out recent versions of Java (>9) spit out their version in a different format. Ultimately the solution was to configure IntelliJ to use an older java to run gradle.

The cool thing about the browser is that you don't need other tools. In a sense, the browser has a build step - when the root html file is loaded, it's sub resources are loaded as late as possible, and combined! If you really need more control over this "build" process, you can acquire programmatic control using XHR. What's even cooler is that you can dig into at ANY browser program at runtime! Can you do that on Android or iOS without specialized tools?

Reply on news.ycombinator.com