React Native for Windows and Mac | Hacker News Reader

React Native for Windows and Mac

microsoft.github.io

715 pointsed477 comments

React Native scares me with its dependency webs:

http://npm.anvaka.com/#/view/2d/react-native

From my experience, it's really great to work with and definitely saves a ton of work, but the depgraph above fills me with doubt for use in sensitive applications such as in finance or healthcare. For this reason, I've been trying out Flutter or even considering to go back to native apps. Perhaps there's some kind of middle ground where we can create a tight microkernel-like thing natively using secure enclaves and key managers, but expose an API to the "untrusted" parts of the program. This approach is not without its own downsides, such as dark patterns in a compromised UI. However, as one friend pointed out, a lot of those deps are indeed for build time only, which have different risk profiles.

The depgraph of reactjs is far simpler and easier for me to understand and therefore feel trust:

http://npm.anvaka.com/#/view/2d/react

Does anyone know if there has been reliable research towards the security of the entire RN dependency tree? Seeing a stray dep there that has 1 maintainer on npm/GitHub who has been inactive for over a year makes me nervous. Any one of those JavaScript projects could do something nefarious deep under the hood, and this to me seems to expose a huge surface area for attackers.

Here's a classic throwback to keep us on our toes :)

https://www.win.tue.nl/~aeb/linux/hh/thompson/trust.html

Wow, that React Native dep graph is crazy!

But as I browse it, most of the dependencies seem to be build-time, not runtime dependencies (i.e. it seems like most of them are related to Babel). The React comparison doesn't include dev dependencies.

While react-native does have more dependencies than vanilla react, on first glance the list doesn't seem too crazy https://github.com/facebook/react-native/blob/master/package...

The package.json file hasn't been remotely close to representative of the actual dependency count of a JS project for years.

sure, but it gives you the list of packages to look at in the dependency visualizer

It gives you a list of directly depended-upon packages. It doesn't give you a list of _those_ packages' dependencies, or _their_ dependencies, which funnily enough also get installed when you install your direct dependencies.

Plus I forgot to address this in my earlier comment: that visualizer only shows dependencies. By default it doesn't load any dev dependencies. You can confirm that for yourself by checking out https://npm.anvaka.com/#/view/2d/rollup for example - only the single runtime dependency on fsevents shows up, the dozens of dev dependencies Rollup has don't.

So yes, React Native does ship that overcomplicated graph of dependencies to all its users. I'll grant that at least _some_ of the code in those dependencies gets tree-shaken out.

Your last paragraph is a bit inaccurate. The dependencies are needed by people developing WITH React Native as opposed to devDependencies (which are for people developing ON React Native). So whilst you will be using the complicated graph of dependencies at some point, that isn't the same as saying they'll be shipped to end users of the app.

The line between dependencies and devDependencies got blurry the second npm packages got used for more than just Node.js itself. What's really needed to remove the ambiguity is something like prodDependencies, which would be a subset of the current dependencies, but I don't know if it's really worth it.

Can you clarify the difference between developing "with" vs "on" react-native?

If you are trying to write an app using react-native, or if you are trying to improve react-native.

Am I the only one who just spent 5 minutes chasing moving nodes round in that graph looking for leftpad.js?

Definitely not.

it's in there, somewhere.. https://github.com/microsoft/react-native-windows/blob/maste...

Why don't people copy the deb-tree to their local repo and/or pin the version that they want, so that they can be free of node terrorists?

EDIT: To be clear - maybe I am REALLY old-school, but every time we did a release, we archived our tool-chain (GCC blah blah, Make blah blah, bash blah blah), our depencies, our vendor libraries and our code, so that IF in 20 years, if we had to rebuild a particular release (12.x) for a particular client (Chase) on a particular platform (AIX), we could do so de novo. Maybe that was overkill, but in a world where everything changes, why wouldn't you snapshot everything for every release?

This makes sense if you're releasing versioned software builds to 3rd parties. If you're running it internally (e.g. as a SaaS company) then there's much less cause to run an old versions, let alone one from 20 years ago.

Yeah. I get that. Getting enterprise people to migrate or go off-prem for everything takes some time. And some like custom versons! I just like to snap-shot everything (including the tool chain) so that I can recreate the past out of my repository at any time for any reason. (I'm weird like that - I expect the same out of legal, ops and accounting as well)

Maybe I'm old - but I don't trust Quickbooks-in-the-Cloud.

EDIT: But I use 'em!

I like this idea. Did you also archive the operating system the build was running on ?

If not, this should be trivial to replicate today using docker containers.

We did! This was before docker. we stuck it on mag-tape and DVD, DVD stayed on-site, and the mag-tape went to Iron Mountain. We had escrow agreements with our customers (Chase, Citi, Amex, HSBC, Deutche, etc.) that if we went tits up, they would get a copy of the code with the docs.

The thing that made it work, though, was the fire-drills. Once a quarter (at the beginning, later it was once a year), we would go buy about 10 servers from dell and set them up in the common-room and say to the employees. "We just got hit by a meteor last night. Get us up from off-sites, including all company documentation. Re-inflate the company in 4 hours. Start Now". Of course we all failed (sometimes the backups didn't even work!), but we got to the point where we could re-inflate the company in four hours. I was so proud of those people.

What a great routine! It's not a backup unless it's regularly tested.

The longer you leave that dependency graph up, the more it starts to look like the Huddle from Inside...

Speaking of trusting trust, I think I'd love for Node¹ to support something like OpenBSD pledge (2) and unveil (2) for imports, where once you enter into a particular package certain capabilities are disabled. I would like to be able to assert that when I import some package, it and all of the packages it recursively includes do not perform network requests, do not use the filesystem outside of some folder, and so on.

A fine grained capability system for packages would dramatically improve the safety profile, and if this were built into package.json and the lockfile we could do the following:

1. Packages advertise what their default capabilities should be limited to 2. Changes in those capabilities are encoded in the package lock file, and can't be changed without the user explicitly affirming them

¹ and other langs with extensive use of package managers and micro-packages

> A fine grained capability system for packages would dramatically improve the safety profile

I think Deno does that (the new project by Node's original creator):

https://blog.logrocket.com/what-is-deno/

Woohoo! I just noticed Deno is at release candidate stage for v1.0.

Deno gives all packages the same permissions of the main app. So if your app can make network requests, so can every dependency you use. It’s not a great situation. I’ve brought this up to them and their response is that per-package permissions would be too difficult to implement.

Yes, checking everyone at the main door is indeed easier than checking everyone at every single point of contact. It needs a vast architectural change compared to current implementation as you need to enforce those rules at runtime!

Well yeah, but I thought the whole point of deno was to make vast architectural changes to allow for increased security. Seems odd to stop half way.

The app design is going to have to change around per-process permissions. build.ts doesn't need the same as main.ts but at that point what are you getting where you couldn't just use docker and abstract that pattern to literally all software and dependencies that aren't in deno.

Maybe it's a start of better tooling? Kicking out a graph of package/permission call stack might be useful to audit

Deno (a modern JS runtime from the same original author as Node) is heading this direction, albeit it’s currently more a traditional opt-in than OpenBSD-style opt-out.

This is a much more productive answer to the node dependency tree question than I'm used to encountering, and it's much more in line with most large modern systems are tending to address security from >1th party sources. Wall it off, require explicit permission, worry more about the security of the sandbox and less about the security of the dependencies. It doesn't address everything (and it becomes a lot riskier when you do give permission), but it's a far better proposal than shouting about how many dependencies are common in the JS ecosystem without any additional steps.

This is a really cool idea.

I like the sound of it, but it seems like it might descend into something like checked exception hell where a given package D works fine as a dependency of package A but not of package B (because package B drops some privileges that D expects to have).

Maybe it could be solved by type checking during dependency resolution time: instead of just checking version numbers, also check capabilities that transitive dependencies declare.

Maybe you could slowly boil the ocean by assuming that everything that doesn't declare required capabilities implicitly requires the "ALL" capability, and triage+prioritize a growing core of packages that have explicit capability requirements. In my mind it's kind of like purifying functions in a library: you start at the lowest level / leaves of the call graph and make sure they don't do any I/O, and then the things that call them can be made pure and so on up the chain.

> I like the sound of it, but it seems like it might descend into something like checked exception hell where a given package D works fine as a dependency of package A but not of package B (because package B drops some privileges that D expects to have).

That sounds like it would be working. If you declare that your package doesn't need network, and it fails because it used the network, that sounds like a bug was caught.

My first reaction was that if we need protection from pieces of software we ship because nobody knows what we ship, something must be deeply wrong.

But npm-snark aside, maybe some lack of trust must come from a highly modular open source ecosystem.

If a library I ship could abstain from unneeded platform capabilities, that would certainly reduce catastrophic bug/attack surface, and I'd sleep better.

This describes what I am currently missing the most in the node ecosystem. Deno is a good approach but it will take some time to see how adoption goes. I would prefer some fine grained capability-based solution. Approaches similar to this have often been articulated [1]. Many of my concerns are best described here [2]. There even was an article from someone who would have been able to overtake many high profile npm accounts with very little effort some time ago (cannot find it anymore).

With tighter snyk integration into npm and the acquisition of npm through ms one could argue that security bar may have risen/will rise but I (speaking as a js/ts dev) am still sceptical. I haven't really looked to deep into stuff like selinux/apparmor/firejail [3] maybe someone can give an opinion on this. I'd wish for something that would be codeified on package level to make review easier and give me some peace of mind.

For now my plan is to dockerize most of my projects and it's dependencies. It should give a little more protection against malicious postinstall scripts.

Unfortunately, I depend more and more on npm modules outside of projects (coc-vim comes to mind/for others it may be vscode etc.).

[1] https://medium.com/hackernoon/npm-package-permissions-an-ide... (2018) [2] https://medium.com/hackernoon/im-harvesting-credit-card-numb... (2018) [3] https://github.com/netblue30/firejail/blob/master/README.md

This capabilities based OS library reminds me of genode some.

wtf! that's insane! now I'm curious to look up other oss projects I use :)

It's turtles all the way down.

I wonder why there is no effort towards reducing the dependencies, or at least vendoring the worst offenders.

It would be a huge quality-of-life improvement for React developers, not to mention the improved security and reliability.

There are. A lot of components have been deprecated and are being moved out into community-maintained versions. Some major examples are: Camera library, Photo Library integrations, Date/Time picker, AsyncStorage, and more. This is a large scale effort from the dev team to decrease core size: https://github.com/facebook/react-native/issues/23313

I believe this is something that next-gen frameworks worked around:

http://npm.anvaka.com/#/view/2d/svelte

http://npm.anvaka.com/#/view/2d/solid-js

React doesn't suffer from this. It's React Native.

Interesting, you are right AFAICT (react has numerous packages and I'm not totally sure how they relate).

http://npm.anvaka.com/#/view/2d/react

http://npm.anvaka.com/#/view/2d/react-dom

In theory, that is. Since it doesn't include batteries, the controller, the wheels, or the antenna you're gonna end up bringing a ton of dependencies yourself to cover the missing parts (animation, state management, routing etc). Plus you're not seeing the dev dependencies, a more apt comparison would be to create-react-app.

Since it doesn't include batteries, the controller, the wheels, or the antenna you're gonna end up bringing a ton of dependencies yourself to cover the missing parts (animation, state management, routing etc).

Or not. I've worked on plenty of applications that had few if any dependencies for those things. I'm sure many others have too.

In some cases that was because we didn't need that particular functionality. Routing has little value if you're building an in-house SPA that always starts from the same dashboard anyway, for example.

In other cases, it's because we're programmers and don't import entire library ecosystems to do what we could do ourselves with a few lines of code or some APIs that are already supported by all modern browsers anyway.

I liked React when it first arrived, because it was a tool that was that did one useful job and did it reasonably well. I dislike the direction it's taken more recently, because it now seems to be trying to do several jobs and not doing most of them very well at all. I understand that this is partly because of the way some developers coerced React into doing things it wasn't really suitable for and the React dev team have been responding to that, but I still think value has been lost in that process.

In 3D, it looks like something from out of stranger things.

Any large financial services company you're working with is already deploying sensitive apps on Node, for what it's worth.

That's not very comforting. Banks deploy nonsensical stuff all the time (like bad password policies).

Nothing about bank security should comfort you, but the clientside app that uses React Native should probably not be the thing keeping you up at night.

Not the one I work for here in Canada. Just stating that to add a counter-point.

Right, but they’re probably mirroring dependencies locally, scanning them regularly, and have a process for adding new ones that isn’t “npm works on my desktop”.

Cute, no they don't. Speaking from experience. It's a shit show.

batter/faster: http://npm.broofa.com/?q=react-native

Well javascript's package management is designed around the micropackage.

It really doesn't bode well for microservices of any large scale complexity, unless there are concentrated meganodes with limited interconnects like cities and superhighways.

I think the micropackage system is great in theory; it just falls down with bloat and security. Security could at least in theory be mitigated by something like pledge. Right now every developer on the (transitive!) deps authors list effectively has full access to our production systems, and that's ridiculous.

Bloat though ... I mean, if every npm module was simply a directory with a package.json file and a couple js files I'd be happy. But thats almost never true, and usually for bad reasons. I'm not sure how to fix the problem. A few years ago I worked with a guy who maintained a popular little 200 line react image component on npm. The project website was great - with example images and whatnot. Some software we worked on used his library. Our node_modules was huge, and one day I took a look to try and figure out why. It turned out his tiny module was bundling all ~10mb of example images in the package itself.

He was shocked and embarrassed when I pointed it out to him. The library had thousands of stars on github at the time. Lots of people were using it but nobody had noticed and mentioned it to him.

10mb isn't that big, but this is the sort of sloppiness that really adds up over time & thousands of transitive dependancies. Would tooling fix the problem? Maybe a little, but I suspect the problem its partially cultural. A lot of the web development community suffers from a lack of ... thoroughness. Like, the expectation is if the website works and looks pretty, you've done a good job. And invisible bugs and issues get overlooked consistently. Like app bundles which silently include multiple copies of the (200k) moment timezone database. Or obvious security issues that web devs just don't know to look for. I suppose this is how juniors learn - but it feels like a very lonely place sometimes when you have skills and experience.

That 10MB anecdote reminds me of someone that deconstructed a massive windows app and found tons of junk images, libraries, and other wasted space.

Meanwhile WinAmp was sooooo tiny.

It was the worst experience of my development life, building a phone app with it........................ never, never, never again.

If you want to know what it's like to have everything break LITERALLY every few days, use react native.

As someone just getting into mobile development, I've enjoyed using it significantly more than native iOS/Android. It's so much faster and more straightforward to spin up designs,

Until your first update. I assume you didn’t work on anything that has been released?

What happens when you do the first update? Have you used Expo?

Its not so bad. He is referring to RN updates, e.g. from 0.61.5 to 0.62

Its annoying, but I succeeded in upgrading in one project in about 1 hour. Just basically comparing the example code diff on github.

perhaps older version had more changes and weren't documented as well.

irrelevant comment: I hate Expo as it fails to be a helpful abstraction on top RN.

Update as in you application update or dependency update?

The app was developed over a year ago and then came back to it for significant feature development.

The update wasn't terrible.

If you know native at the same level, RN is in now way faster.

I don’t know anyone that is equally proficient in Android and iOS development at any high level.

There were breaks for sure, but I worked in a shared-codebase web/native app using RN and React, and it was overall pretty pleasant. How early were you using it? It was actually pretty reliable.

Same experience with me. My company launched their RN app on iOS and Android and it was pretty successful and pleasant.

How long ago was this? Been doing RN since .58 and not had any issues like this unless you pay zero attention and use random dead packages a lot.

Yep agreed! 0.62 works flawlessly and the integration of Flipper standard on every project has been nice

I tried RN for the first time (with a lot of React experience) a few weeks ago and I haven't noticed this. I don't use third party libraries though, maybe that was the source of your problems?

The web has become truly awful and it’s invading desktop apps. We need to refactor our technology stack.

Today I installed an Electron-based terminal emulator and started seriously questioning my life choices.

I have the opinion that UI should not be async - meaning if there is some processing going on, UI elements should be disabled from interaction until the function returns. If it is a web query, I think that's fine. When applications start adding queues and jobs, UI feels "springy" instead of "snappy". User is waiting for some feedback of how long something is going to take, instead the user assumes that job is done (due to lack of feedback) and tries something next - this action is now in the queue. And then user waits... wait... and all of a sudden all queued processes return. This is not human centric design.

Yes! Obviously long-running operations should be asynchronous, but the assumption that all operations should be treated as long-running is wrong. Specifically, typing feedback and button feedback should be synchronous, and should be done directly in the UI loop.

I understand the rationale for going async -- you can never be sure exactly how long anything will take, and invisible things like memory management and caching can blow up your runtime; and if you get synchronous operations wrong, that leads to spinning beach ball cursors and “app not responding” errors, which are even worse than lag. But in that scenario, an async app isn’t going to perform any more usefully, you’ll just get a blank or frozen screen instead of a beach ball.

Most native apps I've downloaded are well into tens or hundreds megabytes. I just tried a few big popular sites with caching off and none of them downloaded more than a couple megabytes of javascript. I'm really skeptical of the popular wisdom around here that web dev is doing something especially egregious when it comes to build sizes or dependencies.

The browser is where the hundreds of megabytes vanish to when you use a JS app instead of a native one.

That might still be better (I'm undecided, personally), but it's worth recognizing that heavy native app is still there, just shared with a lot of other JS apps.

You could say the same about system libraries/binaries every native app needs to run

Native apps can share libraries at run time. I'm no electron expert but I'm assuming electron apps only can share dependencies at build time at which point they would be copied into the executable so they really wouldn't be sharing.

Valid point, for sure.

Slack: usually ~300MiB of RAM for one account. The Ripcord [1] Slack/Discord client written in C++ and Qt: currently using 33MiB. Qt is not the native toolkit on Windows/Mac, but Qt apps typically follow platform conventions far better than Electron apps.

This also voids the argument "we need Electron, because it reduces development costs, and we can get truly cross-platform apps". Ripcord is written by a single indie developer and runs on Windows, Mac, and Linux. Imagine what could be done if Slack employed a team with 10 Qt developers.

Most web apps are egregious. The problem is that there is a whole generation that is not exposed to Delphi or Qt Designer and have the false believe that developing web apps is an order of magnitude easier. It's only an order or magnitude easier for them, because web tech is the only thing they know. Heck, I was writing GUI apps as a 12y/o with Delphi.

[1] https://cancel.fm/ripcord/

People don’t care. The vast majority of people don’t ever use their computers for anything heavy, so it’s not like saving a few hundred mb of ram is going to be noticeable for them. It’d be nice to have a lighter, more performant app but if the cost is that it looks like what you posted (no offence to the dev of ripcord; IMO qt and gtk stuff always just looks super outdated) then I’d bet most people would prefer the more modern/pretty looking app.

The vast majority of people don’t ever use their computers for anything heavy, so it’s not like saving a few hundred mb of ram is going to be noticeable for them.

They will definitely notice. E.g. baseline MacBooks (which is probably what most people outside developers buy) still come with 8GB RAM. If you subtract the OS, video memory, and some disk caching. There is not that much left on modern macOS (or Windows).

Having Slack + Skype in the background and some tabs open with modern web sites/applications can easily much a few GBs of RAM, slowing down quite a lot of 8GB machines. I guess most developers just don't notice, because their employer give them development machines with 16 or 32GB RAM.

People don’t care.

They don't care because they don't understand. They will just believe that their computers are slow and that they have to throw more money at it. Or they just buy an iPad and it will feel fast, because Apple does not allow every application to ship and run its own web browser.

no offence to the dev of ripcord; IMO qt and gtk stuff always just looks super outdated

That's because the developer decided to use their own theme. I have made a few Qt apps and on macOS and Windows you can barely distinguish them from a native app, unless you know where to look. Fully agree with Gtk+ though, it does not follow platform styling and conventions and is very slow on macOS (don't know about Windows).

It's worth mentioning that apart from Javascript, there is nothing 'web' about React Native. To put it simply: You use Javascript to control native components. Electron and React Native are wildly different. React Native is set up to look like web development, but it is not. It makes it easier to get started, but over time you'll have to appreciate the native platform underneath.

For this reason, I've been trying out Flutter or even considering to go back to native apps.

This says so much about the sad state of modern software development...

When native development is a last resort.

Why does it have to be sad? To me it is good news! Especially if it is open source. The more software we can write that isn’t specific to a platform the more free and useful software can become. It wrestles back control from google, apple, microsoft et. al and makes their closed platforms less relevant.

"Useful" as long as you don't care about battery life, memory usage, taking advantage of features of the host platform, or the native UI.

As an end user why do I care about "openness"? If I pay a premium for my platform, why would I want second rate cross platform software?

As an end user you might not get that software at all if no one is motivated to build it.

But junk software is still junk and not worth the trouble.

Are we to presume you think that using native SDKs saves your junk software from being junk? I'm not sure how else to interpret your comment in this thread.

Having software that doesn't act like native software makes it junk. I've deleted a lot of software that was created with cross-platform SDKs that just didn't behave the way every other program on my computer did. I don't have time for that. It's a lot more likely that something created with a native SDK will behave like a native app than something slapped together with the cross-platform SDK du jour.

> As an end user why do I care about "openness"? If I pay a premium for my platform, why would I want second rate cross platform software?

Falsehoods HNers believe about how people buy/use software. Didn't stop Slack/Discord from become ubiquitous.

"But native tho" just becomes a circlejerk. Talking about what users care about, most people don't know what native means nor if a given app is it. They don't know if Zoom is using more memory or CPU than it "should".

Let's not forget that MS Teams has more paying users than Slack....

How many people know that Slack is battery draining monstrosity?

The only people that pay for Slack are companies. The definition of Enterprise Software is where the user is not the customer.

Hmm this one is tough Office 365 has more paying users on teams. I doubt anyone is paying for teams, also they are not direct competitors. We use both, likely to get phones with teams in the future as well.

Whether it is fair or not that Teams comes with Office is irrelevant. This is Slack's competition. They have to convince companies that it is worth paying extra for their product.

In the famous words of Jobs about Dropbox -- chat isn't a product, it's a feature.

What I am saying is, we dont pay more or less for teams, its a SfB replacement.

MS Teams is an Electron app too. This very post is about React Native for Windows and Mac, which are being developed by MS because they're used for the front-ends of much of the rest of Office 365. Microsoft clearly thinks that it's worth rewriting large parts of their crown jewels using cross-platform frameworks.

I remember when Spotify 'upgraded' from a native to a js application on MacOS. It bricked my wife's computer. She never installed Spotify again. This is someone who doesn't usually care about software. She did care about that annoyance.

It works fine for hundreds of millions of other users

If Spotify bricked her computer, it was an issue with computer, not Spotify. It just so happened that you installed Spotify before the computer was bricked. If Spotify did that, you’d have heard stories of other Macs just completely dying out there if this was an actual issue.

I use Slack and other Electron based applications because my job requires it, imposed by our IT or customers, not because I freely have chosen to use them or have the liberty to look for alternatives.

Other than VSCode for Rust and TypeScript, my own personal computer is as much Electron free as possible.

So don't mistake market share for freedom of choice.

VSCode is a great example. We’ve already established that the average joe out there doesn’t care about whether an app is implemented in electron or not. But VSCode’s success at the expense of every other editor out there indicates that even developers don’t care that much.

The important thing is features - which VSCode has, and the speed at which those features are developed and deployed on all platforms - where VSCode is nearly peerless.

If developers cared about performance and resource consumption above all else, no one would be using VSCode right now (you included). They’d be using vim, emacs or perhaps Sublime. But that isn’t the case.

So why does HN keep flogging the “electron is bad” meme?

The day Microsoft releases Rust support for Visual Studio, VSCode gets kicked out of my PC.

Also, I wonder how much the Electron love overlapps with VSCode, after all many of those developers were pushing for Atom before VSCode was born.

Not much, at least here. I was a Sublime Text user for years. I tried Atom but it was an ugly, janky mess. I switched to VScode quickly after its release because the features it provided over Sublime Text were worth it, and the performance was good enough, even though not on par with ST.

And me thinking that it was probably about those $80.

I expect things to go the other way. Visual Studio will eventually be phased out for VSCode or something like it.

I think Microsoft chose Chromium for Edge mostly because they have big plans for Electron.

Because some things being good does not mean we shouldn't criticize the bad ones.

No, criticise whatever you want.

I'm just saying users don't care. They'll still use software that has the features they're looking for, on the platforms they use, as long as performance is acceptable.

I'm pushing back against the idea that performance nuts on HN who won't install a single electron app are somehow representative of the population at large.

Some do, while I can't speak for the emacs community the (n)vim community is very active and engaged. There are modern vim plugins for nearly everything. The developers using VSCode tend to be developing on overpowered workstations where the difference is less noticeable. It doesn't mean it isn't wasteful. At some point we'll hit some upper bounds as an industry and have to rethink how we develop software, the trend back towards statically typed, compiled languages like Rust, Swift, Go are already leading us in that direction.

Edit: a word missing

> the trend back towards statically typed, compiled languages like Rust, Swift, Go are already leading us in that direction.

Indeed, even Java and .NET are improving their AOT stories, while available since the early days, weren't as widely deployed as they could have been.

Hopefully soon Java will have a friction-less path to compiling to native. As of now, its quite difficult for anything that isn't trivial.

It has been trivial since 2000, but you had to buy a commercial JDK to get it.

It is not trivial. Have you tried compiling any large app with graal? Anything with Weld or hibernate or H2 embedded? It has a lot of friction and isn't as easy as just running mvn package.

I use Visual Studio (not Code) for C#, Python and Node now.

Indeed. I had this argument with some of our non-tech staff countless of times. They absolutely prefer Slack, Basecamp & Co. as separate app. Doesn't matter if it's just an electron container - to them a browser tab/window is a subpar experience compared to an icon in the dock and its own exclusive window. Hardware requirements and the fact that each app needlessly runs itws own browser obviously aren't a concern to them.

> If I pay a premium for my platform, why would I want second rate cross platform software?

Are you paying for your software or getting whatever you can find for free? If you are paying, is the software's leanness something you value - that is, will you buy some software because it is leaner over some other software that is heavier? Would that be even if the heavier software has more features?

What sort of software have you bought? I'm asking seriously, not trolling - i've bought Total Commander myself exactly because it was lean (check: windows calculator vs one of the most feature packed file managers[0]) but i do not think there are many that value things like that.

[0] https://i.imgur.com/LYzN3Cj.png

Just bought the wonderful native git client Fork, even though it works for free and the Electron GitHub Desktop is also free.

As far as desktop software, the only software I pay for are subscriptions to Office 365 and JetBrains R#. I don’t really use my personal computer for too much of anything besides Office and a Plex server - I paid for a Plex Pass solely to support the developer.

On mobile, I’ll pay to remove ads and I won’t use any software or games where I can’t remove ads.

With the economy in the crapper, I’m starting to voluntarily pay more to support my favorite content producers.

This is funny because you just listed a bunch of cross platform software.

The argument is not about cross platform software. It’s about native client software.

Office is not written using one of the cross platform frameworks and is usually only around 3-9 months behind when it comes to taking advantage of new features as Apple releases them.

Plex is server software. The UI is a web page.

R# itself is a plug-in only for Visual Studio for Windows. Yes Rider is cross platform, but I don’t have a need for it.

The only other software I mentioned are games. No one expects a native experience from games.

> If I pay a premium for my platform

this is something that you might value but I think it's fair to say it is already a minority position.

phones and the web have become the primary platform for software delivery, and people do not treat their desktop if they even have one as some sort of premium platform, it's a terminal for the internet.

at this point, people are probably more familiar with the look and feel of web applications than they are with native applications and value similarity across platforms over features of individual platforms. The operating system and the hardware are increasingly becoming irrelevant and a detail compared to the web on top.

Follow the money. People pay for what they value. Who is paying money for desktop software besides games, Office 365, and the Adobe Creative Suite?

Who values desktop software enough to pay for it? I know in the Mac market at least, the few indy developers making money are not writing apps using cross platform SDKs.

Lots of business running Windows on their labs and using desktop software for various use cases, like data analysis.

Plenty of money to be made desktop solutions to life sciences, manufacturing, factory automation, aren't plugging their air gaped dashboards to the web.

Anyone doing music composition, graphics, animation, infotainment systems.

In Europe there are enough Win32, WPF, UWP, Qt related jobs and consulting projects with hourly rates to do a comfortable living.

As for B2C, it is always going to be an uphill battle regardless of the application type, there are only so many application types that one is willing to pay for outside established brands, and SaaS is a much better way to avoid piracy and get everyone to pay.

We are speaking specifically about B2C where the users are the customers.

But either way, you kind of made my point. Consumers aren't paying for applications built on cross platform frameworks outside of games.

Kind of, most consumers that aren't willing to pay for desktop software aren't also paying for games.

In most countries they just need to go the local market or get hold of one of those lists distributed among students.

Someone is paying for games. What other B2C software is making money from the general consumer (besides MS) and not the “prosumer” who is buying software to help them run their business?

Just like someone is still paying for desktop software, in spite of piracy and SaaS.

All those small companies that manage to have their software exposed on shops like Saturn here in Germany, or do direct sales over their web site.

And just because it is B2C, Prosummer or used via a tablet plugged into a docking station, it doesn't stop being desktop software, from the points of view who's paying and selling it.

And regarding games, anyone with experience on the field knows how much harder it is to make any kind of living out of them versus regular desktop software.

The success/failure rate is much higher, with the large majority of studios never making any dime.

Office already uses react native for parts of their desktop and mobile platforms, win32 is in the process of integrating react-native support. So does Adobe at least if their github is any indication.

And if you look at the end consumer software which have billions of users, who in one way or the other pay for it, it's almost always built on web tech these days. Discord, Skype, Slack, Spotify, and so on.

Of course there's professional or industrial software written in native code. But that's not because it's popular, it's because it's niche and specialised. The business model of charging upfront isn't exactly a sign of popularity, if anything it's the opposite.

Consumers don’t pay Slack - businesses do.

No one cares about the Spotify UI. People don’t interact with Spotify that much. They listen to it.

The business model of charging upfront isn't exactly a sign of popularity, if anything it's the opposite.

In a capitalist system how else do you measure value than what people are willing to pay enough for to have a sustainable business? End users aren’t paying for Slack. They are using the free plan because it’s good enough.

I literally can't follow your points. Of course people care about the Spotify UI, that's how they interact with Spotify. And it doesn't matter if end users or businesses pay for Slack, people do pay for Slack and its software and UI is part of what they pay for.

Are you just going to find a different reason why you're going to ignore software built on a web tech-stack? Add up the market valuation of all companies using web technology to bring software to their users. Then compare it to the native market. It's not even close.

It's perfectly fine to use market value to estimate utility in a capitalist system. You just can't ignore every piece of software you don't like.

False dichotomy. Native applications can be cross-platform.

I don't think so, if RN or similar is a viable option then it makes far more sense than juggling large Java and Swift implementations of the same app.

Or the alternative is not to have run bloated cross platform apps and run native apps....

Why would you think React Native would be less bloated than native apps?

I don't think it would be less bloated, it's impossible for a layer on top of native to be less bloated. That's not to say it couldn't be efficient, and efficiency in development time is the key factor. It can be a nightmare to manage apps across different platforms, frameworks and languages. RN could be massively improved, but the concept is a godsend.

Why would I as end user care about developer efficiency?

Aside from update frequency you wouldn't, users can't tell the difference if it's done well. Are we not talking about "the state of software development"?

Microsoft and Adobe update their apps quite frequently -- for Mac, Windows, iOS, and Android. I gladly pay $100 a year for O365.

What are some well done cross platform apps that don't unnecessarily drain battery life? I can think of one - VSCode.

Huge companies, yes. They'd still prefer to spend less money/resource/time if they have the option to though, hence why some large companies actively explore cross platform technology. Adobe did that with phonegap a long time ago.

You're talking about Electron there, which like phonegap is a browser wrapper and a different thing to RN. I don't believe RN is known to be a battery drain in general.

How well did PhoneGap work out?

Badly, which is why we have a totally different approach in the form of RN, Flutter etc. The concept of cross platform support wasn't the problem, that's what we're chasing for a reason.

It keeps the cost down. A lot of end users care more about cost than literally anything else.

How many end users pay for non-game desktop software at all? How many successful (ie profitable) companies have made money selling desktop software using cross platform frameworks like React Native?

How many successful (ie profitable) companies have made money selling desktop software using cross platform frameworks like React Native?

React Native for Windows and Mac specifically, none. We commenting on an article about its launch. It's a bit early to be talking about that.

Cross-platform frameworks like Electron or Flutter, loads. VSCode, Skype, Discord, WhatsApp Desktop all use it. Of course you might argue that they're all selling services rather than software but that the point really is that the companies authoring those apps want to keep costs down, give users the same experience everywhere, and believe cross-platform apps can give users a good experience.

And no one cares about any of those apps to pay money directly...

You can't really make that assertion because no one can pay money directly. You have no way of knowing if people would pay for them if they were offered as a product. You just assume they wouldn't because that fits your belief that no one would pay for cross-platform framework driven apps. Until you bring some actual evidence to the discuss to back up your point the whole argument is pointless.

Are you proud of being a consumer rather than a creator?

Surprisingly enough most developers are both....

Because developer efficiency reduces the cost of the app, or in many cases causes the app to exist where it otherwise would not.

Because if you as a developer only develops for a single platform and that platform isn’t the one I’m using at the moment, your product is useless for me.

I will gladly write 10x Swift thatn RN. That said it is usually less code, because you don't have to reinvent thnings.

Why does it have to be sad? When software becomes easier to develop, it enables everyone to benefit.

More developers, more applications of software.

At the same time, performance has a tangential relationship with computer code being interpreted or compiled to native.

After all, Java is compiled to byte code and powers plenty of high traffic servers efficiently.

Many AAA games use ActionScript, Python, Lua, etc for their UIs and scripting for mods.

While it's true that there is no substitute for code compiled to native when high performance is called for, I think it's justified for native development to be last resort.

This is coming from someone who codes primarily in C++, where high performance is important. I wish I didn't have to.

After all, Java is compiled to byte code and powers plenty of high traffic servers efficiently.

How well has Java done on the client in the last two decades?

Many AAA games use ActionScript, Python, Lua, etc for their UIs and scripting for mods.

What's the actual performance sensitive parts written in?

I don't think anyone is suggesting writing game engines or the core of graphics processors or video renderers in React Native. It's for the frontend. The pattern of using React Native for the frontend and native moduels for the backend is a pattern being used by many companies. The difficult stuff can be written as a native cross platform library, while the front end can use React Native. This is what MS is doing with Office.

Java, JavaScript, .NET, forks of Lua, forks of Python, and others are JIT compiled.

So I am not sure what you are saying. Everyone that is able to is compiling their stuff to try to regain some efficiency.

The reason is that people wants to do more complex things with their software nowadays, and hardware can't keep up with the trend. There is also battery life, smartphones, tablets...

Those are the reasons we are seeing a resurgence of native development.

I’m not referring to “native” as in compiles down to x86 and doesn’t need a runtime. I’m referring to native as the opposite of a cross platform framework that produces apps that don’t take advantage of the native OS’s look and feel.

This isn’t just me being a Mac snob. I found Apple’s few Windows apps over the years to be just as bad.

Good abstractions are the reason why we have so much cool technology.

Writing the same thing multiple times is also sad. On desktops, it was understood long time ago.

Sad for who?

Yes and a long time ago Sun came out with Swing. How did that work out?

Even before that MS came out with P-Code and the abomination that was Word 6 for the Mac.

Sad for developers. What I had in mind regarding desktop were big tools like Blender, Photoshop, Blender, IntelliJ IDEs, which existed long before Electron.

I think it clearly shows that complex UI apps require cross platform UI, or will remain single platform (Xcode, Visual Studio).

Let me tell you a story...

I was at a crossroads in 2008. I had been developing mostly in C for a decade and decided to pivot to being your standard “Enterprise Dev”. I had a choice between moving my career to C# or Java. I chose C# partly because of the bad stench of the cross platform Java IDEs at the time. Give me VS or Xcode any day over a Java based IDE.

Photoshop definitely isn’t using a non native runtime. I doubt that Blender is either.

Have you heard about our lord and savior, vs code? People are choosing it over full blown vs. Also, I haven’t seen many happy xcode devs.

VS Code is winning because it's multiplatform and has great support for lots of languages. I'd say it's the best choice for 95% of programmers.

But for writing C# apps in a Windows computer, the old VS was already miles ahead back in 2010. It is a really good product. It had RAD tools, testing, deployment, source control, database migrations, all wrapped in a very snappy and convenient GUI that I still don't think VS Code replaces properly. As much as I love the command line and unix philosophy, there was something about such a complete IDE that made me very productive. All IMO of course.

However I strongly believe that VS Code will get better and better with time and be able to fully replace old VS even for this use case in the future.

VS is all good until it slows to a crawl on big projects. Anecdotal evidence I know, but I've seen people on hn switch to code for c# and like it. Also, nowadays at least testing and source control are pretty good in vscode.

Can't speak for VS but XCode is a pig.

For those that don't know, the latest version is an 8GB download.

XCode also includes the entire iOS/tvOS/iPadOS/watchOS frameworks compiled for x86 for use in the simulators.

Blender is drawing it's UI in OpenGL, you can't be more cross platform than that.

I don't think Microsoft is worried about Visual Studio being single platform, if the platform is Windows.

They are spending money on Visual Studio for Mac and Visual Studio Code.

I'm pretty confident that the reason for Xcode being single-platform is that Apple doesn't care about anybody not using {mac,i}OS.

A bit off topic, but the visualization of the dependency graph isn't really good. There are much better ways to render DAGs: https://github.com/erikbrinkman/d3-dag

My favourite is the factorio research tree. It gives you a sense of depth and you can select dependencies.

Maybe I'll implement it one day when I have the time.

If you want to see something _crazy_ compare that with http://npm.anvaka.com/#/view/2d/ember-cli - 1.2K links (and ember-cli compares quite well with react-native since it ships as direct dependencies a whole bunch of CLI tools to help with _building_ an app, not just the code that you ship to the device.)

This is thanks to many of the React dev team being strong proponents of outsourcing to micro deps for everything & remained strong supporters even after the left-pad incident.

Imagine how much more enjoyable npm would've been if prominent JS devs took a sane approach to dependencies, like the TypeScript team who have no runtime deps.

The resulting npm deps of hell [1] means they need to rely on complex build solutions like Webpack to manage it all. My preference these days is to avoid npm/yarn all together and just use TypeScript watch (tsc -w) for incremental updates which lets you develop modern JS using modern fx's (e.g. Vue/React) without any of the npm/Webpack complexity & only requires a vastly simpler build solution to minify/bundle all UMD deps together.

[1] https://www.reddit.com/r/ProgrammerHumor/comments/6s0wov/hea...

According to the link in the comment, apparently React has a total dependency tree with only 7 nodes, which is the opposite of what you are describing.

I'm actually surprised, I thought React had many more dependencies.

Edit: Removed comment related to typo, no longer relevant.

Was a typo I meant `proponents`, fixed.

The core library deps isn't relevant, it's how many deps the smallest starting Create React App has that matters [1]. As mentioned by OP react-native is far worse.

[1] https://news.ycombinator.com/item?id=19195148

Why would create react app add more run-time dependencies? Isn't that just Babel and stuff used for building?

Also, with TypeScript, Babel becomes completely unnecessary. I haven't used it in any of my React projects for years. Many templates still include it by default to match the JS version, but if you create the project from scratch without any scaffolding, there is no reason to do so.

> Why would create react app add more run-time dependencies? Isn't that just Babel and stuff used for building?

You can see all the dependencies it installs by running:

    $ npx create-react-app my-app

> Also, with TypeScript, Babel becomes completely unnecessary.

Right, as per my comment it's also my preferred approach:

> My preference these days is to avoid npm/yarn all together and just use TypeScript watch

In general I prefer Vue over React, but I prefer to use vanilla TypeScript & UMD deps to develop with either.

> Many templates still include it by default to match the JS version

It's what the React team is recommending to start with [1]:

> Create React App is a comfortable environment for learning React, and is the best way to start building a new single-page application in React.

[1] https://reactjs.org/docs/create-a-new-react-app.html#create-...

I just ran that. It took a long time, and the progress bar showed fetching 1381 packages. Definitely https://i.redd.it/i428f2ki0ho01.jpg.

However, the resulting `package.json` only shows 3 dependencies: react, react-dom and react-scripts. After `yarn build`, it added 3 more things from `@testing-library` (https://testing-library.com/), I assume those things won't make it into the production bundle.

react and react-dom only depend on a tiny number of things, you can check that with any dependency visualizer. 6 or 7 in total for the whole tree, and most of those are tiny things that they just split off from react itself (e.g. prop-types).

react-scripts is the huge beast that causes the dependency tree to explode. It is a `create-react-app`-specific package that contains all its build logic. So that seems to confirm the hypothesis that there actually aren't many runtime dependencies in the basic template, but who knows what it does behind the scenes. Also the LICENSE.txt file it generated for the biggest output .js file only includes entries for react, react-dom and object-assign.

No idea about React Native.

Right, each time a new project is created it contributes to global warming. The entire dependency matrix is what impacts normal development workflow, e.g. everytime I tried to update an old Webpack SPA project there would be always something that was broken that I'd have to hunt down & fix.

> No idea about React Native.

The OP suggests it's worse. But I no longer use React Native as I kept running into bugs & UI issues that were never fixed. I ended up reporting a few with complete repro's but didn't look like they were ever looked at, instead after a few months they decided to triage their 1000s of open issues, to get back to zero issue inbox.

IMO React Native is architecturally flawed to run into so many issues when creating normal Apps after years of development, maybe if there were more developer resources on the team it would be more manageable. But I believe Flutter has a much better architecture [1] which feels much more integrated & polished that results in a more responsive app that works as advertised.

[1] https://dart.dev/platforms

Flutter itself seems nice, but Dart as a language is a pretty big downgrade from TypeScript.

For mobile right now, the easiest, most headache-free solution may actually be to forget about cross-platform and just do separate Android and iOS native apps. You won't need to do things like hunt for a bunch of 3rd party libraries whenever you need to use Bluetooth or something.

Once SwiftUI and Jetpack Compose mature, that process should be much more pleasant as well.

> Flutter itself seems nice, but Dart as a language is a pretty big downgrade from TypeScript.

It definitely isn't, Dart is an advanced clean, strongly typed classical language without JS's warts that's just as clean & productive with a clean complete & well-defined standard library, native support for modules, consistent async/await in all libraries, etc.

I love TypeScript, but it's major productivity advantage over Dart is in JS's dynamism, something that's a lot more restrictive in Dart because it needs to support AOT, which is what allows it to compile to native code & advanced linking + tree-shaking, resulting in its better performance. So there are areas where you need to use code-gen, but having wasted an eternity trying to diagnose runtime issues in C#/Xamarin in libraries that use reflection, I'd much rather use an AOT language that only provides language features that natively supports AOT then running into frequent on-device issues that only occur at runtime.

> For mobile right now, the easiest, most headache-free solution may actually be to forget about cross-platform and just do separate Android and iOS native apps.

Nope, Flutter's Reactive UI & live-reload is far more productive then developing using native iOS or Java/Kotlin tools (which can also be used in Android Studio). SwiftUI is close if you just need to develop for iOS, but I find Dart/Flutter to be a lot more productive than using Swift & Xcode's woefully poor tooling support.

As far as I know, Dart still has all types nullable by default, which makes it easy to run into problems with things like initialization (not realizing that a thing may still be uninitialized at some point / only loaded later) or just plain optional data (assuming some thing is always present when sometimes it's not). It's like partially dropping down to dynamic typing, where you have to keep all this in your head manually every time you refactor a part of the code.

It also doesn't seem to have things like sum types, which would be pretty easy to do in an AOT language. The expresiveness, the ability to accurately describe data structures with its type system just doesn't seem to be there. It seems about on par with Java in that regard. Fast live reload is pretty good though, I hope other langauges/frameworks put more effort into that.

I haven't used it much beyond simple demos though.

> Dart still has all types nullable by default

TypeScript is even worse in that regard since it has to deal with JS that wasn't written in TypeScript & there's no way to verify the runtime object complies with the interface you say it does. Then of course JS has to deal with multiple null & undefined values & even more falsy values, ultimately TypeScript provides nice static analysis but also a false sense of security as there's no guarantee that the compile time static analysis matches the actual types / values at runtime.

At least with Dart, you're guaranteed everything is written in Dart so you can have confidence in the static type analysis is actually going to be valid at runtime. With that said you can use the `--enable-experiment=non-nullable` to enable its Sound non-nullable Types feature [1]

> The expresiveness, the ability to accurately describe data structures with its type system just doesn't seem to be there. It seems about on par with Java in that regard.

This is a gross mischaracterization that I'm just going to assume you're familiar with Dart at all. It's vastly more modern and less verbose than Java in basically all aspects: type declarations, auto properties/getters/setters, auto constructors, implicit interfaces, factory constructors, mixins, typedefs, inference, lambdas, async/await, extension methods, optional parameters, string interpolation, single integer type, cascade/chaining, null guards/assignment/coalescing, generators, operator overloading, Callable classes, first class functions, everything's an object, duck typing with noSuchMethod, etc.

[1] https://github.com/dart-lang/language/issues/110

I have never encountered issues with JS libraries lying in their type definitions (like not including `T|undefined` in the type if `undefined` is a possible return value).

More often this can happen with external data (typing incoming JSON responses), but you have to run-time validate those anyway.

`null` is only rarely used in JS, `undefined` is by far the more common one, and of course the types reflect which one is a possible value, so it's not like you can miss it by accident.

Falsy values are only a problem with bad practices - inside `if`, I just always use the full form with the `===` operator, e.g. `if (variable !== undefined)` instead of `if (variable)`. A lint rule can be enabled for that. There is now also the `??` operator which prevents the common misuse of `||`, e.g. `const a = variable ?? 'default'`.

So those things aren't really issues in practice.

You are correct in assuming that I'm not very familiar with Dart, I have only used it very briefly. I have only checked whether specific features such as sum types were available.

> `null` is only rarely used in JS, `undefined` is by far the more common one, and of course the types reflect which one is a possible value, so it's not like you can miss it by accident.

That's not true, `undefined` is not even a keyword or type, `null` is what you would use if you wanted to specify a variable has "no value" in JS or JSON (again because `undefined` isn't a Type). The "undefined" value is only for specifying if the variable "does not exist". The difference is important as the behavior is different depending on how you use them.

> I just always use the full form with the `===` operator, e.g. `if (variable !== undefined)` instead of `if (variable)`

This is bad practice as you're only testing for `undefined` here, not `null`, this is basically the only time where strict equality isn't useful. You want to test with `if (variable != null)` which tests for both `null` and `undefined` and not other falsy values that `if (variable)` tests for.

> There is now also the `??` operator

Right, the Nullish coalescing operator (which Dart/C# also has) tests for both `null` and `undefined` (well `void 0` since the `undefined` value can be overridden) and not falsy values.

Regarding the `if`, it only makes sense to test for things that the type actually contains.

So if I have a type `User|undefined`, testing `if (user === undefined || user === null)` is pointless, as `null` is not part of that type. It would be different if it were. Similarly, it makes no sense to test a variable of `User` type for value `false`, like it would if the type were `User|boolean`, or even `User|false` which you can do in TypeScript (not that you should). So `if (variable)` is still bad (ok for booleans, tolerable for some types but better avoided). You only test for what the variable can contain.

Some types you encounter are `T|null` - mostly DOM things (e.g. the return value of getElementById), but some JSON stuff as well like you said. Even though a lot of JSON just has optional properties instead, which for all intents and purposes work like `|undefined` when reading them.

From my experience, it is much more common to deal with `undefined` in the JS ecosystem, whether that is by omitting properties from objects, or explicitly assigning/returning `undefined` somewhere.

`T|null|undefined` types are ever rarer. Only for those it makes sense to test for both null and undefined.

By the way you can also have types like

    type RemoteData<T> = {ready: false} | {ready: true, data: T}

in TypeScript, which is better than

    { ready: boolean, data?: T }

because you don't have to worry about "does `data` still make sense when it is non-ready?", the type clearly tells you that it doesn't (of course you can also have a different type where it would, the point is to accurately describe the structures you deal with). Then, if you do a check

    if (remote.ready) {
        console.log(remote.data.length)
    }

it knows that data exists inside that `if` block, so you can safely access it without `!` or `?`. Similarly, inside `if (!remote.ready) { }`, you cannot access it at all. It also won't let you pass an object with { ready: true }, but no data of the required type to `RemoteData<T>`.

> So if I have a type `User|undefined`, testing `if (user === undefined || user === null)` is pointless, as `null` is not part of that type.

It's very relevant, your TypeScript definition is meaningless at runtime when it's executed JS where all TypeScript's type information is erased, the only checks are relevant are the runtime JS type checks.

> `if (user === undefined || user === null)` is pointless

Right, it is verbose & unecessary, so is only testing for `if (user === undefined)` which is inadequate and I don't know anyone who'd use it since using the recommended `if (user == null)` is shorter and more complete for testing if any value is not `null` or `undefined`. If you're validating JSON you should know that there is no `undefined` type in JSON, but any value could be `null`.

> From my experience, it is much more common to deal with `undefined` in the JS ecosystem, whether that is by omitting properties from objects, or explicitly assigning/returning `undefined` somewhere.

If a type want's to declare that property exists but doesn't have a value it would be `null`, which is also the only option you have in JSON to do so.

Your TypeScript definitions are for your code structure and API description so you can benefit from its static analysis, but you should be aware they do nothing at runtime where all Type annotations are erased so if you try to define your Vue component with an optional property, e.g:

    class MyComponent extends Vue
    {
        p1?:string;
        p2 = null;
    }

It gets stripped away completely but setting a null value instead will ensure the property exists and is made reactive:

    var MyComponent = /** @class */ (function (_super) {
        __extends(MyComponent, _super);
        function MyComponent() {
            var _this = _super !== null && _super.apply(this, arguments) || this;
            _this.p2 = null;
            return _this;
        }
        return MyComponent;
    }

It's important to know what guarantees TypeScript does for you, what effects the type annotations have and what their behavior is at runtime.

Yes, it is theoretically possible for a TypeScript type to be "wrong" and the underlying variable to have a different type.

But there are only a few ways in which that can happen:

- a bug in type definitions - a JS library with .d.ts files which "lie" about the actual types - this is no different than any other bug in a library, needs to be reported and fixed. In my experience, such bugs are not very common (I've yet to encounter one).

- non-validated external data (JSON coming from HTTP) - like I said, you have to validate external data (or assume that anything can be anything). You kinda have to do it in all languages, though ones with reflection and a deserializing library can do that somewhat automatically and throw a runtime error if the deserialization fails (although that is not full validation).

- incorrect explicit casts and using `any` - e.g. `const a: number = ('asdf' as any)`, but less stupid and more accidental. This is a bug in the casting code, similar to doing an incorrect `reinterpret_cast` in C++. There is usually little reason to do explicit casts in TypeScript code, outside of very small isolated pieces of code.

Which means you generally don't have to worry about any of this. Relying on those guarantees is good enough for 99+% of situations (I mean, some people even use dynamically typed languages and survive without doing tons of checks on every other line of code).

---

Testing stuff which is not expected (by the specified type) to be `null` for `null` is just as pointless as testing it for the number 10. There is just no "valid" way for the `null` to have gotten there (just like the number 10). It would be extremely paranoid and only add noise to the code.

If there is a valid way, then the type needs to be `T|null` (and then you need to test it), not `T`, otherwise it's a bug. For TypeScript code, this will be checked automatically, for JS library type definitions, it needs to be made correct manually.

Regarding JSON and undefined, you can omit properties in JSON. E.g. sometimes have {"user": {"name": "Bob", "email": "bob@example.com"}}, and sometimes just {"user": {"name": "Bob"}} without the email. Such an optional "email" can of course be expressed in TypeScript, and can be tested as `=== undefined`, which will return true if it's not there. And such a pattern of omitting properties from objects (not just JSON) is much more common in JS than assigning `null` to stuff.

You are much more likely to find a JS object where some property is sometimes there and sometimes not there but never `null`, than an object where it is always there but sometimes `null`. That's what I mean when I say `undefined` is much more common than `null` in the JS world. But neither is a problem, you just need to have types which correctly describe what values the properties can contain.

---

So typically none of this is a problem in practice, as long as you have correct type definitions for the JS libraries which you use (i.e. there is no bug in them, just like there should be no bugs in the library itself) and don't do funky casts with `any`.

> Yes, it is theoretically possible for a TypeScript type to be "wrong" and the underlying variable to have a different type.

Unlike most languages, TypeScript is just a high-level static analysis compiler service that compiles to JS that executes in a JS VM. It has no control over what happens at runtime, it doesn't know about external libraries and user input, how its TypeScript functions are going to be invoked. All it can know is the "truths" you tell it to assume, of which it makes no attempt to validate whether any of your assertions are accurate. It's not that TypeScript is wrong as it can only verify the compile-time state of your program, it doesn't know or can control the runtime state of the JS VM, what arguments your functions are invoked with, what values properties are set with, how any of its instances or prototype chain is manipulated, etc.

> Testing stuff which is not expected (by the specified type) to be `null` for `null` is just as pointless as testing it for the number 10. There is just no "valid" way for the `null` to have gotten there (just like the number 10). It would be extremely paranoid.

It's strange to read runtime JS type checks is pointless when it's the only way you can validate for sure what a Type is. You seem to think you can resolve issues by declaring typescript annotations in a different way, when they have absolutely no impact, your type annotations does not provide any guarantees at runtime, TypeScript can't tell you if your Type annotation is accurate now or will remain accurate in the future, if what you cast to is accurate, if how your code is invoked is accurate, you're telling TypeScript what the only types for a variable are, but these type assertions have no impact at runtime. Ask yourself if you're only checking for `undefined` what the behavior of your program is when it's called with `null`. Since JS functions have positional arguments it's very common for it to be invoked with `null` argument values when needing to provide values for each argument, whereas it's almost never explicitly called with an `undefined` value unless it's undergoing regression testing for bugs.

Given any JS variable can be assigned both `undefined` and `null`, there's no good reason for using strict equality check for `=== undefined`, it's always the wrong type check unless you need to determine the difference between `null` and `undefined`, otherwise it's just a more verbose inadequate type check for nothingness.

I know how it works. I'm talking about practical implications.

In practice, say I have

    type User = { name: string, email: string } 
    let loggedInUser: User = { name: 'Bob', email: 'bob@examaple.com' }

or even

    // Can't change the contents, only reassign the whole variable
    let loggedInUser: Readonly<User> = ...

and only ever use that `loggedInUser` from TypeScript code (because my entire codebase is TypeScript), and I avoid the 3 scenarios mentioned above (buggy JS library type definitions, non-validated external data, casting/any/`!`).

How would a `null` email ever get inside `loggedInUser`? It just won't happen. I know there are no run-time checks - I don't need any run-time checks. I don't need 100% theoretical guarantees. I can be reasonably certain that `loggedInUser.email` will always be a non-null non-undefined string. It's a good enough™ practical guarantee. A null-check on `loggedInUser.email` would be pure confusing noise (because anyone reading it would go "wait, this can be null? I thought it was non-null").

Do you have a practical explanation of how a `loggedInUser.email === null` situation might occur given the above assumptions?

>Given any JS variable can be assigned both `undefined` and `null`

Any JS variable can be assigned literally anything. I don't need to check that `loggedInUser.email` is not null, just like I don't need to check that `loggedInUser.email` is not a boolean or a number. Because how would that even happen? Not having to do those checks is half the point of having a static type system in the first place (the other half is being notified of type errors at compile/edit time).

If you need to defensively check whether something so basic that is never supposed to happen has happened, then the code is already a giant unmaintainable mess.

To sort of answer my own question, there is one more "leak" I forgot about - array bounds are unchecked https://github.com/Microsoft/TypeScript/issues/11122, which can give you `undefined` (though not `null`) without it being reflected in the type of the expression. Similar for objects with arbitrary keys (i.e. maps/dictionaries/etc.) https://github.com/microsoft/TypeScript/issues/13778.

E.g. `const a = [1, 2, 3]` will let you do `a[5]` and still give it type `number` instead of `number|undefined` as mentioned in the github issue. Many other languages also do this (though they have runtime checks/errors).

So that kinda sucks, but the rest still stands (there is still no practically realistic way for `null` or anything other than `undefined` to get there). Hopefully they'll fix that in the future with a new compiler setting.

> but the depgraph above fills me with doubt for use in sensitive applications such as in finance or healthcare.

Fortunately, in such industries you don't have to worry about being cross platform particularly. Go write C# and WinForms (or whatever it is these days). Or use Lazarus/FreePascal if you do need to be cross platform.

What's your take on the way Web Assembly approaches trust of dependencies?

https://hacks.mozilla.org/2019/11/announcing-the-bytecode-al...

I think the top comment should offer a solution, not only a critique. This dependency graph includes the development environment, which I feel is an unfair assessment. Why not re-run with only the production dependencies?

You build the app with the dev dependencies, so you need to trust them as well.

No, thats a logical fallacy. critiques don’t need to provide solutions. It does not make the critique any less valid. This sentiment gets brought up so often here, I really don’t understand the reasoning behind it.

A lot of these "packages" are just silly though. Among the horde of dependencies in that web is `number-is-nan`. Behold its awesome functionality:

https://www.npmjs.com/package/number-is-nan

Want Array#filter/map/reduce? Why that'll be three separate packages:

https://www.npmjs.com/package/array-filter https://www.npmjs.com/package/array-map https://www.npmjs.com/package/array-reduce

It just seems to be the culture of the Node.js crowd to take a library, break it up into functions, and publish every. single. one. as a separate package.

The purpose of that kind of package is to provide a standalone implementation of a function.

To criticize this organization, you would need to understand why people find that to be valuable and show a better approach.

You’re attributing it to “culture” but there may be deeper, less arbitrary reasons. Look up “ponyfill” if you are interested in learning about it.

Wouldn’t the alternative simply be bigger libraries grouped around common functionality or extension points? Like jQuery or similar (only an example, not sure what is hip today).

I’d rather trust a fairly big library with an organized open source group behind it than thousands of small libraries by unknown developers.

The NaN library is literally just testing if the value is a number with typeof v === 'number' then tests if v !== v. This is not something you need a library for at all, big or small.

Yeah, this is my philosophy when developing Erlang software as well (also seems to be shared by most of that community). A few dependencies less are always worth a few functions more.

fwiw, I've been doing professional JS (mostly server, good amount of client) for about 5 years now and have never pulled in a single function package before as a direct dependency. Every team I've been on has used Lodash or Underscore in the capacity you describe.

https://lodash.com/docs/4.17.15 https://underscorejs.org/

I agree that this is the sane alternative, but sanity does not seem to be winning out. Our friend number-is-nan, for example, has 12 million downloads a week.

A week!

It’s like someone saw how much the is-odd/is-even (yes one of those first two depends on the other and just returns the inverse with !) packages are downloaded per week and said “hold my beer”

Of course they don’t hold a candle to “is-number” which has 29M/week

Of course this is completely unrepresentative of reality because “yolo just install dependencies at deployment” may mean it’s downloaded 5 or 10 or 50 times for a high traffic site/service with a bunch of backend installations.

Another good example: .NET Core. I trust that Microsoft hires good people who can update the core libraries in .NET Core to not do dumb and unexpected things. I trust Microsoft to have controls that check for malicious behavior and prevent / fix that quickly. I trust Microsoft to vet all open-source dependencies they decide to integrate into their products.

Also the legal team likes this a lot more too. If a data leak occurs due to some library that Microsoft wrote, we have one company to sue. If it's a react package, who the hell do we go after? Most of these are "at will" / MIT license style things, so we are more or less SOL anyways, but legal teams don't like hearing that.

You also get at a more fundamental question. What is trust? Why can we trust a larger organization over a collection of individuals? Are they not the same thing? What social structures make one more trustworthy over another?

There's a great book on this by Bruce Schneier called Liars and Outliers. I highly recommend you read it.

https://www.schneier.com/books/liars_and_outliers/

I looked up "ponyfill"[0] and I still agree with hyperbovine's criticisms.

Polyfills and single-function libraries are just two different problems with the NPM ecosystem.

https://github.com/sindresorhus/ponyfill

Yeah, but the thing is that it's just unnecessary.

isNaN() has been in the language forever. And in case you really need Number.isNaN() (because it's weird for isNaN('foo') to be true), it's been there for quite a long time too. Not enough to be on IE, sadly, but certainly more than enough to be on the modern JS engines React Native runs on.

So, at least for React Native, the package number-is-nan shouldn't be necessary at all. But it's probably a transitive dependency, and that's basically the problem with all these sort of polyfill packages: you might not need them, but a library that runs on older engines on which you depend (directly or transitively) does need them, so you end up paying the price anyway.

no, isNaN has been in the language for quite a while, num !== num has been in the language forever.

which actually if I look at number-is-nan it returns

return typeof value === 'number' && value !== value;

I never use the typeof value === 'number' myself because I always know if what I'm checking is NaN should be a number of not, but probably that's a bad habit to get into.

It's a result of hiring policy which looks at the number of git repo's, open source projects etc you have.

KPIs are always the driver. Also for programmers.

For those who just want a snapshot and not wait for the graph to draw

https://i.imgur.com/RT6Fj4c.png

I tried using this a few months ago, as well as React Native for mobile and React Native Web for web, and I felt like they were all just hacks glued together to get cross-platform support, and RN isn't even native, it still includes a Javascript bridge. Build dependencies and packages were a nightmare, things continuously broke. I tried Flutter afterwards and it just felt like a breath of fresh air. Everything "just worked", on all the platforms I tested it on: web, iOS, Android, Windows, Mac, and Linux. Updates on one are hot reloaded to another. In contrast, Expo sometimes just broke. This was all wrapped up in one package instead of needing to use separate build chains for each platform.

I wonder if React Native can do all of this officially, but I suppose that's not their prerogative, given that RN is mostly used by Facebook for apps and these other platform efforts are by third parties, like Microsoft here.

> RN isn't even native, it still includes a Javascript bridge

"Native" doesn't describe the programming language, but the GUI layer. Native == non-web-browser.

React Native isn't afraid to expose platform specific details when abstracting away cross platform APIs in uniform APIs. In my experience, it was fairly easy to use a native UI library inside a React Native app. (It takes more work to embed a React Native view inside a native view that's embedded in a react native view, but it's possible.)

I've seen both uses of the term "native"; it's an overloaded term. Some use it to mean "native UI", and others use it to mean "natively compiled". I meant it in the latter case. I actually prefer wholly custom UI, as most apps do these days that are cross-platform, because it allows for very interesting user experiences. Of course, some people disagree, wanting everything to be native-looking and feeling to their platform, such as Linux apps all using GTK or macOS all using Cocoa.

The GUI layer in a static sense. You can't have native realtime interactions with the GUI, for instance dragging and interactive animations.

You can choose one of two things:

1) Run a single precomputed action or animation in native-land when receiving an event from JS. No interaction is possible.

2) Run a requestAnimationFrame loop in JS which is passing the bridge (6 API calls on Android - 3 layers per direction) 60-120 times per second in async mode. Enjoy the jank.

Have you tried react-native-reanimated?

you can, using react-native-reanimated, also, the upcoming fabric work will enable this as well.

I've had the exact opposite experience, but I mostly use Java over Flutter for Android. Expo can be fairly limiting and breaks a lot, but core React Native is wonderful and does everything I need with a couple exceptions (FCM and more fine grained microphone support). I also have a dedicated Android native module for my app, and a lot of React Native libraries can probably be consolidated down to one module and directly using the Java libraries on Android.

What dependencies are you using that continuously broke? Did you track your package lock file on Git?

EDIT: Ive also tried React Native Web and it pretty much worked OOTB. Alerts were the only thing I found that weren't implemented, but they didn't show any runtime errors or instability

What do you think is the main reason for the difference between your experience and the parent's?

Instead of "Flutter", use "Flash" and you got the same thing!

Except hot reload

I had the same experience.

Expo is wonderful for prototyping and quick iteration. The ability to use Snacks online and see them working on the phone is great.

But beyond that everything in RN feels hacky and unfinished. While working with it I had some silly issues with Metro, and found some subtle bugs in Text and Button components.

About the "Native" part. I think that a lot of people have the expectation that doing RN apps will be the same as building a iOS or Android native app. But RN+Expo is not that different from frameworks like Ionic. Is really hard to do an app that follows the Apple HIG or Material Guidelines, you end with something in the middle that doesn't look or feels truly native (at least not without tons of extra work to imitate things that you get for free in the native UI kit) .

RN without Expo is not so nice, lots of rough edges and sooner or later you'll need to write interop code in Objective-C or Android Java to take advantage of the native platform.

Expo has one small issue... if you are in an organization that isn't capable of keeping it up to date and it becomes deprecated, your app will stop working.

If this happens over a weekend, expect your phone to blow up every three hours until it gets republished and fixed.

Unless you are referring to another issue, using `expo build:android` will create an apk file so you don't have to rely on staying up to date with the Expo app.

Yeah, but if you are using their native extensions and they deprecate your version, their repo will become unavailable and your app will fail to start.

That’s a massive claim to say RN doesn’t feel native without alot of extra work? Please elaborate because it feels pretty native out of the box using the standard components.

It’s nothing like ionic. When is the last time you used RN? RN apps are hard to tell from native.

Take the most basic example: a Button.

The RN's core Button it’s a Text composed with a Touchable (https://github.com/facebook/react-native/blob/master/Librari...). It behaves in the same way but there are subtle differences in text rendering: the font size and letter spacing is not exactly the same, so when you create a native looking iOS view it doesn’t look the same unless to fine tune the font settings (and of course that will break when iOS decides to change it). This is just one small example, another one in iOS is “routing”. With the RN Router you don’t get the native components but a simulation of it. But Apple HIG doesn’t document many details of the animations and behavior of headings and nav bar (they assume that you use the native component). So if you want to have a native look and feel your options are: try an alternative router built for iOS, try to build your own adapter (hard unless you have tons of native dev experience), or try to imitate the native platform. All the options have pros and cons, and require more extra work over a small UI detail that you get for free using native tools. At least Flutter took the effort to make it look native by default.

In the end is similar to the desktop: if you want cross platform code is easier to not follow the platform rules. The differentiator of RN is that you have the option to embed the native widgets, which is not always easy. (The last time I used RN was mid-2019, I didn’t see substantial changes since then)

I had the opposite experience actually. Expo made it difficult to accomplish anything with their ever changing sdk and (what felt like) never ending version deprecations and I found sooner or later for any serious project one would inevitably need to eject.

As of RN 0.60 it has been completely smooth sailing developing a react native app sans expo IMO

And I’d like to second this experience. Expo was more pain than it was worth for us, and raw RN was great once you understood it’s toolchain.

I've done a few client projects in the past using React Native. I get the appeal of having a "single" codebase for iOS and Android, but I absolutely detested using it.

I'm quite sure and aware of people that love it, but just from my personal development background, it just never really seemed appealing to me. Definitely not a fan of how state is handled. I've rolled my own system, Redux, and a host of other solutions as well. It just all seemed unnecessarily complex.

As you said, to me it just felt like hacks on top of hacks. I'll take vanilla iOS and Android development any day of the week, and twice on Sunday.

With that said, and from what I've seen of Dart/Flutter, I really hope it takes off.

can you go into more detail about "how state is handled"? I wouldn't have considered that to be one of the offerings of React Native (or Flutter).

Well, for a toy app, it's pretty simple, but once you begin to build real-world apps, with 30 or 40+ components, and their children, I just found passing state and props around a bit messy and hacky. Of course, then you introduce Redux, and all is well. But now you have to deal with transducers and actions, and so on. I just didn't find the tradeoff worth it, and prefer native development.

I'm sure every React developer has at some point found themselves banging their head on the wall trying to figure out why some child component isn't updating.

And yes, it's a personal preference, but I'm also not a fan of Javascript. If another client wants a single codebase app, I'm really gonna give Flutter a nice long look. I've read the docs, and it looks quite appealing.

Check out React context to avoid this property passing, which is annoying, I agree.

Did you know that Redux is now basically built into React?

https://medium.com/simply/state-management-with-react-hooks-...

https://blog.logrocket.com/use-hooks-and-context-not-react-a...

In contrast,

https://www.simplethread.com/cant-replace-redux-with-hooks/ https://daveceddia.com/context-api-vs-redux/ https://medium.com/javascript-scene/do-react-hooks-replace-r...

TL;DR Context can replace some but not all of Redux. Redux can figure out which components to rerender based on what's being computed. Context doesn't, so it's basically the same as refreshing your entire component tree every time something changes. You could build it yourself, but at that point, you're just reinventing Redux.

I also like the Redux Toolkit (https://redux-toolkit.js.org/) which is an opinionated way to write Redux that cuts down the boilerplate a lot. createSlice is easily one of the best features, you can encapsulate Redux logic for each different type of content, like authentication, users, posts, etc.

Glad to hear that RTK is working well for you!

I'm currently working on updating the Redux core docs to teach RTK as the default way to use Redux. Hoping to have the new "Quick Start" tutorial page up in the near future.

Flutter has a few different state management techniques, and even a Redux implementation. Provider is the most commonly used one.

For Redux with React, you could check out Redux Toolkit (https://redux-toolkit.js.org/). It solves a lot of the boilerplate issues with Redux. createSlice is especially valuable.

Not sure why NativeScript and Ionic are not more popular on HN, I've seen more success with both of these than React-Native.

I guess the first is not backed by a big company and the second still has the Cordova stigma.

I'm kinda surprised that everything "just works" for Flutter, even on Windows and Linux, which the official documentation seems to say are still in alpha stages and might be subject to breaking changes in the future.

I also couldn't find ways to easily implement things I want, e.g. native Mac MenuBar bindings/Mac App Store payment library etc.

Eventually I ended up using Quasar https://quasar.dev/, which allows you to use one Vue.js codebase but deploy to Cordova on mobile and Electron on desktop. Vue is definitely not the prettiest solution out there, but I had to be practical and actually get the app out.

Maybe I'm just one year too early for React Native/Flutter ecosystem to be developed enough for my app. The landscape is certainly changing rapidly, which is good.

Yes, Flutter is useful for when you have GUI heavy apps, not necessarily ones with platform integration like menu bars and cameras, although that is progressing pretty well I'd say, people are writing plugins for platform capabilities.

Regarding Windows and Linux, I too was surprised at how well everything worked. You can't build to production yet for these two platforms (officially at least, see flutter-rs for unofficial implementations), but the debug builds still work as well as the Android and iOS emulators. I used them on a lower powered machine to run my Flutter apps and it was great that they worked well.

Those JavaScript cross-platform solutions are opaque boxes that run basically their own operating system within an operating system. This comes at a penalty of a non-standard UX and higher than usual CPU usage and memory usage. But after they tackled that hurdle (like Visual Studio Code, excellent work), they still lack a lot of platform standard goodies like Accessibility and AppleScript.

I prefer solutions like Xamarin / Mono where you can have a Cocoa UI coupled with C# or F# based dll's. Let's be honest, as long as you have a good way of maintaining a good state in your app for example by already using ViewModels that did most of the heavy lifting like formatting strings, having the state in a state machine and so on, getting the UI to work as required is just an exercise of filling in the colors between the lines.

Barely anyone would notice they were using a Xamarin based solution on a Mac, while the JS based applications are immediately really obvious to the trained eye.

It's almost like people want a new markup language for defining interfaces that isn't based on JavaScript.

Flutter seems to be gaining ground on React Native. And they also have web and desktop ports. Recently flutter overtook react native on Google trends.

Any other evidence? I don't "feel" this, flutter seems to be floundering from what I've seen.

Same feeling here. still waiting for that killer flutter app to convince me one can actually build a real app with decent latency in flutter

What do you mean by killer exactly?

Splice is now on flutter, including web. I'd say that is a pretty demanding app.

A killer app is something like Rails. Rails made Ruby popular, because it was so good that people who otherwise wouldn't have been interested in Ruby were willing to use it for the benefits they got from Rails.

I suppose Flutter is Dart's killer app, since you're comparing frameworks and languages. Rails is to Ruby as Flutter is to Dart, as it were. I suggest you give it a try. Personally, this felt like the "killer" feature to me, fully advanced animations that I'm not sure are possible on native widget based frameworks: https://www.youtube.com/watch?v=FCyoHclCqc8

Wouldn't Flutter be the killer app to Dart as Rails was to Ruby by your analogy?

Maybe? I don't know enough about it to say. I was just trying to clarify what a "killer app" was by using an example.

I checked out Splice and they are using Angular/Rails for their web app? Both builtwith and HTML source code for their marketing website and logged in app indicate this.

I watched their talk video [1] and they seemed to have only built an MVPish app using Flutter (ie, less than a year using it + a team of two devs). And it only seems to be for the desktop app?

Maybe I'm missing where they are using it on the web... but I wouldn't call this a huge buy in.

[1] https://www.youtube.com/watch?v=FcjPNKmyrlM

I mean an app with a large user base built in majority with flutter.

The problem with flutter is you never know when Google will stop investing in the product at any moment when the devs shift their priority.and let it die on the vine.

People love to say this but rarely provide concrete examples. Google has a habit of discontinuing unsuccessful services, not technologies like SDKs or whole programming languages.

Angular.js is currently causing problems for me, as it's going to be unsupported in about a year.

https://angular.io/guide/upgrade

The point is precisely that I have to do that.

GP asked for evidence of Google abandoning things, and Angular.js is exactly that.

Upgrading to an incompatible framework is not supporting the old one.

If you can "upgrade", then it's not incompatible.

Every major revision of software has breaking changes (or as you call them, "incompatibilities"), some more than others (see Python 2 -> 3).

That doesn't mean it's "abandoned". Google made major API changes and renamed it to better communicate that it's not some simple JS framework – calling that abandoned is disingenuous. It's only abandoned in-so-far as every old version of every software ever gets abandoned at some point.

Excuse me, I used imprecise language.

I cannot upgrade.

I have to port, due to the backwards-incompatible changes.

Those changes may well be for the better, but for those of us maintaining stable programs, porting means increasing risk of failure for no perceivable end user benefit.

Microsoft is much better at supporting old tools and software, at least historically.

AngularJS

Dated, but Google Gears?

Hit me up on Google Wave and I'll explain it to you.

It makes me think of Google Web Toolkit.

Not exactly abandoned - it seems to have been maintained for 10 years, although no stable release for the last couple of years.

It does feel like it would have been a dead end to get into though.

My worry with Flutter is the same - it won't get large enough adoption by other tech companies, and Google will move on to something else.

I think it'll still hang out as open source project. But will it get the large investment to make improvements as the various OSs change over the long time?

Particularly outside of the US, in my experience. Having spent considerable time in React, RN, and Flutter the difference is remarkable. Unless devs are big fans of JS, Flutter is a compelling alternative [1].

1: https://blog.benroux.me/us-devs-are-sleeping-on-flutter/

Your conclusion re: Cordova is pretty outdated. Also these days folks are moving to Capacitor instead.

Cordova has a pretty high "Would not use again" score: https://2019.stateofjs.com/mobile-desktop/cordova/. No data on Flutter or Capacitor unfortunately.

Windows Forms was released on 2002 and is still supported by Microsoft. How long do you think Flutter will be supported by Google? For dev technology, Microsoft has a well-deserved reputation for supporting products for a long time.

It... depends. Remember Silverlight?

The last version of Silverlight, Silverlight 5 is actually supported until next year, 10 years after the initial 5.x release, which is not really "short" by any standard.

It's mostly the browser's ecosystem moved away from these for more standard based approaches.

"Supported" in a sense of patching security holes, sure. Not so much in a sense of writing new apps in it, or using modern tools to maintain old apps (support was dropped in VS 2017). So in that regard it's very unlike MFC or WinForms, which both enjoy continuous tooling support, and fixes and minor enhancements outside of security.

FWIW, I think your criticism is broadly valid, in that it's more of an exception for Microsoft, but much more common for Google. It's not hard to look at the Windows dev ecosystem, and see which parts of it are very stable, and likely to be around long term - because they have already been around for very long indeed.

I think the difference between MFC and WinForms, compared to Silverlight is that former are still widely used. albeit less than in the past with a lot more prevalence of web based applications.

Silverlight in other hand is a technology no modern web browsers support (in the same camp with gradually deprecated Flash and everything that requires plugins.), and perhaps to Microsoft it's a lot less justifiable to update it beyond security update.

Ahh, the good ol days. I lost count of how many Xaml-based UI Frameworks got released. In 2011 I started learning web development for UI, almost immediately after Microsoft announced Windows 8 and WinRT at build. This graphic [0] was the writing on the wall.

[0] https://softwareengineering.stackexchange.com/questions/1555...

To be fair, not all of them were like that. E.g. WPF is very similar to WinForms, in that it doesn't see any major new features, but there's constant ongoing maintenance (including fairly big items, such as getting it to run on .NET Core), and all the development tooling is fully supported as well.

> How long do you think Flutter will be supported by Google?

I am curious about how often this sentiment gets brought up about Go or Kubernetes.

Go and kubernetes clearly have reached a critical user mass that makes one confident other companies will maintain it even if for some reason google abandons ship.

flutter on the other hand is tremendously complex, and has yet to display any major company having bet their future on it.

At least Kubernetes won’t be in trouble since its no longer under the aegis of Google. CNCF is now the maintainer.

Go can easily within a year fade away to be replaced with something else. Remember MongoDB?

MongoDB still seems to be around and kicking?

I'm still a MongoDB cerificated developer. The popularity has dropped as with the amount of positions available.

There may come a time when this applies to Go.

I'm curious, what seems to be the Next Big Thing that is superceding MongoDB?

My guess is returning to SQL databases. An SQL database can handle a surprisingly large workload pretty well and provides some very nice correctness guarantees.

Graphql. Managed databases. A new beginning with Postgres for some.

Postgres is not new. It was part of my stack 10 years ago. So many new people have moved to postgres it has become hot.

I guess it depends on how frozen Go features happen to remain. while all modern alternatives release their value types + AOT tooling support.

I would be careful with Flutter’s web port. It’s going to be a pretty divergent approach in terms of web dev familiarity, bundle size, and compatibility with native web features (they had to implement copy and paste from scratch, for example). It is very similar to the approach Famous took back when. It is not looked kindly upon by many web platform advocates I know.

The Flutter web port is ridiculous. It circumvents the entire point of a Web page as it's literally just a canvas on the Web page.

You lose all advantages that HTML and CSS gives you, links, styling, accessibility, text selection! ... It's basically a flash website... Which admittedly is okay for some applications

It's Flash all over again, with a fresh coat of paint.

Isn't this consistent with Flutter's approach in general, though? On iOS, Android, etc., it uses its own widget toolkit and does its own rendering, it's not a wrapper over the native toolkits and renderers.

You might be misinformed; according to https://medium.com/flutter/hummingbird-building-flutter-for-... Flutter for Web uses HTML & CSS where it can, and falls back to Canvas where it can't.

Flutter for Web is still on Beta, so lets see where it lands. Today, it seems to implement some PWA practices and lazyloading to try and get some performance.

Well that article is from 2018 and kind of overemphasises the HTML and CSS where it can.

Checkout the official [1] Flutter web demos. Even the simplest [2] example renders basically every part of the UI (including text!!) within canvas elements, which is a bit crazy to me... but yes it's still Beta, so we'll see what they can improve

[1] https://flutter.github.io/samples/#?platform=web

[2] https://flutter.github.io/samples/web/animations/#/

Wow that's pretty insane. I can't select any text on any of those examples, I can't open anything in a new tab, and I can't save any images.

For some web app, that's a feature

I wonder how SEO is handled for web applications built with Flutter since its mostly canvas.

They also create a thousand webcomponent wrappers to display this.

I got a big grey screen on the first three I clicked. Not sure if this is ready for prime time...

Is it WebGL?

I only did some reading about Flutter for web and I kept thinking "Wait ... is this the web anymore then?"

Admittedly I need to go back and check but it was confusing and worrisome.

Not sure what browser you're using. But here it's actually using webcomponents and CSS houdini to render all demos I tried. Nowhere did I see any canvas usage.

I look forward to the day when the folks that shout the benefits of Electron desktop development start screaming over Flutter ruining the web because “it ignores everything that’s good in the browser!”

> Recently flutter overtook react native on Google trends.

How did you query this? I want to have a look, but the fact "flutter" shows data since 2004 means the terms I'm using are inflated [1]. Flutter is a dictionary word after all.

[1]: https://trends.google.com/trends/explore?date=all&geo=US&q=r...

Don't limit your search to the US. The "dictionary word" problem is reduced in worldwide search, which shows a more convincing trend for flutter. Though I wouldn't say it has a large or clear-cut lead on React Native.

https://trends.google.com/trends/explore?date=all&q=react%20...

Oh true, good idea!

The community is finally at its first apex. I tried it this past weekend, and the VSCode setup was so sexy and easy to get started. I dropped React-Native in a heart beat, even losing a few weeks of work.

The biggest gripe I have with React-Native is the many JS packages on npm that we can't use due to how the code is exported. It's a huge hack job, which Flutter absolutely destroyed by having everything I needed as a package that just worked.

One thing I'm looking at on Flutter, is how their public packages age. If I can't use a 3 year old package on modern day Flutter, there will be some big problems coming soon.

A three year old package would be an issue with Flutter. The move to Dart 2 was not backwards compatible.

That said, there's an effort in the community to find maintainers for older packages that people find useful. If you come across something that you need, post back, or shoot me an email.

Flutter on desktop has been "right around the corner" for about 5 years now.

But Flutter didn't come out until 2017?

Not for iOS and for the public, but Google had been talking about and demoing for a long time before that.

I've been building in Flutter for desktop (macOS) for a year and a half. It's _still_ feeling early, but if you're comfortable writing a bit of native code, it pretty much just works (for single window applications — hopefully that changes soon).

Writing code I'm fine with, it's coaxing other peoples' code to build that drives me nuts.

Flutter on the web is absolutely insane. For those who don't know, it basically strips away everything and wraps it in a big terrifyingly complex mess of code and renders everything in a canvas. Flutter advocates like to claim that that's "only a fallback" for when things get complex but as far as I can tell the vast majority of things (including the simplest examples from Flutter itself) force the entire thing into canvas: it's basically Flash 2.0, but worse.

I seriously hope that Flutter fades. It's very dangerous in many ways. Even ignoring the huge downsides of basically having a new Flash, consider this: the massive Flutter layer is, surprise surprise, yet another Google project that is magically _significantly_ slower in Firefox. I don't mean a small difference here, I mean that on a brand new fancy flagship I tested on, Flutter in Chrome is buttery smooth and Flutter in Firefox is a miserable, laggy experience. If it gets popular, this will become yet another reason pushing people off Firefox and cementing Google's dominance of the web.

Flutter is a very, very dangerous thing.

Adobe Flex was my most productive client development experience over the past 20 years. I transitioned to Android _but_ there were many hideous things with that (e.g. ghastly emulator, legacy Java support etc.).

My personal hope is that Flutter gains traction and the web can move beyond current web/native technology. Postscript / PDFs aren't suitable for game experiences...and to my mind web standards have been shoehorned into supporting web apps, where there is a mismatch with native technologies. I'd like to think that Flutter can help bridge that gap.

This is not to say that accessibility etc. should be ignored...nor better support in Firefox...but even Brendan Eich is using Blink/V8 with Brave.

Anyhow, thoughts of one.

Ahhhh Adobe Flex with MXML and ActionScript3. Before Typescript and React with JSX got popular that was the cool kids club. RIAs yo! Rich internet applications.

I loved what Flex brought to the table. Too bad Adobe didn’t open source flash and let it die.

It lives on in web APIs

As hated as flash was, there was a whole creative ecosystem of really unique games / art pieces that died off with it. A shame.

This is an insane approach on all platforms and it's depressing that Flutter is gaining mind share. Throwing away the whole platform and rendering everything from scratch with OpenGL/Vulkan etc is just flabbergasting.

Having worked with/on React Native for ~3 years I am definitely not a fan but at least React Native enables using native components directly even if this happens too rarely.

Goodbye accessibility.

I'd love to abandon my C/C++ UI frameworks for React, but I need

- consistent rendering/support across multiple platforms and versions

- multiple windows

- rendering to a window that isn't owned by the UI being rendered or created by the framework

Can I do that all in React native? Edit: don't need to bring up electron.

Wasm

With WASM though you will still have to have the app be deployed within browser context. Thus losing hotkeys to the browser etc

Or you can build native WASM apps?

That's probably where Blazor is eventually heading to?

There seems to be some preview on the mobile native, though, it's probably not strictly a WASM as it provides binding through Xamarin...[0]

[0]: https://devblogs.microsoft.com/aspnet/mobile-blazor-bindings...

No actually. There are projects that can run in a server. The spec doesn’t say anything about web only.

That's absurd; if you're shipping a native app you can compile native code.

what the heck is that third one about?

maybe an OpenGL type of rendering?

I think they mean stuff like XAML islands in Win32.

I work with applications that generate windows and manage their lifetimes independently of whatever is inside the window. afaict, most web/mobile UI frameworks assume they're the only thing in the universe, whereas on desktop there's a complex application managing zero or more rendering surfaces and portions of the code only know about the one that they're supposed to target.

It's a hairier problem than you'd expect it to be. I'm not an expert but my understanding is that it's tricky to deal with the event loops when you're not the master of your domain, at least in a platform agnostic way. The workaround is usually to spawn multiple processes, but then the management of app state has to have an IPC layer underneath the internal APIs and there needs to be a master daemon running somewhere.

In keeping with front page posts, the plugin API for Apple's Logic Pro (audio units) is an example of that. You are handed an NSView* and need to render on it, but you don't create it.

I think it means using the same process to control multiple windows simultaneously. You can do it with various C/C++ libraries and .NET, but IIRC not Electron, which leads to the question: can you do it with React Native?

Electron can't do multiple windows or consistent rendering?

Legit question, I just started using Electron, hadn't heard of the former and thought the latter was a selling point because all platforms wrapped Electron's Chrome.

Electron supports multiple windows, but it ends up being annoying to do because each window runs in its own process. If your app has any kind of central state that's shared between windows, you end up copying data between processes frequently, which can be slow.

Rendering consistency is generally pretty good; I haven't run into any issues with that.

just ship everything with sqlite :) it'll be fine

This bugs me to no end about Electron. The one module that existed to implement cross window / process communication is deprecated with no alternative. I haven't found a solution for multithreading in electron without killing the base process (which they explicitly say NOT to do compute in) or the rendering process (duh).

Web workers launched from the renderer work fairly well if you just need compute. I think I've also seen some apps add an additional BrowserWindow that's never displayed onscreen, although that will increase your memory overhead.

This list is && not ||

Wouldn't it have been more concise then to just state that you "needed a framework that supported rendering to a window that isn't owned by the UI being rendered or created by the framework"? I guess now I'm even more confused about what Electron supports...

EDIT: Ok I see now, you listed your requirements and just stated that Electron doesn't satisfy them. The construct is confusing to me because the way it's worded seems to suggest Electron doesn't satisfy any of them, but I understand now.

Yea sorry for being unclear, I meant I need to do all those things. I have evaluated electron in the past and tried to hack the things I need unsuccessfully, but I don't keep up with it so I've edited my comment.

This is electron by another name, Microsoft is forcing us into a web sandbox.

If electron is Chrome and Edge is Chrome and Microsoft uses Edge for this - then its all chrome in all directions. Native is much faster and more powerful - WE MUST RESIST!

https://www.youtube.com/watch?v=_p6tvs-qjpA

Is this true? React native for ios and android draw with native widgets, not a DOM.

It is not.

Here's the GitHub for the Windows implementation: https://github.com/microsoft/react-native-windows

And here's the fork of React Native for the Mac one (it doesn't seem to be as polished as the Windows one yet): https://github.com/microsoft/react-native-macos

I would be very surprised if they didn't use any pieces used by Edge (how else would they render css?). A quick search of their code though and I couldn't find it. Perhaps I assumed too much

React native doesn't really use css - there are no .css files, no cascading either. It's more like a style engine that uses a subset of css ideas as a starting point.

It uses flex-box (and only flex-box) for layout, adds some convenient shorthands - marginVertical, marginHorizontal, and does some surprising (but useful) things like has transform take a JS array of key value pairs - https://reactnative.dev/docs/transforms#transform

They do a translation between CSS/flexbox and the native UI layer, just like on iOS and Android

It doesn't render CSS, not in that context. The way styling for layout and for colour/text/etc is specified is designed to match a subset of CSS so that developers can easily transition across to the platform, that's all (and for layout it uses an engine called Yoga, which implements CSS' flexbox spec). So in the context of actual component code, it's a layer designed to look like CSS that can generate whatever the backend being used requires to render (so it should be able to produce valid CSS as an output, as in the case of React Native Web)

This is misinformed.

React scripts native widgets, not HTML.

You could use Flutter. It has the first point, but I am not necessarily sure about the latter ones.

You should be able to do all this, if it is as flexible as RN for mobile

VST2 just has to die already

Sciter then (https://sciter.com):

- multiple platforms...

Yes: Windows (x32,x64, ARM64), from XP to 10, MacOS, Linux/GTK, IoT and mobiles.

- multiple windows -

Yes. Multiple desktop windows and you can even render separate DOM elements in popup windows.

- rendering to a window that isn't owned by the UI being rendered

Yes, you can render it on top DirectX, OpenGL, Vulkan (coming) or in child window/nsview/gtkwidget. There is also Sciter.Lite that allows to render UI without any DWM - on frame buffer / video memory directly. Check : https://sciter.com/sciter-and-directx/

- don't need to bring up electron.

Not Electron. All this in monolithic dll/so (5..9mb) that even can be linked in statically.

- consistent rendering across multiple platforms.

Check screenshots of https://notes.sciter.com/ , are they consistent enough?

- ... for React

React (Reactor in Sciter terms) is implemented natively. JSX (SSX in Sciter) is a part of language/runtime - no need for additional compilers, etc.

- I'd love to abandon my C/C++ ...

No need to. You can still manage (update, handle events) UI directly from C++ if needed. You can even create custom native DOM elements that can even draw themselves by native code.

Kind of a chicken and egg situation, I looked at sciter for a project about a year ago and estimated that it would cost more time/money to get things off the ground in your framework than using my existing codebase and frameworks with larger ecosystems.

I can't really commit to sciter and your flavor of JS until it has a larger community, more docs, and more onboarding materials so I can get teams up to speed and working quickly, reinventing fewer wheels, and have more discoverability in your docs and community so I can even know how to do things and what I don't need to rewrite.

Some bencharks comparing engine performance to V8 would also be much appreciated.

1. I've been told that it takes 1..2 weeks for average front end developer to get into Sciter and features that I've added to HTML/CSS to support desktop UI use cases.

2. "larger ecosystems..." Sciter is embeddable and extendable engine, this means that you can extend it by existing native libraries, time proven and effective. Here is how SQLite native namespace looks in Sciter: https://github.com/c-smile/sciter-sdk/blob/master/sqlite/sci...

3. "it has a larger community..."

I am aiming not to larger but rather more professional community. Sciter sources contains patches from these dev teams: https://sciter.com/#customers Security audit was made by Symantec and 3 more AntiVirus vendors. All that... Source code base is compact enough for a C++ programmer to get into when needed.

"Some bencharks comparing engine performance to V8"

Slower than V8 but faster than Python 3. But script performance in Sciter is not that critical (never been a bottleneck) for simple reason: script treated as a glue between native function calls. If you need something to run with bare metal speed - just provide native function(s) for this functionality. JS approach in this respect is simply crazy: to run something fast add megatons of JIT implementation and then another twist: WebAssembler. Why not just to compile what is needed with C++ into native code and call it? Again, Sciter is embeddable and extendable by design.

Very interesting work. I need to re-evaluate in the future.

HTML is half of the problem, the DOM is just fundamentally unsuited for app UI rendering, and CSS is a nightmare when applied to UI controls rather than text documents. What we need is a cross platform well-thought-out scene graph like Flash had or Flutter (kinda) has.

> the DOM is just fundamentally unsuited for app UI rendering...

Consider the following:

Native UI: is a tree of widgets. Each widget has sematic properties / attributes. Each widget may have style properties (colors ,fonts, etc.). Each widget has exactly on parent and may have multiple children. There is an API for all of these.

HTML/DOM UI: Same as above, just replace "widget" by "element".

Could you explain then why one of these is "fundamentally unsuited" and other is a perfect match?

The most glaring is the ability to measure things (including text) in order to lay them out, rather than adding stuff to the tree and waiting a while for somebody else to lay them out in order to measure them. Followed closely by absolutely everything about the way overflow "works". After that I'd add the absolutely batshit insane hoops through which one still must jump to build any sort of text editing component without throwing away all the good things about HTML like accessibility; the things going on inside Visual Studio Code required to produce even an experience as good as that must haunt the team that builds it. The disconnect in process between "building something out of built-in components" against "build and using a new component", the list goes on.

And just about all of these things are made worse by both the cascade rules and complicated precedence system of CSS.

> The most glaring is the ability to measure things (including text) in order to lay them out ...

This has nothing with the DOM (or HTML or CSS for that matter).

Yes, sometimes in desktop UI you will need to know exact element position/dimensions. That's why in Sciter I've added:

1. element.update(); method, it will force dimensions to be calculated at this moment.

2. element.onSize = function() {...} called when dimensions of the element change.

3. element.paintContent = function(graphics) {} called to paint the element on graphics. Dimensions and position of the element is known at this moment.

4. There is a Graphics.Text object that allows to calculate (not just render) text and glyph positions.

My main point with all this: it is a matter of API provided and has nothing with HTML/CSS per se.

For that matter, Flutter also uses DOM (tree of widgets, etc.). It is just that its style system is not declarative and misses cascading - for some reasons they decided to use WPF/XAML way of doing business. But we've already sang "Sic transit gloria mundi" to WPF ...

For the text editing... check html-notepad : https://html-notepad.com/ . Left sidebar (structure outline) is computed and painted in immediate rendering painting mode - when paintContent of the document is invoked.

When I wrote "DOM" I meant the DOM as in the W3C one you're looking at right now, not Sciter, which I haven't used. Nothing wrong with the concept of trees of objects, other than the fact the tree usually forms part of the objects.

The biggest problem I have with html/css is that the outcome seems unpredictable; I sit with very experienced web devs and still have to do trial and error sometimes to know where what will be and of what size. I hear, way to often, when I (backend/embedded dev) ask how to ‘not make X happen’ something like ‘try this or this’ after they check my css. How is that software development if you have to guess how things work? Maybe it is because I am a backend dev, but we have this issue far less with native dev; they just say ‘do this’ and indeed it works as expected.

HTML is for document/flow.

Only with flexbox it became kind of usable for "apps". But still, the widgets are not native. You can keep emulating and emulating, but it's very easy to spot and quite frankly super annoying.

This is actually amazing. Thanks for sharing.

I see someone actually submitted the homepage 40 mins ago so I upvoted it for awareness. This is so feature complete I'm frankly surprised it hasn't hit the front page before.

https://news.ycombinator.com/item?id=23163320

Consistent cross platform: This is actually the one thats probably most difficult with react-native. Since unlike electron or Flutter, React-Native uses native UI for each platform. This means you can achieve full parity with native apps in terms of the UI. But all the platforms have different capabilities so since react-native can take full advantage of all the platforms, and isn't lowest common denominator, there are differences between the rendering / support across multiple platforms.

Can the native UI framework do multiple windows? - Then React-Native can do multiple windows.

Rendering to a windows that isn't owned by the framework is what React-Native refers to as Brownfield apps. This is absolutely supported. For instance, Microsoft Office is using React-Native for some parts of their UI in Android, iOS, Windows and macOS. And the Office window is not created or owned by react-native.

For that matter: Sciter supports use of native platform (or custom) native windows or widgets. For different reasons an combinations. I saw cases when even Qt widgets were used as DOM elements in Sciter controlled main window. So you can get best of two worlds - flexibility of HTML/CSS (rendering, layout managers) and native UI behavior and look.

> - rendering to a window that isn't owned by the UI being rendered or created by the framework

I once used a native library I installed with iOS' native package manager, Cocoapods. I rendered a React Native view inside the native view, which was contained inside a react native view. The only limitation is that the two react native views used separate bundlers i.e. the two react native views can only communicate through the native platform, they couldn't communicate to each other via JavaScript.

Java?

STMicroelectronics uses it for almost all of their applications, which ship in one zip file with binaries for Win/Mac/Linux.

It ticks #1 and #2, but I don't know about #3.

Of course, I'm not sure if having web-like programming is your implicit #4?

Revery comes to mind here.

MacOS implementation here https://github.com/microsoft/react-native-macos

While personally I dislike React Native in the strongest terms possible for the number of nigh impossible to debug technical issues it has brought the projects that tried to tame it, there is a really interesting moment happening here. Microsoft is embracing Facebook's cross-platform tools to eventually compete with Google's cross-platform Electron. Microsoft currently relies on Google for the internals of VS Code, Github for Desktop and many more of its popular pieces of kit, and it doesn't seem very happy about it.

My own experience with React Native has been nothing but terrible, but it will be interesting to see how all of this will play out in the long run.

V8, Chromium and Blink are an Open Source projects that Google is one of the main contributors to, but they're not 'Google'.

If Google went away tomorrow, V8, Chromium and Blink would still exist, and Microsoft would be able to use all projects.

The problem isn't the projects going away, more so that Microsoft has no control over where those projects are headed. If Electron moves in a direction that works well for Google but not so well for Microsoft, they can't do much about it unless they want to pick up maintaining a full fork.

Google doesn't care about Electron, much like they don't care about node.js, despite those projects relying on tech Google contributes to. Whereas Microsoft does care about Electron.

Sure they are open source projects, but the majority of dev work is done on Google's dime. Google employs many of the most important people in these projects. Sure the code will still be there if Google gives up, but will anyone have the capacity to step up and maintain them?

Yes. Microsoft would hire them, and already is doing do.

There's plenty of commits to V8 from outside Google. Blink is a fork of a fork of a twenty year old project.

Fascinating that your experience has been the opposite of mine. Did you do native app development before trying react-native?

My unconventional take is the real gains from react-native come from converting existing native projects, while leaving as much native code intact as possible.

I think the killer feature here is natively targeting Windows AND macOS simultaneously.

The only cross-platform alternatives that I've seen in the ecosystem use either web or Gtk in the frontend, and both of these have a distinctly non-native feel to them.

In which ecosystem? If you mean desktop apps in general, then there are many other options. Qt and wxWidgets, to name a couple of popular ones that have been around for a very long time.

My problem with those two is the damn C++ API. I’ve used both in the past, but I’ve moved on from C++ for desktop applications to greener pastures but these toolkits’ APIs are a pita to use via ffi.

They're both pretty popular to wrap; I'm surprised that whatever language/ecosystem you're using doesn't have a wrapper lib already.

Delphi does this. GDI+/DirectX on Windows, OpenGL on macOS, and GTK+ on Linux (and OpenGL on Android and iOS). Single source responsive UI.

nice, means that Qt apps fit well enough that you don't even notice them :p

The latest Xamarin is no longer mobile-only for Windows and might potentially fit the bill here.

Xamarin targets windows/mac/ios/android/UWP/tizen natively.

Killer vaporware, classic Microsoft FUD modus operandi. Mac is “coming soon.”

I've been working with Xamarin / Mono and having a Cocoa front-end with a C# back-end is really the best of both worlds. Everything looks native, is snappy, uses relatively little memory and all of the not so immediately visible Good Stuff for macOS like accessibility, document state and AppleScript just works out of the box.

Most cross-platform solutions are awful in at least one of those three, usually all of them.

PyQT with QML / QT Quick is another option for cross-platform (Android, iOS, Windows, Mac, Linux) development, but the widgets aren't native. It's closer to Flutter in that way.

QT Widgets, in contrast, do have native-looking widgets for Mac and Windows. You can use it with Python instead of C++, but it's a bit of a pain, and most of the Qt community seems to be moving towards QML, which is a far better developer experience.

I'm really excited, although the Mac part of this page is somewhat misleading — there isn't anything available on the Mac side yet (everything is "coming soon")

you can checkout the code here https://github.com/microsoft/react-native-macos. It still being actively developed and not yet ready for release.

react-native-macos is available today. The documentation is linked on the sidebar: https://microsoft.github.io/react-native-windows/docs/next/r...

I've used React Native for a client and, whilst it was super clunky, I still enjoyed being able to write React to deploy to mobile. With React Native for Web, you can technical write code that writes to a bunch of different platforms, a big selling point for businesses.

Check out Ionic which now fully supports React and will give you a similar benefit but without the need to use RNW or have different code for each platform. Also Ionic’s components are much more robust and widely used than RNW.

I agree that Ionic's components are easier to work with and less of a hassle. However, React Native components let you talk directly to native, even using native components from the native platform's ecosystem in your code. It's a tradeoff developers have to make.

https://github.com/wix/react-native-navigation is beautiful, it uses iOS' own navigation APIs, but it's a pain.

That’s fair! One other option is to do both: use Capacitor and embed it inside native navigation controls (i.e. a native shell), then use Ionic React for screens, etc.

One other aspect is that Ionic React uses react-dom so it will be a pretty normal react dev experience compared to RN which isn’t 1-1 (CSS being an example).

> Windows

> We are actively developing React Native for Windows...

> Mac

> Coming soon

So React Native for Windows.

Don't forget... Microsoft <3 Linux. You can tell it's a top consideration.

They don't <3 desktop Linux and probably never will. To them, Windows and macOS are the major desktop operating systems, and Linux is the server operating system. VS Code likely only runs on Linux because Electron runs on Linux.

Yeah, MS's <3 for Linux started with their patent racket aimed at Red Hat and Suse. Let's also not forget their bankrolling of SCO's anti-Linux lawsuits in the 00s. "So sharing, so caring".

It’s literally linked to from that page, just not ready for release: https://github.com/microsoft/react-native-macos

I wish someone would take a web renderer, took the Javascript away, made a native react-like library for it, and made a universal interface to it so any language could use it. That would finally fix the problem with the UI building issue, while allowing flexible language access. That would be the best of both worlds.

sounds a lot like what wasm is trying to achieve (minus the web rendering part)

I asked this on a previous React Native thread, and I’m still curious: is RN (on mobile, as that’s where it’s currently used) actually faster than something like PhoneGap? Are there any benchmarks or demos? Anyone got any anecdotes of a like-for-like comparison?

I’m skeptical (though certainly willing to be convinced) because RN runs your JS application in a separate thread from the UI, with a rather expensive bridge sending JSON messages back and forth. That seems to me a poor design choice.

Browsers have the downside of working with the complex DOM that doesn’t map as well to native widgets. But browsers are mature and highly optimized. So I would guess that performance might be a wash.

Performance is just one reason companies adapt something like React Native, the ability to have web developers* come in and string native-quality components together is another. React Native can feel better than mobile web and have access to lower level APIs.

* I think this is more of a selling point than a reality. I think in practice, to make a React Native feel and work well requires native platform knowledge.

Yes its faster, for majority of cases.

But if you overload the bridge, you not only hit a bottleneck, you hit an async bottleneck between your UI code and native. Very rare for that to happen in my experience, and well worth the trade-off.

Not sure what the advantage here is over Electron. I know the chromium engine is a resource hog, but the scalability/mix between platforms makes it worth it. Curious to know what your thoughts are folks!

> Not sure what the advantage here is over Electron.

You can customize per-platform to provide a better experience than the web can offer.

EDITED React native's GUI compiles to native code. Or something like that. It is very different from Electron.

No, React Native still uses Javascript, not “native code”.

It’s different in that it doesn’t use HTML or CSS (which is a major difference, sure).

Does React Native use V8 internally then?

It uses JavaScriptCore on iOS because that's the Apple-blessed JS engine. On Android it bundles its own copy of JavaScriptCore.

It uses a combination of both JS and native code. That JS that RN calls ultimately makes calls out to native Andriod and iOS (and Windows, and macOS) APIs that are compiled to Java and ObjC/Swift (and, I assume, C#?). All of RN's targeted platforms leverage scripting bridges for JS, but only a portion of the actual running code is JS, the part that's native is (usually, but not exclusively) generalized.

It uses a combination of both JS and native code. That JS that RN calls ultimately makes calls out to native Andriod and iOS (and Windows, and macOS) APIs

Exactly like a web browser.

only a portion of the actual running code is JS

“Only a portion” meaning your entire React application! The native parts are the RN framework, any native libraries you’re using, and any native code you’ve added yourself.

What RN brings to the table, as compared to a browser, is a different layout model that’s simpler than the DOM and maps a bit more closely to native widgets.

It also has APIs for sending messages back and forth between JS and native code. That’s also possible with WebViews on all platforms, but RN has a more consistent API (at least on the JS side), so a decent amount of native bindings have been written by third parties.

> and any native code you’ve added yourself.

I think you undervalue just how important this bit is.

It’s so easy to bind your own native code to react-native, it’s quite the game changer for those of us that have been managing two (or more) native code bases for different platforms for the past decade.

I have successfully merged two separate projects for the same iOS/Android app into one by simply writing JS bindings for the existing native code and moving all the business logic to react-native. I probably deleted more LOC than I wrote, and it’s still 90% native code- this is a GPU intensive A/V app.

I’m not a web guy so I can’t compare it to vanilla web react, but for native app development RN has been a huge productivity boost.

> Exactly like a web browser. > > “Only a portion” meaning your entire React application! The native parts are the RN framework, any native libraries you’re using, and any native code you’ve added yourself.

Exactly, in the sense that JS is a hosted language in both scenarios, but that's pretty much where the similarities end.

In a web browser, JS is the programmatic interface to behavior after the HTML and CSS are rendered. With React, a function of props that returns a JSX data structure is a declarative-ish interface to additional JS behavior. It's JS all the way down to the renderer.

With RN, JS is an interface to a lower level UI API on the host OS. A function of props that returns a JSX data structure is a declarative-ish interface to a bridge to that API, which performs the actual work.

It's hard to visualize the difference when just thinking of a static output, but easy once you start to think about user events. E.g. there is no `onPress` in the JS bridge for these APIs.

All of React is JS. A substantial portion of React Native, itself, is native. That's the difference.

> What RN brings to the table, as compared to a browser, is a different layout model that’s simpler than the DOM and maps a bit more closely to native widgets.

That's... maybe part of what would attract a dev to RN, but certainly not all of it. It also brings actual (not just close) native UI, with all of the performance and UX expectations that come with that. And it brings the ability to implement performance-critical logic in the native environment while sharing a lot of the rest of your logic with code for other environments.

> It also has APIs for sending messages back and forth between JS and native code. That’s also possible with WebViews on all platforms, but RN has a more consistent API (at least on the JS side), so a decent amount of native bindings have been written by third parties.

If I'm not mistaken, that's how RN works. (I could be mistaken.) In any case... that capability is hardly attractive unless the API is not just consistent internally, but with APIs on other platforms.

> I know the chromium engine is a resource hog, but the scalability/mix between platforms makes it worth it.

Worth it for some. Personally, I refuse to use any Electron apps because they have a highly non-native-feeling UX and because they're resource hogs.

This announcement excites me, because React Native is likely to be an improvement on both counts.

The UX still won't be quite as native-feeling as a single-platform app designed for that platform's unique idioms – but as long as it uses native controls under the hood, that's still 10x better than Electron in my book.

And even without the bloat of Chromium, an app written in JS is still likely to be slower than one written in, say, C++ or Rust – but most GUIs don't really need that level of performance. And at least on macOS, the competition is not C++ or Rust but Objective-C and Swift, which are both slower, more on par with JS in terms of performance.

VScode looks and feels native and not memory intensive

VSCode is certainly one of the better (if not best) Electron application out there, but it is definitely memory intensive.

"When I use an editor, I don't want eight extra KILOBYTES of worthless help screens and cursor positioning code! I just want an EDitor!! Not a 'viitor'. Not a 'emacsitor'. Those aren't even WORDS!!!! ED! ED! ED IS THE STANDARD!!!"

Not making a point. Just couldn't resist.

Context: https://www.gnu.org/fun/jokes/ed-msg.html

It might feel native on platforms where 'native' doesn't mean anything (Windows, Linux), but the only native thing about it on macOS is the fact it has proper global menu bars — which is something provided by Electron for free.

Everything else is custom.

It uses the platform’s native APIs to render UI widgets, so it looks and feels like a true native desktop application, while still giving you a web flavored dev experience.

I'd love to see some dog-fooding on this. Maybe a branch of VS Code for RN.

I mean, say what you will about the quality of even Apple's own Catalyst apps, but at least they eat their own dogfood (although with the unfortunate consequence of making us eat it, too).

There are so many different competing projects at MS to do practically the same thing, it'd be great to see RN for Windows and macOS used for something major from MS.

Last I heard, they are using it for at least significant parts of Office and Skype.

There was a community effort[1] with similar goal on macOS. I was a tiny bit disappointed that they stopped working on it when Apple announced Project Catalyst. It's good to have MS carrying the touch on this topic.

[1] https://github.com/ptmt/react-native-macos

Looked at it a while ago when I was trying to start a cross-platform app (both on mobile and on desktop), but under the Mac section it simply said "Coming Soon!". I thought there's some update with this post receiving so many upvotes, but apparently it's still the same, and Mac support is still in a very early experimental stage.

Flutter left me a similar impression.

I eventually ended up using Quasar https://quasar.dev/, which allows you to use one Vue.js codebase but deploy to Cordova on mobile and Electron on desktop. Vue is definitely not the prettiest solution out there, but I had to be practical and actually get the app out.

Maybe if I started the project one year in the future, the landscape would be totally different already. It's definitely changing rapidly.

I think I might be on the same boat. I have personally looked into all frameworks and planning to hire a team, quasar seems is one of the options. The application isn't for any mission-critical application, revolves around curd. Quasar is a good option albeit with a lot of baggage, Flutter is clean but for Desktop use case it's still evolving. How was your experience with Quasar? Would you recommend Flutter over Quasar?

They supply short Counter example and claim they're both the same. However looking at the code button handler called onClick for react and onPress in React Native. Unless this is a simple typo why doing crazy things like that?

React Native is getting better all the time and it's mature already. I think people who criticize RN are the devs who had to work with the first few shitty versions of RN in a shitty complex project. I think that's the case in many, if not all, open source projects.

We do pretty complex stuff with RN as does Facebook and it's been serving us well. I don't know why someone would want to use it with Windows, but this tells how far the project has gotten.

I would love to developed native, but you just save a lot (maybe half) time using RN if you need the app for both platforms.

I looked at the docs, and checked the Calculator demo app. It a Visual Studio solution. I will not install Visual Studio because each time I install it (last time it was 5 years back now), my Windows Installation gets polluted with all kinds of packages that I now never ever been able to figure out how to uninstall.

I can copy couple of dlls in a project folder, and run npm / yarn install, but that is the most I am willing to do.

So, my question is: is there a VS Code / npm only demo?

As an ex-windows developer, turned react dev - I am excited.

I swear to gosh Facebook, if you tempt my employer into making me write Windows apps...

I would be happy to add Windows as a platform to my apps. More market == more money. Only as an add-on. I wouldn't want to write Windows exclusive apps for sure.

Not meant to disparage, but how lucrative is that market? How much do Windows users (outside of business) actually spend on software (regardless of business model)? It's a leading question, but a sincere one.

Who buys software outside of businesses? God I feel like I haven’t paid for a stand-alone piece of software in years.

I do. Not a ton, but enough to be a part of the drop in the bucket that makes the Apple ecosystem more attractive to smaller-purchase businesses that target it. I just... haven't seen much of that targeting Windows for a long time.

That's a good question. There doesn't seem to be much outside of famous software like the Adobe suite. That's excluding business of course. Most apps I want to make are business facing. However, I believe in web first for most of those ventures. Only making "native" apps if they're really wanted.

On the React Native MacOS fork:

> This repository is a working fork of facebook/react-native that adds support for the official React Native for macOS implementation from Microsoft.

Does anyone know when these changes are planning to be upstreamed?

RN's been available for many years, and little interest has been shown in providing first class support for desktop targets. That said, it wouldn't surprise me if:

1. the recent FB messenger desktop apps are RN.

2. they leverage work done in forks (like this one from MS) to achieve that.

React Native for Xbox seems like a step in the complete wrong direction...

Glad to see I wasn't the only one confused by the Xbox and game controller in the header.

(I mean, sure, it "just" runs Windows, but...)

> React Native for Windows and Mac

> Mac: Coming Soon

You know what, I think I'll wait for Flutter Desktop, or see who wins true cross-desktop compatibilty since Flutter already has Mac support but no Windows.

Didn't Microsoft use RN for building Skype or did I dream that?

Skype is Electron now.

The previous version of Skype was based on an older, internal-only fork of RN for Windows.

A decade ago, Java was the de-facto language to build a cross-platform desktop application (with Java Swing). Now it is JavaScript. So be it then....

Too bad Rust does not have something similar.

Is anyone able to provide a map of modern frameworks? With React-native, React-redux, Angular, Vue and probably a bunch of others.

I'm really not sure what's relevant now and what was relevant 6 months ago. I'm genuinely curious, but it's pretty difficult to grasp and no framework homepage is going to tell you "Don't use me, I'm about to be a dead project!" and every developer will tell you their preferred framework is the best framework.

I can provide you with a short video clip of spaghetti falling through the air, it's functionally equivalent

I don't know how often a project dies because it has planned obsolescence vs. people stop using and updating it, but for the latter case I think https://2019.stateofjs.com/ is pretty great.

Thanks, that's exactly what I want!

React, Angular, and Vue are the big 3 web frameworks. Of which React is still more popular than the others I believe, and it takes a slightly different approach. While Angular and Vue use string-templating DSLs to control rendering, React uses JSX which is a thin syntax sugar over JavaScript (and allows you to mix JavaScript in with it). React is also more functional. In practice I find this makes it more flexible, and easier to debug. Angular and Vue are very similar, but Vue has the reputation of being simpler while Angular is the Enterprise Java of the web view.

There are a bunch of others that are less popular such as Ember, Svelte, and Inferno which are also decent in their own right, but the ecosystem of libraries around them is smaller.

The most important libraries to know about in the React ecosystem are React-Router for routing, and either Redux or MobX for state management. There are other options, and for small apps you could get away without a state management library, but these are the mainstream options. I'm not super-up on the Angular/Vue ecosystems, but I believe they're more integrated (e.g. they provide more first-party libraries).

Almost everyone who is using these frameworks is also using either Babel or TypeScript together with Webpack for bundling. There are other options for bundling such as Parcel and Rollup, and again it is possible to get away without bundling or transpiling if you really want to, but Webpack is still the mainstream option for applications (Rollup is well-suited to libraries).

React-native is a different beast. It's a cross-platform mobile (and now desktop) framework rather than a web-based one. It uses React executed in a JavaScript VM to control rendering, but it renders native mobile UI toolkits. There are similar projects for Vue and Angular, but unlike the web versions which are competitive with React, they are nowhere near as mature. React-native's real competition for cross-platform mobile development is Flutter. Flutter is written using that Dart language, and takes a different to React-Native. Rather than compiling down to native UI widgets, it custom-renders everything. This makes it more reliable and consistent across platforms, but also more limited in what you can because you can't hook into the existing ecosystem of native ios/android libraries nearly so easily.

My subjective view on this is that React-Native is just about on the cusp of reaching maturity, while Flutter doesn't quite seem to have enough momentum to reach the mainstream. Although I'd love to be proven wrong on that one.

I don't think it's too common, but Vue does support JSX: https://vuejs.org/v2/guide/render-function.html

"I can't figure out what will be relevant in six months" might have been a legitimate complaint a decade ago, but those days are long gone.

React has been a core part of the front end ecosystem for almost 10 years. Angular is more than 10 years old. Vue is the "new kid" on the block at about six years old.

React is roughly 10x more popular than Vue or Angular according to npm usage, has been far more popular in usage terms for many years, and continues to be growing faster than either Vue or Angular.

Complaining you can't figure out if React or Angular or Vue will be relevant in six months is a bit like complaining you can't figure out if C++ or Java will be relevant in six months. Yes, there is lots of advancement happening in the front end space. Yes, that's a good thing. No, it's not an excuse to act like you're paralyzed to understand the current state.

React, almost 10 years? It was only open sourced 7 years ago and definitely took time to fully catch on..

I'm truly amazed to still encounter "omg React is so new and unproven how can we possibly keep up with stuff like this?" posts. Next up: is no-sql just another fad or will it catch on?

Who said that in this thread? (Nobody, they just pointed out you are wrong about the timeframe)

Oh, c'mon, that's a bit of a stretch.

I was around in 2014, when angular 1 was starting to be a big thing.

If you look at reactjs on google trends, react gets its first bump in 2014-15, and then another one around 2017.

VueJs gets a huge jump in 2016-2017.

---

Java has been around for decades, has had much fewer changes, and is entrenched in a lot of code. In comparison, react has gone through some big changes in a very short amount of time, and most people use it to build SPAs that aren't usually mission critical.

Everyone can set their threshold for when they noticed React at whatever point they choose. Regardless of when any particular individual noticed React, it has undeniably been a big deal for years and can be reasonably expected to remain relevant for years to come. The assertion that "omg front end changes so much how can I know if React will matter in six months" is simply nonsense.

React Native and React are two different things, no? JavaScript is not Java, Programming Pearls by John Bentley is not about Perl, C# is not C, etc.

No Linux support.

You could try moving https://github.com/justinmcp/react-native/tree/ubuntu forward. I no longer have the time.

Sounds crazy to say this, and I've had mostly positive experiences working with React Native, but sure hope everyone keeps using Electron.

React Native seems to be quickly becoming the standard for fast development coupled with native integration

If only it were stable

Does Facebook use it?

Yes

Only for its marketplace app

This isn’t true.

Unfortunately, `Good First Issue` and `help wanted` sections are currently empty for the macOS fork.

Excuse my ignorance. What's new about this? I thought React Native was already a thing?

React Native was a thing for native mobile app development. The post is talking about React Native becoming available for native desktop app development.

You mean when this came out 4 years ago? I'm not sure why this is being posted as "News"...

[1] https://news.ycombinator.com/item?id=11386595

[2] https://news.ycombinator.com/item?id=11490190

While it's not that new (has been public for over a year), this is a different, newer implementation of RNW (written in C++ instead of C#)

Much obliged!

React Native at least only advertises that it only supports Android + iOS, whereas this adds "PCs, tablets, 2-in-1s, Xbox, Mixed reality devices, etc., as well as the MacOS desktop and laptop ecosystems"

Thanking you kindly!

The web site reads "Mac coming soon" the headline reads differently.

Only a matter of months before VSCode will not be an electron app anymore.

. (dot) (ignore me, I need this comment to comeback to it in the future)

The mac related lib and docs are still ComingSoonTM

Why is Microsoft doing this instead of Facebook?

What would be the benefit over electron?

1. Not using the DOM for rendering. 2. Integrating native APIs is much easier.

> Being compiled to native code is a huge benefit.

It's still just running Javascript. The real difference is that it uses widgets that are native to the platform, instead of a browser engine/DOM.

It's not "just" running JS, it's also running JS. Part of the control flow into and out of the native widgets is JS, and part of it is abstractions over scripting bridges employed by RN (and its various forks).

Where's the Linux one?

Today an Electron wept

Of course, no Linux support, since this is still Microsoft :(

Classic HN - never anything positive to say about any story here.

React Native is best understood as an insurgent attack on native mobile platforms, funded by overwealthy and bloated companies that do not control mobile platforms, but feel entitled.

Microsoft and Facebook attacking Apple and Google basically.

IMHO it's not a sincere effort to make a nice platform. It moves fast and breaks things in major ways with each minor point release, with the current excuse being that it's not at 1.0 yet. But it offers just enough to introduce FUD into the competitors' ecosystems. And that's the entire goal as far as I can tell.

If you value getting useful deep knowledge, stay away. If you want to play in the shallows and be patching stuff up all the time with JavaScript/TypeScript, React Native is an option.

How are Facebook and Microsoft any more or less "bloated" than Google or Apple?

Also Discord's iOS app is built with ReactNative, and it is a pretty feature rich application, seems like it works for those use it.

They have lots of money but without carrying the cost of maintaining an active hardware product line. Unless you count Oculus for Facebook and a few minor things for Microsoft but those are in the noise.

Reply on news.ycombinator.com