5 ms·

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), a

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.

Yuioup 6y ago
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.
- londons_explore 6y ago
  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.
  - g_p 6y ago
    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!
    - NicoJuicy 6y ago
      An SDK is nothing more than dependencies bundled for a specific version.
    - kllrnohj 6y ago
      The "one layer higher" for Android is Jetpack: https://developer.android.com/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/paging https://developer.android.com/topic/libraries/architecture/p...
      - g_p 6y ago
        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
- modeless 6y ago
  That's a ridiculous bar for being impressive. And yet, totally possible. https://bellard.org/jslinux/vm.html?url=win2k.cfg&mem=192&graphic=1&w=1024&h=768 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.
dahfizz 6y ago
You can create a view in android in XML just as easily as you do for the web in HTML.
- modeless 6y ago
  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.
  - dahfizz 6y ago
    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.
    - javajosh 6y ago
      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?
g_p 6y ago
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.
- PunksATawnyFill 6y ago
  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.
bathtub365 6y ago
A single HTML file would be an absolute nightmare for anything even slightly nontrivial. This oversimplification falls down almost immediately.
- modeless 6y ago
  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.
  - kelnos 6y ago
    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.
- javajosh 6y ago
  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.
  - kelnos 6y ago
    So then it's... not a single HTML file for you application anymore.
deleted 6y ago
[deleted]
rimliu 6y ago
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.

Yuioup 6y ago

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.

londons_explore 6y ago
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.
- g_p 6y ago
  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!
  - NicoJuicy 6y ago
    An SDK is nothing more than dependencies bundled for a specific version.
  - kllrnohj 6y ago
    The "one layer higher" for Android is Jetpack: https://developer.android.com/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/paging https://developer.android.com/topic/libraries/architecture/p...
    - g_p 6y ago
      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
modeless 6y ago
That's a ridiculous bar for being impressive. And yet, totally possible. https://bellard.org/jslinux/vm.html?url=win2k.cfg&mem=192&graphic=1&w=1024&h=768 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.

dahfizz 6y ago

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

modeless 6y ago
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.
- dahfizz 6y ago
  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.
  - javajosh 6y ago
    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?

g_p 6y ago

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.

PunksATawnyFill 6y ago
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.

bathtub365 6y ago

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

modeless 6y ago
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.
- kelnos 6y ago
  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.
javajosh 6y ago
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.
- kelnos 6y ago
  So then it's... not a single HTML file for you application anymore.

deleted 6y ago

[deleted]

rimliu 6y ago

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.