Hacker News new | past | comments | ask | show | jobs | submit login
React Native for Windows and Mac (microsoft.github.io)
714 points by ed 12 days ago | hide | past | web | favorite | 477 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?

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?


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.

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!



Definitely not.

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/


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.

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


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.

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

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 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


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 capabilities based OS library reminds me of genode some.

This is a really cool idea.

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.


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/


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.


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.


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


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 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 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".


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.


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.

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.


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

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.


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.

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.

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.

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.

It works fine for hundreds of millions of other users

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


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.


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

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.

> 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.

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.


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.


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

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.

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.

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.

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 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.

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.

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.

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

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

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?

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

The update wasn't terrible.


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?

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.

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?

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

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.


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.

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.

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

> 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.


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.)

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

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.

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).


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.

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.

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.


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.


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.

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.


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


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?

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.

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


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.


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

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

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


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

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

It's turtles all the way down.

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.


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?

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.

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.

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)


> 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.


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 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.

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 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.


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.


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.


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.


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.


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.


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

Except hot reload


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.

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.


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.


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.


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

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

Goodbye accessibility.

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


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 got a big grey screen on the first three I clicked. Not sure if this is ready for prime time...

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.

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.

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

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!”

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 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.


Is it WebGL?

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.

> 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.


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.

> 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.


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

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?

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.


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.

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.

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

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.

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?


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

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


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.


Dated, but Google Gears?

AngularJS

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.


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.

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.

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

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.

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.

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

Search: