3 ms·

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

by 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.
- javajosh 6y ago
  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
- g_p 6y ago
  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!
saurik 6y ago
> 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.
- g_p 6y ago
  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".

by g_p 6y ago

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.

javajosh 6y ago
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
g_p 6y ago
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!

saurik 6y ago

> 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.

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