5 ms·

The web is great in theory, but the bare-bonesness of the browser environment makes it an exceedingly unappealing platform for apps specifically when you’re use

The web is great in theory, but the bare-bonesness of the browser environment makes it an exceedingly unappealing platform for apps specifically when you’re used to developing with a throughly batteries-included experience like you get on Apple platforms. Where on macOS a highly capable, polished app can be easily be developed with a list of dependencies and sub-dependencies that can be counted on a single hand (and with a little effort, none at all), the equivalent web app has many tens or hundreds because of all the feature gaps needing filling in. For example, I don’t see why browsers can’t furnish basic list and table views that are capable of efficiently recycling their cells without any (or extremely minimal) JavaScript. It’s not unusual to need to be able to scroll through hundreds or thousands of items without causing the device to chug or run out of memory, and that’s handled nicely out of the box in AppKit, UIKit, SwiftUI, Android Framework, Compose, and probably even Flutter (haven’t checked) but in the browser you’re either pulling in a library or writing custom code for this very basic capability. And that doesn’t even get into the package management and general tooling situation, where the same fundamental problems doggedly persist even as solutions come and go.

deadbabe 3y ago
What’s wrong with Javascript
- vorticalbox 3y ago
  Nothing really but lots of it is not a nice experience.
- jwells89 3y ago
  It’s not JS itself that’s the problem, it’s the need to write it to fill gaps in browser facilities. Rather than there be 10k different implementations of a scrolling recycler list of wildly varying quality, there could just be one in each browser engine that web devs can rely on, allowing them to instead focus on writing application code.
  - deadbabe 3y ago
    Even if those facilities were available wouldn’t the complaints then shift to some other high level facility not being available natively?
    - jwells89 3y ago
      It’d be rinse-and-repeat until browsers had a decent toolkit out of the box, yes. That doesn’t strike me as a bad thing.
    - charcircuit 3y ago
      Yes, and as the next and next gets resolved over time browsers would be easier and faster to develop high quality products on enhancing the value of the web ecosystem.
- lta 3y ago
  What is not ?
- bsimpson 3y ago
  The web was originally a document sharing program for academics. JavaScript was never a "batteries included" language because the web wasn't built as an app platform. It evolved into one, and the platform has improved for app development with things like modules, but it is still part of an ecosystem that expects the developer to bring the app framework. Custom Elements tried to solve this, but React came and solved the same problem in a more ergonomic way. So now, we're in the same place: apps are built with open source stacks like React where you have to bring your own toolkit because the browser doesn't make assumptions about which one you're using. The web is a lot like Linux: it evolved as thousands of developers try thousands of different ways of doing things. Some of those things are great and become de facto standards, but it's an ecosystem you can't manage top-down. If you've ever worked at Google, there's a famous internal deck about how decentralized ecosystems evolve like an amorphous slime mold. It's written in the context of Google product management, but it applies to things like Linux, and the web too.
- behnamoh 3y ago
  > What’s wrong with Javascript Javascript.
flawn 3y ago
Flutter is pretty strong with it's out-of-the box APIs as they have a custom render engine. Together with WebAssembly (& alternatives like Flutter) the bare-bonedness shouldn't be a problem anymore.
auggierose 3y ago
I find that developing with Electron is a much nicer experience than developing for Apple UIs. And I've written my share of iOS/iPad apps starting over 15 years ago. The nice thing about the Web is that there usually is a library/framework that fits your needs (Electron, for example). For Apple, often there is no good library. Also SwiftUI is so buggy. React just works, and is conceptually simpler (folks, two-way data binding is a bad idea). Apple has this whole idea of making everything simpler for you, but are often making everything more cumbersome and difficult for you.
- jwells89 3y ago
  > For Apple, often there is no good library. Do you have examples? I’ve not often run into this in my projects. These days there’s Swift packages for most things, and in the worst case I’ll have to write a simple wrapper around some C or C++ library. SwiftUI is still green yes, which is why I’ve stuck to UIKit for anything moderately complex.
  - auggierose 3y ago
    I stopped coding in Swift about 3 years ago, and SwiftUI was green then, too. I don't expect it to become much better soon. Not much comes to mind right now in terms of libraries, I just remember constantly thinking that on the Web it is just an "npm install" away, while in Swift I would just have to code it up myself. UIKit is powerful, of course, but just requires too much ceremony most of the time. And SwiftUI is just not reliable. Writing wrappers for C libraries is not my thing, thinking about all implications of different memory models etc. is exhausting, and I'd rather not waste my time on low-level stuff like that if it can be avoided. Mostly I am thinking about how easy it is to do UI stuff in React, it's much simpler and quicker. The ceremony that XCode and UIKit require are exhausting, as well. Why exactly do I have to give 100 different icons via drag'n'drop for my app? Funny, the Electron app only requires one icon, and I just place it in the right path. What's a PITA in JavaScript is the commonjs / ecmascript modules mess, but I have a standard template now for coding up a module so that it works for both, and since then I much prefer npm over the Swift package manager, as well. Coding in the Apple ecosystem just feels sluggish to me now. It feels like the equivalent of a luxury prison. Being able to access things like general compute shaders via Metal is the only thing I miss, but I think via WebGPU this will be fixed soon enough, and in a cross-platform way at that. Just like Electron runs everywhere, not just on my Mac. So what if it is 200MB large compared to a few kilobytes? That doesn't really matter. That's a one time price you pay, and it is well worth it.
skydhash 3y ago
> For example, I don’t see why browsers can’t furnish basic list and table views that are capable of efficiently recycling their cells without any (or extremely minimal) JavaScript. The web was built with documents in mind, so that the html files already has all the data needed for display. The tables are already populated with all the data needed and in the correct order from the server. There is no need for recycling cells and rows. And all of that is snappy because we're talking about KBs of data for thousands of rows.
- jwells89 3y ago
  Even static pages can get to be too large with a certain number of rows and would benefit from a variant of HTML’s table element that automatically recycles rows while displaying static data. The problem isn’t the size of the transmitted data but the strain the resulting page puts on the browser engine due to the huge number of DOM nodes.

deadbabe 3y ago

What’s wrong with Javascript

vorticalbox 3y ago
Nothing really but lots of it is not a nice experience.
jwells89 3y ago
It’s not JS itself that’s the problem, it’s the need to write it to fill gaps in browser facilities. Rather than there be 10k different implementations of a scrolling recycler list of wildly varying quality, there could just be one in each browser engine that web devs can rely on, allowing them to instead focus on writing application code.
- deadbabe 3y ago
  Even if those facilities were available wouldn’t the complaints then shift to some other high level facility not being available natively?
  - jwells89 3y ago
    It’d be rinse-and-repeat until browsers had a decent toolkit out of the box, yes. That doesn’t strike me as a bad thing.
  - charcircuit 3y ago
    Yes, and as the next and next gets resolved over time browsers would be easier and faster to develop high quality products on enhancing the value of the web ecosystem.
lta 3y ago
What is not ?
bsimpson 3y ago
The web was originally a document sharing program for academics. JavaScript was never a "batteries included" language because the web wasn't built as an app platform. It evolved into one, and the platform has improved for app development with things like modules, but it is still part of an ecosystem that expects the developer to bring the app framework. Custom Elements tried to solve this, but React came and solved the same problem in a more ergonomic way. So now, we're in the same place: apps are built with open source stacks like React where you have to bring your own toolkit because the browser doesn't make assumptions about which one you're using. The web is a lot like Linux: it evolved as thousands of developers try thousands of different ways of doing things. Some of those things are great and become de facto standards, but it's an ecosystem you can't manage top-down. If you've ever worked at Google, there's a famous internal deck about how decentralized ecosystems evolve like an amorphous slime mold. It's written in the context of Google product management, but it applies to things like Linux, and the web too.
behnamoh 3y ago
> What’s wrong with Javascript Javascript.

flawn 3y ago

Flutter is pretty strong with it's out-of-the box APIs as they have a custom render engine. Together with WebAssembly (& alternatives like Flutter) the bare-bonedness shouldn't be a problem anymore.

auggierose 3y ago

I find that developing with Electron is a much nicer experience than developing for Apple UIs. And I've written my share of iOS/iPad apps starting over 15 years ago. The nice thing about the Web is that there usually is a library/framework that fits your needs (Electron, for example). For Apple, often there is no good library. Also SwiftUI is so buggy. React just works, and is conceptually simpler (folks, two-way data binding is a bad idea). Apple has this whole idea of making everything simpler for you, but are often making everything more cumbersome and difficult for you.

jwells89 3y ago
> For Apple, often there is no good library. Do you have examples? I’ve not often run into this in my projects. These days there’s Swift packages for most things, and in the worst case I’ll have to write a simple wrapper around some C or C++ library. SwiftUI is still green yes, which is why I’ve stuck to UIKit for anything moderately complex.
- auggierose 3y ago
  I stopped coding in Swift about 3 years ago, and SwiftUI was green then, too. I don't expect it to become much better soon. Not much comes to mind right now in terms of libraries, I just remember constantly thinking that on the Web it is just an "npm install" away, while in Swift I would just have to code it up myself. UIKit is powerful, of course, but just requires too much ceremony most of the time. And SwiftUI is just not reliable. Writing wrappers for C libraries is not my thing, thinking about all implications of different memory models etc. is exhausting, and I'd rather not waste my time on low-level stuff like that if it can be avoided. Mostly I am thinking about how easy it is to do UI stuff in React, it's much simpler and quicker. The ceremony that XCode and UIKit require are exhausting, as well. Why exactly do I have to give 100 different icons via drag'n'drop for my app? Funny, the Electron app only requires one icon, and I just place it in the right path. What's a PITA in JavaScript is the commonjs / ecmascript modules mess, but I have a standard template now for coding up a module so that it works for both, and since then I much prefer npm over the Swift package manager, as well. Coding in the Apple ecosystem just feels sluggish to me now. It feels like the equivalent of a luxury prison. Being able to access things like general compute shaders via Metal is the only thing I miss, but I think via WebGPU this will be fixed soon enough, and in a cross-platform way at that. Just like Electron runs everywhere, not just on my Mac. So what if it is 200MB large compared to a few kilobytes? That doesn't really matter. That's a one time price you pay, and it is well worth it.

skydhash 3y ago

> For example, I don’t see why browsers can’t furnish basic list and table views that are capable of efficiently recycling their cells without any (or extremely minimal) JavaScript. The web was built with documents in mind, so that the html files already has all the data needed for display. The tables are already populated with all the data needed and in the correct order from the server. There is no need for recycling cells and rows. And all of that is snappy because we're talking about KBs of data for thousands of rows.

jwells89 3y ago
Even static pages can get to be too large with a certain number of rows and would benefit from a variant of HTML’s table element that automatically recycles rows while displaying static data. The problem isn’t the size of the transmitted data but the strain the resulting page puts on the browser engine due to the huge number of DOM nodes.