Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

On the other hand, we could be entering a phase where an open source developer might say "Why bother porting to Windows? Just target Arch/Ubuntu/SUSE."


tl/dr: Simply put, the cross platform distribution problem is solved (in way more ways than one), but I think the combination electron/nw.js + cross-platform-from-the-get-go languages will win, instead of other options like QT. I think it might be a waste of time to target a distribution and hope it gets ported reasonably to Windows, clouding your codebase in the process.

While possibly a highly unpopular opinion, this is where I think solutions like Electron/Node Webkit fit perfectly.I think this is actually kind of already solved (just not with the tools that everyone may want). We shouldn't be even aiming for any particular distribution to begin with, at the expense of a larger executable and less-than-native UI performance, you get write once ship just-about-everywhere when you use tools like electron/node webkit.

Developers often hate web programming, but it's just about the only easy to pick up, and relatively consistent tool for the job of platforms that "just work" (pretty much) everywhere right now. It even seems like the best way to do it going forward, given that:

- Browser companies will work hard towards making browsers faster and efficient, because it's in their best interest (which is the best kind of guarantee).

- Cross-platform minded languages like Go or Rust will become more popular for those who want to get away from using JS at all, and JS could basically become an RPC layer for the "real" application

- Once WASM really takes to the mainstream, languages will just compile it to it. WASM already has LLVM support, so there's a bunch of languages for free already.

So soon, JS won't even be the sticking point in why people dislike distributing cross-platform apps with Electron/NodeJS, then we'll focus on things like executable size and memory usage, and solutions will pop up for those things too.

<tl/dr goes here>


If I wanted bloated UIs that look the same on every platform but integrate poorly with every platform I'd use Java Swing.


Oh yes, I totally forgot, that option has been around forever as well (I only mentioned QT) -- I've only written one non-trivial app in it and it wasn't the worst experience actually (but then again, it was a greenfield project, albeit close to a decade ago now)


The Wheel of Time turns, and Ages come and pass, leaving memories that become legend. Legend fades to myth, and even myth is long forgotten when the Age that gave it birth comes again


Soon to be a TV series.


I'll believe it when I see it


JavaFX has been released almost a decade ago, and it's much nicer to work with. There is really no reason to be using Swing anymore.


Interesting, I wrote in AWT a lifetime ago, and swing was billed as the hot new thing then.


> While possibly a highly unpopular opinion, this is where I think solutions like Electron/Node Webkit fit perfectly.

Well ...: https://twitter.com/jacobrossi/status/851992646151278592


Nothing is secure. That post is basically spreading FUD as far as I'm concerned. There isn't even a point of comparison to any other distribution platform/native toolkit.

I also trust browser vendors to focus on keeping stripped-down versions of their core products secure more than I just joe/jane schmoe the app developer that just learned how to use QT/Swing/whatever.


"I have taken these numbers from a paper I can not publish". (Scroll in comments). That is a good source.


Ah yes Javascript becoming the RPC layer

I sure love my data types of `int` to be IEEE 754 floating point numbers!


I think there is a distinction to make between developers of applications deployed on servers and deployed on desktops. I know the latter category is a dying breed, but still.

With WSL, developers targeting servers do have less of an incentive to port to Windows; but I'd argue that was the trend already, which is why MS is finally coming around.

On the other hand, developers targeting desktops now have more of an incentive to target Windows. A lot of early adopters and peers for these people are power users and other developers, who run Linux or Mac on their desktops as much as (if not more than) Windows. If more of these people move back to Windows because of WSL, desktop developers will have to consider Windows a priority again.

While a lot of the focus of "New MS" is on selling and promoting their cloud services, they are also interested in stemming the bleed on desktop. WSL helps a lot in that regard, IMHO; and as a side effect, it keeps developers on Windows: familiarity is always useful when it comes to peddle other Windows-based solutions. Win-win (for MS).


Not sure how viable that strategy is, considering that WSL is more a developer tool than something normal end users would install. But many open-source developers already don't care about porting to Windows, so not much changes, I guess.


I suspect you will be able to write an installer that enables WSL and installs your application as a Linux app on Windows


I think WSL is a result from the work Microsoft did to run Android apps on Windows. If I'm not mistaken, they decided to scrap that because of this issue, if developers can target Android and run on Windows mobile, why would they target Windows?

I don't think that will be an issue with GUI programs on computers, but it might for CLI programs.


The apps still needed to be recompiled, because Google Play services weren't ported. The iOS bridge is still supported.


This seems to already be happening with Docker. I can think of a couple of Open Source projects where there official Windows installer just installs Docker, a Docker container and a .bat file that starts up and connects to the docker container.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: