4 ms·

Wow, one twitter thread worth reading. I think this is one of the reasons that sincerely the browser should be normalised, have a consistent API across all pla

Wow, one twitter thread worth reading. I think this is one of the reasons that sincerely the browser should be normalised, have a consistent API across all platforms (including performance characteristics, and native things like movement, sound, etc) and continuously improved, it just evens so much the playing field - by extension it would allow people to actually build novel and interesting ways to use a computer instead of figuring out how to build the same goddamned buttons across platforms. You can't just outcompete the deepness of some pockets when you have to juggle turds across so many layers. I never tried flow, I did use Asana and liked it compared to whatever else was there, I think it's a good product, although they might be a bit overboard on the rainbow confetti scale, but I still think all of these platforms sincerely lack an approach to digital organisation, they all still behave like their paper based flows/ideas. Millions upon millions of $ plus human hours, spent on making a todo app working across platforms. It's a waste of human and societal potential.

threeseed 6y ago
> It's a waste of human and societal potential What a ridiculous comment. Productivity apps are the most important apps because they enable others to do great work. It's impossible to collaborate (especially hybrid/remote) without them and when they work poorly they drag good teams down.
- hnedeotes 6y ago
  > What a ridiculous comment. Only topped by a ridiculous english comprehension. Indeed productivity apps are essential for collaboration specially in async and non-local environments. They should be invested in because there's a lot of uncovered potential there still regarding modes of information organisation. What does that have to do with the fact that to deliver that consistently and performantly across different computing platforms you need to produce N variations of your product?
  - threeseed 6y ago
    I don't think your comment was particularly clear. Flow is not just a todo-app. It's a full project management app similar to Jira and I don't think they would've saved a ton of money not building an iOS or Android app.
    - hnedeotes 6y ago
      I have nothing against todo apps, on the contrary! In fact any improvement in that area/tools can easily affect thousands/millions of people, because organising work/projects/collaboration is needed everywhere. What I would wish for was that to develop things that don't require native functionality (e.g. only need storage/ram/connection) that there was a unified, consistent, performant, API that allowed one to program against that, and have the owners of the OS provide that API, in this case the browser would be the closest (and many issues people have with it against native apps are solvable). While it's almost sure that the money and time spent on providing native versions wasn't the sole reason, it just adds a gigantic overhead in many cases - as mentioned in the tweet, it's either time you have your devs dedicate to it instead of all other things, it's the continuous maintenance costs as now instead of having a source of bugs you have N, and new features have to be implemented across N, it's the limitations that it imposes in how and what can be implemented (it has to basically work to the lowest common denominator), the hoops you might need to jump to bring it on pair, and then if you use "wrappers" many times their performance is bad. And if you're using a tool to simplify your work you don't want to be wasting time on every interaction you have with it. Or you can hire a team to do it for you, which brings costs and still management overhead and dependency or you can choose to develop only for web, but this then comes with the issues of not being normalised well enough. Have an WebGL interface that scrolls a container and needs to interact with mouse/motion events? Well, outside of Chrome it's going to suck. And etc... As a consequence, given two ideas that are similar, those with much bigger pockets can outrun the UX and quality of their "adversary" products easily. In the process wasting thousands of hours and $ on just replicating the same thing across platforms. This was my main point!
dimmke 6y ago
It's even worse when you consider that in a very real way, the differences in these platforms largely exist to moat themselves. Apple creates their own programming languages then implements proprietary frameworks inside these languages. So you have developers that really have to specialize in doing that kind of development if you want to do native. So you have an "iOS" team and an "Android" team all to deliver the same thing as your web app but on locked down proprietary devices. It really only serves the phone vendors themselves. But I think React Native/Electron have done a decent job at solving this problem as much as it can be solved. It's important to acknowledge that web standards for html/JS really still aren't geared towards creating fully interactive applications. A lot of what exists is hacks. So I don't think you can fully lay the blame at companies for not wanting to build their platforms entirely on web technologies.
- c-cube 6y ago
  Google is also trying to imitate Apple here, with Dart and flutter. The only reasonable explanation for these (especially Dart being exhumed from its thumb so it can become the only language supported by flutter) is vendor lock in.
  - chgibb 6y ago
    Are you concerned about being locked into Dart as a developer?
- hnedeotes 6y ago
  Yeap, the biggest problem in my view is not the usage of other technologies other than web, is that those technologies don't transfer. I would be fine with other technology that allowed the interop, I've written quite a bit in js and interesting stuff but it's far from being my fav thing for sure. > But I think React Native/Electron have done a decent job at solving this problem as much as it can be solved. Well in a way they do, and I'm not dissing the work done on those fronts, but it's not the same thing. These solutions and development frameworks (even the native ones from the OS venders) are mostly cookie cutter things. They don't really allow for exploring the breadth of what is available on our computers (desktop and pocket) in any meaningful or innovative way when it comes to UX. In the case of Electron and others in the same vein they still circle back, because they're implemented exactly using browser technology. > It's important to acknowledge that web standards for html/JS really still aren't geared towards creating fully interactive applications That also shows how much better it could be if a "building blocks" OS layer/API that is responsibility of the vendor but the same across platforms existed, because you can still build amazing experiences using something that wasn't made for that all. (edit* I mean building blocks not as in "here's an accordion widget, or a button", I mean building blocks to build those things, stop thinking you somehow reached nirvana) Even ancillary projects like browsers would benefit from something like that. Probably this is not in the interest of many different factions due to many different issues and objectives. The internet, the www, and the browser is proof, even with all its warts, that this interoperability is good. Transferable skills are good. Having better foundations is good. Most of the interested companies make billions, they should push this forward. There's plenty to differentiate between competing OS/hardware as it is. Better, more maintainable projects is good. We'll fill the gap of what we don't need to do with more useful work for sure. Native will still make sense for a whole host of things.

threeseed 6y ago

> It's a waste of human and societal potential What a ridiculous comment. Productivity apps are the most important apps because they enable others to do great work. It's impossible to collaborate (especially hybrid/remote) without them and when they work poorly they drag good teams down.

hnedeotes 6y ago
> What a ridiculous comment. Only topped by a ridiculous english comprehension. Indeed productivity apps are essential for collaboration specially in async and non-local environments. They should be invested in because there's a lot of uncovered potential there still regarding modes of information organisation. What does that have to do with the fact that to deliver that consistently and performantly across different computing platforms you need to produce N variations of your product?
- threeseed 6y ago
  I don't think your comment was particularly clear. Flow is not just a todo-app. It's a full project management app similar to Jira and I don't think they would've saved a ton of money not building an iOS or Android app.
  - hnedeotes 6y ago
    I have nothing against todo apps, on the contrary! In fact any improvement in that area/tools can easily affect thousands/millions of people, because organising work/projects/collaboration is needed everywhere. What I would wish for was that to develop things that don't require native functionality (e.g. only need storage/ram/connection) that there was a unified, consistent, performant, API that allowed one to program against that, and have the owners of the OS provide that API, in this case the browser would be the closest (and many issues people have with it against native apps are solvable). While it's almost sure that the money and time spent on providing native versions wasn't the sole reason, it just adds a gigantic overhead in many cases - as mentioned in the tweet, it's either time you have your devs dedicate to it instead of all other things, it's the continuous maintenance costs as now instead of having a source of bugs you have N, and new features have to be implemented across N, it's the limitations that it imposes in how and what can be implemented (it has to basically work to the lowest common denominator), the hoops you might need to jump to bring it on pair, and then if you use "wrappers" many times their performance is bad. And if you're using a tool to simplify your work you don't want to be wasting time on every interaction you have with it. Or you can hire a team to do it for you, which brings costs and still management overhead and dependency or you can choose to develop only for web, but this then comes with the issues of not being normalised well enough. Have an WebGL interface that scrolls a container and needs to interact with mouse/motion events? Well, outside of Chrome it's going to suck. And etc... As a consequence, given two ideas that are similar, those with much bigger pockets can outrun the UX and quality of their "adversary" products easily. In the process wasting thousands of hours and $ on just replicating the same thing across platforms. This was my main point!

dimmke 6y ago

It's even worse when you consider that in a very real way, the differences in these platforms largely exist to moat themselves. Apple creates their own programming languages then implements proprietary frameworks inside these languages. So you have developers that really have to specialize in doing that kind of development if you want to do native. So you have an "iOS" team and an "Android" team all to deliver the same thing as your web app but on locked down proprietary devices. It really only serves the phone vendors themselves. But I think React Native/Electron have done a decent job at solving this problem as much as it can be solved. It's important to acknowledge that web standards for html/JS really still aren't geared towards creating fully interactive applications. A lot of what exists is hacks. So I don't think you can fully lay the blame at companies for not wanting to build their platforms entirely on web technologies.

c-cube 6y ago
Google is also trying to imitate Apple here, with Dart and flutter. The only reasonable explanation for these (especially Dart being exhumed from its thumb so it can become the only language supported by flutter) is vendor lock in.
- chgibb 6y ago
  Are you concerned about being locked into Dart as a developer?
hnedeotes 6y ago
Yeap, the biggest problem in my view is not the usage of other technologies other than web, is that those technologies don't transfer. I would be fine with other technology that allowed the interop, I've written quite a bit in js and interesting stuff but it's far from being my fav thing for sure. > But I think React Native/Electron have done a decent job at solving this problem as much as it can be solved. Well in a way they do, and I'm not dissing the work done on those fronts, but it's not the same thing. These solutions and development frameworks (even the native ones from the OS venders) are mostly cookie cutter things. They don't really allow for exploring the breadth of what is available on our computers (desktop and pocket) in any meaningful or innovative way when it comes to UX. In the case of Electron and others in the same vein they still circle back, because they're implemented exactly using browser technology. > It's important to acknowledge that web standards for html/JS really still aren't geared towards creating fully interactive applications That also shows how much better it could be if a "building blocks" OS layer/API that is responsibility of the vendor but the same across platforms existed, because you can still build amazing experiences using something that wasn't made for that all. (edit* I mean building blocks not as in "here's an accordion widget, or a button", I mean building blocks to build those things, stop thinking you somehow reached nirvana) Even ancillary projects like browsers would benefit from something like that. Probably this is not in the interest of many different factions due to many different issues and objectives. The internet, the www, and the browser is proof, even with all its warts, that this interoperability is good. Transferable skills are good. Having better foundations is good. Most of the interested companies make billions, they should push this forward. There's plenty to differentiate between competing OS/hardware as it is. Better, more maintainable projects is good. We'll fill the gap of what we don't need to do with more useful work for sure. Native will still make sense for a whole host of things.