5 ms·

"Write once. Deploy everywhere."... I've heard this too many times to take it seriously anymore.

nu11ptr 5y ago
I'm still a fan of this concept, but I think you have to keep your expectations realistic. You are likely going to have to make some platform specific considerations, just a lot less than without an abstraction technology. Generally, I've found this manageable, but it can be hard to pull off well for sure. Some have succeeded rather well I think (Java comes to mind). Native GUI frameworks can be more of a challenge. Still, if you want a native L&F your alternative is to code each platform individually, then something like this (or wxWidgets/SWT/etc.) is likely to be a lot less work (but likely to look a bit less native). Trade offs. Good to have choices I think.
y4mi 5y ago
"write once, deploy everywhere [you've got the same kind of hardware or machine available so that the code will work without recompilation and won't look too out of place]" just doesn't have the same ring to it...
mrtksn 5y ago
It never works well because the platforms are not simply the same thing by different companies but they all have their concurrent ideas, conventions and differences. The toolset for "Write once. Deploy everywhere." that works is HTML + JS + CSS and nothing else. This is because browsers work about the same everywhere. IMHO if an app is not going to leverage the platform but will simply show some UI to display or collect data, the way to do it is HTML + JS + CSS in the browser. When you try to support platform specific features, you end up doing much more work but instead of working on the primary App, you spend you time on integration and replication of platform behaviour or functions.
- c-smile 5y ago
  There are two major types of application: one where users play role of "reader" and second type is where user is "writer" - creator of some data, document, etc. > that works is HTML + JS + CSS and nothing else. That type of UI mostly works for "reader" applications - when maximum what you do is clicking on buttons and filling couple of <input>s. For "creator"'s applications, CADs, editors, IDEs, and so on, HTML + JS + CSS is far from being perfect. At least without special means that extend these technologies to acceptable level. Menu shall be menu but not that position:absolute something, dialog shall be modal window, drawing shall support immediate mode, keyboard interaction shall be there, and so forth.
  - mrtksn 5y ago
    My App definition was a bit too narrow maybe, games too tend to be multi platform. I think that’s possible when the App and user interaction model is completely custom - like shooting zombies or drawing 3D shapes. That's also party why browsers can't replace every app(the browsers have it's own opinion about the UI and interactions), the other reasons are performance and access limitations.
zerkten 5y ago
It's not worth taking seriously for app development where you gain advantages from the native experience. This rules it out as a primary app development platform for the majority of developers. It's very strong for the many "good enough" scenarios that range from complete products in domains like pharma where users will tolerate user experience glitches as long as they can be using the same Pandas code behind the scenes on multiple OSes, or utility-level apps that need to run on multiple platforms. These are often tucked away in places that HN readers are averse to exploring from a career perspective.
deleted 5y ago
[deleted]

I'm still a fan of this concept, but I think you have to keep your expectations realistic. You are likely going to have to make some platform specific considerations, just a lot less than without an abstraction technology. Generally, I've found this manageable, but it can be hard to pull off well for sure. Some have succeeded rather well I think (Java comes to mind). Native GUI frameworks can be more of a challenge. Still, if you want a native L&F your alternative is to code each platform individually, then something like this (or wxWidgets/SWT/etc.) is likely to be a lot less work (but likely to look a bit less native). Trade offs. Good to have choices I think.

y4mi 5y ago

"write once, deploy everywhere [you've got the same kind of hardware or machine available so that the code will work without recompilation and won't look too out of place]" just doesn't have the same ring to it...

mrtksn 5y ago

It never works well because the platforms are not simply the same thing by different companies but they all have their concurrent ideas, conventions and differences. The toolset for "Write once. Deploy everywhere." that works is HTML + JS + CSS and nothing else. This is because browsers work about the same everywhere. IMHO if an app is not going to leverage the platform but will simply show some UI to display or collect data, the way to do it is HTML + JS + CSS in the browser. When you try to support platform specific features, you end up doing much more work but instead of working on the primary App, you spend you time on integration and replication of platform behaviour or functions.

c-smile 5y ago
There are two major types of application: one where users play role of "reader" and second type is where user is "writer" - creator of some data, document, etc. > that works is HTML + JS + CSS and nothing else. That type of UI mostly works for "reader" applications - when maximum what you do is clicking on buttons and filling couple of <input>s. For "creator"'s applications, CADs, editors, IDEs, and so on, HTML + JS + CSS is far from being perfect. At least without special means that extend these technologies to acceptable level. Menu shall be menu but not that position:absolute something, dialog shall be modal window, drawing shall support immediate mode, keyboard interaction shall be there, and so forth.
- mrtksn 5y ago
  My App definition was a bit too narrow maybe, games too tend to be multi platform. I think that’s possible when the App and user interaction model is completely custom - like shooting zombies or drawing 3D shapes. That's also party why browsers can't replace every app(the browsers have it's own opinion about the UI and interactions), the other reasons are performance and access limitations.

zerkten 5y ago

It's not worth taking seriously for app development where you gain advantages from the native experience. This rules it out as a primary app development platform for the majority of developers. It's very strong for the many "good enough" scenarios that range from complete products in domains like pharma where users will tolerate user experience glitches as long as they can be using the same Pandas code behind the scenes on multiple OSes, or utility-level apps that need to run on multiple platforms. These are often tucked away in places that HN readers are averse to exploring from a career perspective.

deleted 5y ago

[deleted]