6 ms·

The Persistent Gravity of Cross Platform

91 points by Aaronn 5y ago

pantulis 5y ago
This hits the nail. Cross-platform as a cheaper option only comes true if the multi-platform feature delivers real value to the users --which is obviosly the wager that Agile Bits is doing. Otherwise someone else is bound to deliver a similar feature set either with a less price point or with better execution using native frameworks. Counterpoint: multiplatform frameworks are web-based and thus are easier to learn and have more developer mindshare than native frameworks. But native frameworks are not that much more complicated these days and can use proprietary services: would you roll your own sync or use CloudKit?
- nvrspyx 5y ago
  > would you roll your own sync or use CloudKit? CloudKit is definitely satisfactory, but it's limited to Apple devices. I don't know much about the space, so I may misunderstand the following technologies, but I wish more apps used P2P protocols like IPFS, Hypercore, etc. to keep my devices in sync with an optional pick-your-own-cloud-backup as well, so I can just use Dropbox, Google Drive, OneDrive, etc. The latter seemed to be pretty popular amongst developers for syncing (i.e. pick your cloud backup service) not too long ago and while there's still apps that do this, like Notability, I don't know why so many developers moved to rolling their own sync.
  - dividedbyzero 5y ago
    > I don't know why so many developers moved to rolling their own sync. Sync is great for justifying a paid subscription model
    - pantulis 5y ago
      Also, rolling your own sync is basically a must on multiplatform, I'd say.
  - pantulis 5y ago
    > CloudKit is definitely satisfactory, but it's limited to Apple devices. That was my point, exactly. If you target only specific platform users, easier development (ie, using Electron and web technologies) does not necessarily win over native frameworks because now they are decorated with powerful vendor services. Obviously if your target is multiple platforms, you are now on Electron land. That's not a bad thing per se, though.
- PaulDavisThe1st 5y ago
  > Counterpoint: multiplatform frameworks are web-based Qt, GTK, FLTK, JUCE, NTK, libui are not web-based. I think that there's more than one definition of "multiplatform" floating around here.
api 5y ago
There is absolutely no reason we can't have a very good lightweight native UI compatibility layer. Look at this heroic effort by a single developer: https://github.com/andlabs/libui https://github.com/andlabs/libui It's not there, but it's probably too big of a project for one person.
- user-the-name 5y ago
  There are a million reasons. The main one being that you can't put the same UI on different platforms and have it fit in, no matter how well you use the native components. The components are just one part of what makes up a UI. Different platforms have different conventions of how they are used on a higher level, and how everything fits into the rest of the platform UI.
- jancsika 5y ago
  > It's not there, but it's probably too big of a project for one person. I mean, just take a single subset of functionality like handling multi-touch input. It's probably an hour or two to read through the Pointer Events[1] spec until you get a better idea of why that API was designed the way it was. Now imagine coming up with such a design after at least dozens of hours studying the limitations of prior APIs (but probably more than that). And now, imagine either a) conceiving of and implementing that design (at least dozens of hours, probably way more), or b) cloning that design (still dozens of hours to implement). Now compare to the minutes it takes to read a tutorial and start using the API in a browser that probably already runs on probably any modern device that has a screen. That's just one cross-platform API, and probably not in the top ten to implement first. 1: https://w3c.github.io/pointerevents/ https://w3c.github.io/pointerevents/
- twic 5y ago
  There have been many attempts to build such things, going back decades. None have really succeeded. I am no expert, but my understanding is that it's easy to get to 75%, but extremely hard to get to 100%, or even 95%. Not to mention that there are some differences between layout and navigation idioms on different platforms. Making an app truly native is not just a matter of using native widgets. I do wonder if there is mileage in building an abstraction layer at a much higher level than a widget toolkit. Imagine being able to write a very abstract description of your app in some DSL, saying what screens it has, how they are linked, what information is on each one, and then having tools to compile that down to appropriate native code.
d--b 5y ago
I can't help but believe that the native vs crossplatform tradeoff will eventually go away when someone does a good enough crossplatform library... Video games are cross-platform and polished and fast and they have been so for a while now. When someone comes up with a Unity for desktop applications, that's when this problem is going to go away. I hope Sciter.Js is going to be it.
- Zababa 5y ago
  Video games often have not that much consistency between each others, aside from a few basic keys. Thus, they haven't really solved the tradeoff. Part of the complaint against the cross-platform apps is that you have to adapt yourself to the workflow of the app, instead of the app having to adapt itself to the workflow of the platform.
  - d--b 5y ago
    Sure, though it's debatable that it's a plus. I switch between computers often, and I am happy that my spotify looks the same here and there. I really don't want my spotify app to feel like gimp on Linux and like Excel on Windows...
    - Zababa 5y ago
      That's true. I'm personally happy enough that I get to have almost all of the apps I need on Linux with this cross-platform trend. I also use Linux at home and Windows at work, so a cross-platform experience fits me. But I can see how it's frustrating to be left behind when you were used to your platform and people adapting their software to it. For videogames, I think it makes sense that many have different controls. Trying to force the same controls would make some very hard to play. But I can see people arguing that most apps aren't as specialized as video games, and thus shouldn't need this level of personalization. There is the same argument to be made with special fonts for your apps, vs trying as much as you can to use the system ones.
    - robertlagrant 5y ago
      To give a counterexample, Microsoft Teams notifications on MacOS can't be dragged offscreen; I have to wait for them to vanish. They're not using the native notifications tech (who knows why), and so they're jarring compared to all the nice MacOS applications.
Zababa 5y ago
That's a great article. I think I understand better the anger that certain people (often mac users) express when a product switches from a native app to a cross-platform app. I always thought it was about cost, and that the solution was to pay more. But it seems to be about the business thinking they know better than the user what a good user experience is. If you're picking a platform for the consistency of user experience, I understand how frustrating (and patronizing) that can feel. I want to apologize to the few people that I talked to about this here on HN. I didn't understood your side.
vemv 5y ago
Shipping a whole browser engine along with arbitrary Node.js dependencies doesn't seem exactly a safe recipe for a password manager.
- yunohn 5y ago
  Why? Those dependencies are locked and not going to auto-update themselves.
  - vemv 5y ago
    Even a specific dependency can sneak malicious code. For example foo-2.3.1 when distributed over npm is not guaranteed to match its source over github. Here's a popular piece explaining various plausible scenarios https://medium.com/hackernoon/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5 https://medium.com/hackernoon/im-harvesting-credit-card-numb... (npm is not different from cocoapods I guess... except that npm dependency trees are famed for its size/depth)
    - yunohn 5y ago
      That’s not how electron works - it bundles dependencies. Like any other app bundle (exe, msi, dmg). Same goes for non-electron websites (/apps). I guess there’s a way to also auto-update those, but that defeats the goal of using Electron - reproducible, predictable app builds to ship to consumers.
    - danShumway 5y ago
      Evergreen reminder that with just a little bit of work to avoid platform-specific native-compiled dependencies and Node-Gyp, you can vendor your dependencies for non-library Node projects, and sometimes you should. Certainly, Electron apps themselves should not be pulling dependencies at install time, those should be bundled into the app, that's the whole point of Electron. But they also don't need to pull their dependencies from the official NPM repos at build time either. You don't technically even need NPM installed on anything other than your dev machines, Node's dependency resolution during builds and at runtime doesn't rely on NPM at all. I think some languages (Go springs to mind) are starting to slightly popularize dependency vendoring more, and at one point this was the official recommendation for Node apps/websites in the official docs. It fell out of fashion for some reason, but I think a lot of orgs would benefit from picking up the practice again. It's also a good way to be a lot more deliberate about what you install, and a good way to make sure that new dependencies don't get snuck in without anyone noticing. It's very hard to hide a giant commit that introduces a thousand new files, and that can sometimes be a good opportunity to take a step back and ask yourself why you're adding a dependency that introduces thousands of files.
Ericson2314 5y ago
I worry that everyone is trained for web, no one is trained to write native apps outside of phones, and so the problem will become harder to correct.
- horsawlarway 5y ago
  I don't actually know that this is a problem. The web is a pretty damn good distribution method for software. The user simply clicks a link and is provided with valuable features. No install process. No IT approval process. No thought at all, really, about how that code runs on their machine and does things that are valuable to them. Frankly - We're still inching towards the browser being the OS. I don't want a clunky app that needs to be installed on all my devices, and which has a limited feature set compared to the web: I just want the website. And for the vast majority of "productivity" tools - networking and sharing aren't backseat things, they're literally the most important part of the product (see Figma, for example) --- Long story short, you're saying this is a "problem to correct". I disagree - I think the problem these tools are correcting is that native distribution methods (up to and including the current mobile walled-garden app-store fuckery) simply suck. They suck SO much compared to simply opening a Url in a browser.
  - zepto 5y ago
    The web is more fickle and opaque than the App Store. It’s still a great way to deliver certain kinds of application, but we need an alternative.
    - horsawlarway 5y ago
      > The web is more fickle and opaque than the App Store. You have some examples of what you mean by fickle? I'm not really sure I understand. In basically every situation I can think of, the browser is less fickle, more consistent, and more backwards compatible than an app store. The only benefit to using an app over a website is offline access - which is moot if you don't have the app installed already, since the app download will certainly be bigger than the page load, and it's also the problem electron nicely solves for those cases.
stkdump 5y ago
Often the choice is between a cross-platform app vs a native Windows application only. That is because Mac users are of course important, but maybe not enough to pay for a separate native Mac app.
- SavantIdiot 5y ago
  Some companies use Java as cross-platform, STMicro comes to mind. Their stuff is wonky, and that's possibly because they don't have committed UI/UX designers, but it is consistent cross-platform.
jagger27 5y ago
It's hard to justify my desire for awesome Mac-only apps without considering the spectre of future Apple lock in. Electron has made it possible to use a lot of apps that otherwise wouldn't have been ported to Linux work with no hassle, and for that I'm grateful. I have only recently been able to comfortably run Linux full time. My dev experience on Linux is effectively identical to what I do on macOS: Docker, VSCode, Alacritty, and Discord (to talk to my team). Of course Discord and VSCode are both Electron apps, and Docker just lives on the command line. Alacritty, on the other hand, is an extremely interesting example to me, as it is a true native program that uses cross-platform GPU acceleration through OpenGL. I feel that route is overlooked as a path towards compatibility for a lot of programs outside of games.
- vivty 5y ago
  I prefer apps built using APIs like Vulkan or OpenGL to apps built using electron because they do not feel as sluggish. I think the Blender UI also uses OpenGL to render the interface. One criticism of this approach that has come up in many threads on the same topic however was the lack of accessibility. This is a big pro for electron (and also native development).
  - robertlagrant 5y ago
    I really feel as though Vulkan is a brilliant leveller, with the chance to replace DirectX with a cross-platform, open source standard, funded by Valve and Sony? Sign me up.
    - pjmlp 5y ago
      I really don't get where you got the information that Sony cares about Vulkan, Playstation uses its own 3D API.
      - robertlagrant 5y ago
        Errrr yes! You're totally right. Thought I read that they were contributing, but I must've dreamed it.
travisgriggs 5y ago
> “What is it about enterprise companies that make so many of them abandon native apps, when they could surely afford to develop one app for each platform?” If this is the case though, why when I follow links to strong web apps like Twitter and reddit and Facebook, do I got plagued with “try the app! It’s better!” prompts? I developed/maintain 2 apps that both have native variants. So 4 apps total. And I often bemoan the duplicity and wonder if we shouldn’t unify them. But then I see that the web guys are still pushing me to use native apps. I find it very circular/confusing.
- danybittel 5y ago
  I think that's pure marketing. If you download a "native" app, you're more committed to their product. And they can show an icon on your home screen. It is probably more comparable to a bookmark.
- dividedbyzero 5y ago
  Native apps can keep users more engaged (think notifications) and collect more and better data on them
- wmf 5y ago
  Besides what other people said, mobile apps have unblockable ads. The app is better... for them.
ryandrake 5y ago
> Inconsistencies both small and large had crept into our apps over time. From small things like password strength being different between platforms to larger things like differences in search results and entire missing features. The solution that has worked well for me in the past, has been: 1. Keep all of your business logic and as much of the rest of your code as possible in platform-neutral C or C++: Something you can call into from all native platforms. 2. Write a very small layer of code using the native language/frameworks to do the UI and interact with platform-specific APIs. This has a few advantages: You get a single code base, for the most part, to maintain. You have the opportunity to implement as native a look-and-feel as you want, on each platform if you want. Most of your application is C or C++ so you don't need a team with deep expertise in multiple languages. Most of your development should be on the business logic, right? This architecture also lets you easily add a command-line version of your product, for example to help with automated testing of your business logic. And finally, you don't have to ship a huge, memory-devouring browser and JavaScript stack with your application--your users will thank you. It's not rocket science or anything to be terrified of! I think people too quickly dismiss cross-platform native because they imagine re-writing their application in 3-4 different languages, but it doesn't have to be that way.
- allo37 5y ago
  I had this experience as well! I think a big limitation to this approach is actually finding (competent) C++ devs who are willing to work on mobile, otherwise it works really well.
  - twic 5y ago
    Would it be possible to use Go for this? That compiles to native code, although it does include a much more significant runtime than C, it's safer than C or C++, and it's famously easy for developers to pick up as as second language.
    - nicoburns 5y ago
      Probably not very well, as these solutions typically involve FFI, and integrating thw runtimes would be a big pain. On the other hand, Rust is ideally suited foe this use case. Personally I'd love to see a Rust + react-native combo.
10x-dev 5y ago
In my experience it's the coordination and mental overhead between the platform teams that kills productivity. I suspect that hiring and training cross platform developers, then having them own a feature across all platforms will significantly increase speed of delivery of that feature. These are typically called feature teams and they are most effective when there are backend developers on the team as well. The trade-off is that now the new feature teams are not communicating between each other and coordinating on the common code between them, which starts affecting productivity. In the end, regardless of how the new VP of engineering likes to split the teams and get praised for solving the current problem by introducing another one down the road, the trade off for increased size is loss of productivity due to synchronization overhead between the people involved.
- blacktriangle 5y ago
  I've been the cross-platform dev implementing every feature across 3 platforms, its a miserable job. Besides feeling like you're living through Groundhog Day, the mental burden of constant context switches between languages and APIs wears you down over time, and that's before you look at the effort required to stay current on all your supported platforms. I would never organize a business like that again.
SavantIdiot 5y ago
As long as there are platforms with enough market cap, there will be a need for cross-platform. And the easiest path wins. ElectronJS is the easiest path. My company relies on it.
PaulDavisThe1st 5y ago
The article seems fairly confusing to me. First, I'm not even sure I understand what the author means by "cross-platform". At some point, he mentions Figma and Slack. What platforms are we talking about? Does cross-platform mean "web-based"? Lots of people use Figma's web incarnation ... is that cross-platform? Or is it cross-platform in its "native" Android/iOS apps? More people use Slack in it's app-based incarnation (probably), but those are not implemented with the same tools as the desktop version(s). I suspect the article suffers from the myopia often on display here at HN, in which essentially all software development involves some datastore, a means of entering data (often by one set of users) and a means of display the data in various ways (often by a different set of users). This used to be called "application development" in the 1980s, and these days there's a lot of writing about s/w development (and a lot of comments about that writing) which seems to be based on the idea that this the ONLY kind of s/w development there is. This vision excludes most "creative" software, all gaming software, most development tools, a great deal of technical/scientific computation, a large amount of automation software, and all actual computing platforms (kernels & user-space environments). Those of us who have been doing native desktop application development for decades have an entirely different take on this stuff from people for whom "cross-platform" means "web, android and/or iOS". We're not "more right", but we know about toolkits that work on macOS, windows and linux (gasp!). We've been compiling our software on multiple platforms for a long time, not relying on interpreters and VMs. We've had to grapple with packaging and runtime library questions for longer than web browsers have existed. Electron has got a group of people excited because it appears to move web-based development approaches onto the desktop, which is a totally different model than the one taken when using a cross-desktop-platform toolkit. It doesn't add to the list of such toolkits, it creates a totally different approach to tackling the problem, with the promise that the result could also be used for a web-based version, somehow. In my case, having been developing a "creative" application for 20+ years that runs on windows, macOS and linux via a cross-platform GUI toolkit (and C++), switching to a model that included web front ends (e.g. Electron) let alone mobile platforms, would be even more disruptive than just switching to another of the existing desktop cross-platform GUI toolkits, and in that sense, it's essentially a new development process entirely.
munificent 5y ago
This is a really really good article: > “What is it about enterprise companies that make so many of them abandon native apps, when they could surely afford to develop one app for each platform?” Another way to think about the article's thesis is that organizations never deal directly in simple "costs", like "Can I afford to spend X on Y?" They always evaluate in terms of opportunity cost, "Would I rather spend X on Y or Z?" Once you frame it like that, you realize that the choice between native versus cross-platform is, as the author states, often a choice between fidelity and velocity. And in today's software environment where hardware and user needs change very quickly, velocity often wins.
stephc_int13 5y ago
Cross-Platform versus Native is a false choice. It is perfectly possible to do both. You don't have to use something like Electron or even Qt to make cross platform apps or games.
rkangel 5y ago
The confusion factor here is that 'cross-platform' has become fairly synonymous with 'Electron' (if desktop is one of your targets). It is possible to build cross-platform stuff that is performant. In the past I used wxWidgets for the classic Enterprise app that was cross-platform between Windows and Linux. The UI wasn't the prettiest thing in the world (you regularly end up with dated looking widgets) but it was snappy, and the UX was good. It's continuously astonishing to me that there isn't another workable UI platform that doesn't require bringing a whole browser. Or is the HTML/CSS/JS UI the killer feature because you can share things with the browser implementation (or share skills with a browser frontend team)?

91 points by Aaronn 5y ago

This hits the nail. Cross-platform as a cheaper option only comes true if the multi-platform feature delivers real value to the users --which is obviosly the wager that Agile Bits is doing. Otherwise someone else is bound to deliver a similar feature set either with a less price point or with better execution using native frameworks. Counterpoint: multiplatform frameworks are web-based and thus are easier to learn and have more developer mindshare than native frameworks. But native frameworks are not that much more complicated these days and can use proprietary services: would you roll your own sync or use CloudKit?

nvrspyx 5y ago
> would you roll your own sync or use CloudKit? CloudKit is definitely satisfactory, but it's limited to Apple devices. I don't know much about the space, so I may misunderstand the following technologies, but I wish more apps used P2P protocols like IPFS, Hypercore, etc. to keep my devices in sync with an optional pick-your-own-cloud-backup as well, so I can just use Dropbox, Google Drive, OneDrive, etc. The latter seemed to be pretty popular amongst developers for syncing (i.e. pick your cloud backup service) not too long ago and while there's still apps that do this, like Notability, I don't know why so many developers moved to rolling their own sync.
- dividedbyzero 5y ago
  > I don't know why so many developers moved to rolling their own sync. Sync is great for justifying a paid subscription model
  - pantulis 5y ago
    Also, rolling your own sync is basically a must on multiplatform, I'd say.
- pantulis 5y ago
  > CloudKit is definitely satisfactory, but it's limited to Apple devices. That was my point, exactly. If you target only specific platform users, easier development (ie, using Electron and web technologies) does not necessarily win over native frameworks because now they are decorated with powerful vendor services. Obviously if your target is multiple platforms, you are now on Electron land. That's not a bad thing per se, though.
PaulDavisThe1st 5y ago
> Counterpoint: multiplatform frameworks are web-based Qt, GTK, FLTK, JUCE, NTK, libui are not web-based. I think that there's more than one definition of "multiplatform" floating around here.

api 5y ago

There is absolutely no reason we can't have a very good lightweight native UI compatibility layer. Look at this heroic effort by a single developer: https://github.com/andlabs/libui https://github.com/andlabs/libui It's not there, but it's probably too big of a project for one person.

user-the-name 5y ago
There are a million reasons. The main one being that you can't put the same UI on different platforms and have it fit in, no matter how well you use the native components. The components are just one part of what makes up a UI. Different platforms have different conventions of how they are used on a higher level, and how everything fits into the rest of the platform UI.
jancsika 5y ago
> It's not there, but it's probably too big of a project for one person. I mean, just take a single subset of functionality like handling multi-touch input. It's probably an hour or two to read through the Pointer Events[1] spec until you get a better idea of why that API was designed the way it was. Now imagine coming up with such a design after at least dozens of hours studying the limitations of prior APIs (but probably more than that). And now, imagine either a) conceiving of and implementing that design (at least dozens of hours, probably way more), or b) cloning that design (still dozens of hours to implement). Now compare to the minutes it takes to read a tutorial and start using the API in a browser that probably already runs on probably any modern device that has a screen. That's just one cross-platform API, and probably not in the top ten to implement first. 1: https://w3c.github.io/pointerevents/ https://w3c.github.io/pointerevents/
twic 5y ago
There have been many attempts to build such things, going back decades. None have really succeeded. I am no expert, but my understanding is that it's easy to get to 75%, but extremely hard to get to 100%, or even 95%. Not to mention that there are some differences between layout and navigation idioms on different platforms. Making an app truly native is not just a matter of using native widgets. I do wonder if there is mileage in building an abstraction layer at a much higher level than a widget toolkit. Imagine being able to write a very abstract description of your app in some DSL, saying what screens it has, how they are linked, what information is on each one, and then having tools to compile that down to appropriate native code.

d--b 5y ago

I can't help but believe that the native vs crossplatform tradeoff will eventually go away when someone does a good enough crossplatform library... Video games are cross-platform and polished and fast and they have been so for a while now. When someone comes up with a Unity for desktop applications, that's when this problem is going to go away. I hope Sciter.Js is going to be it.

Zababa 5y ago
Video games often have not that much consistency between each others, aside from a few basic keys. Thus, they haven't really solved the tradeoff. Part of the complaint against the cross-platform apps is that you have to adapt yourself to the workflow of the app, instead of the app having to adapt itself to the workflow of the platform.
- d--b 5y ago
  Sure, though it's debatable that it's a plus. I switch between computers often, and I am happy that my spotify looks the same here and there. I really don't want my spotify app to feel like gimp on Linux and like Excel on Windows...
  - Zababa 5y ago
    That's true. I'm personally happy enough that I get to have almost all of the apps I need on Linux with this cross-platform trend. I also use Linux at home and Windows at work, so a cross-platform experience fits me. But I can see how it's frustrating to be left behind when you were used to your platform and people adapting their software to it. For videogames, I think it makes sense that many have different controls. Trying to force the same controls would make some very hard to play. But I can see people arguing that most apps aren't as specialized as video games, and thus shouldn't need this level of personalization. There is the same argument to be made with special fonts for your apps, vs trying as much as you can to use the system ones.
  - robertlagrant 5y ago
    To give a counterexample, Microsoft Teams notifications on MacOS can't be dragged offscreen; I have to wait for them to vanish. They're not using the native notifications tech (who knows why), and so they're jarring compared to all the nice MacOS applications.

Zababa 5y ago

That's a great article. I think I understand better the anger that certain people (often mac users) express when a product switches from a native app to a cross-platform app. I always thought it was about cost, and that the solution was to pay more. But it seems to be about the business thinking they know better than the user what a good user experience is. If you're picking a platform for the consistency of user experience, I understand how frustrating (and patronizing) that can feel. I want to apologize to the few people that I talked to about this here on HN. I didn't understood your side.

vemv 5y ago

Shipping a whole browser engine along with arbitrary Node.js dependencies doesn't seem exactly a safe recipe for a password manager.

yunohn 5y ago
Why? Those dependencies are locked and not going to auto-update themselves.
- vemv 5y ago
  Even a specific dependency can sneak malicious code. For example foo-2.3.1 when distributed over npm is not guaranteed to match its source over github. Here's a popular piece explaining various plausible scenarios https://medium.com/hackernoon/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5 https://medium.com/hackernoon/im-harvesting-credit-card-numb... (npm is not different from cocoapods I guess... except that npm dependency trees are famed for its size/depth)
  - yunohn 5y ago
    That’s not how electron works - it bundles dependencies. Like any other app bundle (exe, msi, dmg). Same goes for non-electron websites (/apps). I guess there’s a way to also auto-update those, but that defeats the goal of using Electron - reproducible, predictable app builds to ship to consumers.
  - danShumway 5y ago
    Evergreen reminder that with just a little bit of work to avoid platform-specific native-compiled dependencies and Node-Gyp, you can vendor your dependencies for non-library Node projects, and sometimes you should. Certainly, Electron apps themselves should not be pulling dependencies at install time, those should be bundled into the app, that's the whole point of Electron. But they also don't need to pull their dependencies from the official NPM repos at build time either. You don't technically even need NPM installed on anything other than your dev machines, Node's dependency resolution during builds and at runtime doesn't rely on NPM at all. I think some languages (Go springs to mind) are starting to slightly popularize dependency vendoring more, and at one point this was the official recommendation for Node apps/websites in the official docs. It fell out of fashion for some reason, but I think a lot of orgs would benefit from picking up the practice again. It's also a good way to be a lot more deliberate about what you install, and a good way to make sure that new dependencies don't get snuck in without anyone noticing. It's very hard to hide a giant commit that introduces a thousand new files, and that can sometimes be a good opportunity to take a step back and ask yourself why you're adding a dependency that introduces thousands of files.

Ericson2314 5y ago

I worry that everyone is trained for web, no one is trained to write native apps outside of phones, and so the problem will become harder to correct.

horsawlarway 5y ago
I don't actually know that this is a problem. The web is a pretty damn good distribution method for software. The user simply clicks a link and is provided with valuable features. No install process. No IT approval process. No thought at all, really, about how that code runs on their machine and does things that are valuable to them. Frankly - We're still inching towards the browser being the OS. I don't want a clunky app that needs to be installed on all my devices, and which has a limited feature set compared to the web: I just want the website. And for the vast majority of "productivity" tools - networking and sharing aren't backseat things, they're literally the most important part of the product (see Figma, for example) --- Long story short, you're saying this is a "problem to correct". I disagree - I think the problem these tools are correcting is that native distribution methods (up to and including the current mobile walled-garden app-store fuckery) simply suck. They suck SO much compared to simply opening a Url in a browser.
- zepto 5y ago
  The web is more fickle and opaque than the App Store. It’s still a great way to deliver certain kinds of application, but we need an alternative.
  - horsawlarway 5y ago
    > The web is more fickle and opaque than the App Store. You have some examples of what you mean by fickle? I'm not really sure I understand. In basically every situation I can think of, the browser is less fickle, more consistent, and more backwards compatible than an app store. The only benefit to using an app over a website is offline access - which is moot if you don't have the app installed already, since the app download will certainly be bigger than the page load, and it's also the problem electron nicely solves for those cases.

stkdump 5y ago

Often the choice is between a cross-platform app vs a native Windows application only. That is because Mac users are of course important, but maybe not enough to pay for a separate native Mac app.

SavantIdiot 5y ago
Some companies use Java as cross-platform, STMicro comes to mind. Their stuff is wonky, and that's possibly because they don't have committed UI/UX designers, but it is consistent cross-platform.

jagger27 5y ago

It's hard to justify my desire for awesome Mac-only apps without considering the spectre of future Apple lock in. Electron has made it possible to use a lot of apps that otherwise wouldn't have been ported to Linux work with no hassle, and for that I'm grateful. I have only recently been able to comfortably run Linux full time. My dev experience on Linux is effectively identical to what I do on macOS: Docker, VSCode, Alacritty, and Discord (to talk to my team). Of course Discord and VSCode are both Electron apps, and Docker just lives on the command line. Alacritty, on the other hand, is an extremely interesting example to me, as it is a true native program that uses cross-platform GPU acceleration through OpenGL. I feel that route is overlooked as a path towards compatibility for a lot of programs outside of games.

vivty 5y ago
I prefer apps built using APIs like Vulkan or OpenGL to apps built using electron because they do not feel as sluggish. I think the Blender UI also uses OpenGL to render the interface. One criticism of this approach that has come up in many threads on the same topic however was the lack of accessibility. This is a big pro for electron (and also native development).
- robertlagrant 5y ago
  I really feel as though Vulkan is a brilliant leveller, with the chance to replace DirectX with a cross-platform, open source standard, funded by Valve and Sony? Sign me up.
  - pjmlp 5y ago
    I really don't get where you got the information that Sony cares about Vulkan, Playstation uses its own 3D API.
    - robertlagrant 5y ago
      Errrr yes! You're totally right. Thought I read that they were contributing, but I must've dreamed it.

travisgriggs 5y ago

> “What is it about enterprise companies that make so many of them abandon native apps, when they could surely afford to develop one app for each platform?” If this is the case though, why when I follow links to strong web apps like Twitter and reddit and Facebook, do I got plagued with “try the app! It’s better!” prompts? I developed/maintain 2 apps that both have native variants. So 4 apps total. And I often bemoan the duplicity and wonder if we shouldn’t unify them. But then I see that the web guys are still pushing me to use native apps. I find it very circular/confusing.

danybittel 5y ago
I think that's pure marketing. If you download a "native" app, you're more committed to their product. And they can show an icon on your home screen. It is probably more comparable to a bookmark.
dividedbyzero 5y ago
Native apps can keep users more engaged (think notifications) and collect more and better data on them
wmf 5y ago
Besides what other people said, mobile apps have unblockable ads. The app is better... for them.

ryandrake 5y ago

> Inconsistencies both small and large had crept into our apps over time. From small things like password strength being different between platforms to larger things like differences in search results and entire missing features. The solution that has worked well for me in the past, has been: 1. Keep all of your business logic and as much of the rest of your code as possible in platform-neutral C or C++: Something you can call into from all native platforms. 2. Write a very small layer of code using the native language/frameworks to do the UI and interact with platform-specific APIs. This has a few advantages: You get a single code base, for the most part, to maintain. You have the opportunity to implement as native a look-and-feel as you want, on each platform if you want. Most of your application is C or C++ so you don't need a team with deep expertise in multiple languages. Most of your development should be on the business logic, right? This architecture also lets you easily add a command-line version of your product, for example to help with automated testing of your business logic. And finally, you don't have to ship a huge, memory-devouring browser and JavaScript stack with your application--your users will thank you. It's not rocket science or anything to be terrified of! I think people too quickly dismiss cross-platform native because they imagine re-writing their application in 3-4 different languages, but it doesn't have to be that way.

allo37 5y ago
I had this experience as well! I think a big limitation to this approach is actually finding (competent) C++ devs who are willing to work on mobile, otherwise it works really well.
- twic 5y ago
  Would it be possible to use Go for this? That compiles to native code, although it does include a much more significant runtime than C, it's safer than C or C++, and it's famously easy for developers to pick up as as second language.
  - nicoburns 5y ago
    Probably not very well, as these solutions typically involve FFI, and integrating thw runtimes would be a big pain. On the other hand, Rust is ideally suited foe this use case. Personally I'd love to see a Rust + react-native combo.

10x-dev 5y ago

In my experience it's the coordination and mental overhead between the platform teams that kills productivity. I suspect that hiring and training cross platform developers, then having them own a feature across all platforms will significantly increase speed of delivery of that feature. These are typically called feature teams and they are most effective when there are backend developers on the team as well. The trade-off is that now the new feature teams are not communicating between each other and coordinating on the common code between them, which starts affecting productivity. In the end, regardless of how the new VP of engineering likes to split the teams and get praised for solving the current problem by introducing another one down the road, the trade off for increased size is loss of productivity due to synchronization overhead between the people involved.

blacktriangle 5y ago
I've been the cross-platform dev implementing every feature across 3 platforms, its a miserable job. Besides feeling like you're living through Groundhog Day, the mental burden of constant context switches between languages and APIs wears you down over time, and that's before you look at the effort required to stay current on all your supported platforms. I would never organize a business like that again.

SavantIdiot 5y ago

As long as there are platforms with enough market cap, there will be a need for cross-platform. And the easiest path wins. ElectronJS is the easiest path. My company relies on it.

PaulDavisThe1st 5y ago

The article seems fairly confusing to me. First, I'm not even sure I understand what the author means by "cross-platform". At some point, he mentions Figma and Slack. What platforms are we talking about? Does cross-platform mean "web-based"? Lots of people use Figma's web incarnation ... is that cross-platform? Or is it cross-platform in its "native" Android/iOS apps? More people use Slack in it's app-based incarnation (probably), but those are not implemented with the same tools as the desktop version(s). I suspect the article suffers from the myopia often on display here at HN, in which essentially all software development involves some datastore, a means of entering data (often by one set of users) and a means of display the data in various ways (often by a different set of users). This used to be called "application development" in the 1980s, and these days there's a lot of writing about s/w development (and a lot of comments about that writing) which seems to be based on the idea that this the ONLY kind of s/w development there is. This vision excludes most "creative" software, all gaming software, most development tools, a great deal of technical/scientific computation, a large amount of automation software, and all actual computing platforms (kernels & user-space environments). Those of us who have been doing native desktop application development for decades have an entirely different take on this stuff from people for whom "cross-platform" means "web, android and/or iOS". We're not "more right", but we know about toolkits that work on macOS, windows and linux (gasp!). We've been compiling our software on multiple platforms for a long time, not relying on interpreters and VMs. We've had to grapple with packaging and runtime library questions for longer than web browsers have existed. Electron has got a group of people excited because it appears to move web-based development approaches onto the desktop, which is a totally different model than the one taken when using a cross-desktop-platform toolkit. It doesn't add to the list of such toolkits, it creates a totally different approach to tackling the problem, with the promise that the result could also be used for a web-based version, somehow. In my case, having been developing a "creative" application for 20+ years that runs on windows, macOS and linux via a cross-platform GUI toolkit (and C++), switching to a model that included web front ends (e.g. Electron) let alone mobile platforms, would be even more disruptive than just switching to another of the existing desktop cross-platform GUI toolkits, and in that sense, it's essentially a new development process entirely.

munificent 5y ago

This is a really really good article: > “What is it about enterprise companies that make so many of them abandon native apps, when they could surely afford to develop one app for each platform?” Another way to think about the article's thesis is that organizations never deal directly in simple "costs", like "Can I afford to spend X on Y?" They always evaluate in terms of opportunity cost, "Would I rather spend X on Y or Z?" Once you frame it like that, you realize that the choice between native versus cross-platform is, as the author states, often a choice between fidelity and velocity. And in today's software environment where hardware and user needs change very quickly, velocity often wins.

stephc_int13 5y ago

Cross-Platform versus Native is a false choice. It is perfectly possible to do both. You don't have to use something like Electron or even Qt to make cross platform apps or games.

rkangel 5y ago

The confusion factor here is that 'cross-platform' has become fairly synonymous with 'Electron' (if desktop is one of your targets). It is possible to build cross-platform stuff that is performant. In the past I used wxWidgets for the classic Enterprise app that was cross-platform between Windows and Linux. The UI wasn't the prettiest thing in the world (you regularly end up with dated looking widgets) but it was snappy, and the UX was good. It's continuously astonishing to me that there isn't another workable UI platform that doesn't require bringing a whole browser. Or is the HTML/CSS/JS UI the killer feature because you can share things with the browser implementation (or share skills with a browser frontend team)?