> React Native for Windows and Mac
> Mac: Coming Soon
You know what, I think I'll wait for Flutter Desktop, or see who wins true cross-desktop compatibilty since Flutter already has Mac support but no Windows.
React Native for Windows and Mac
441–450 of 505 posts
Re: React Native for Windows and Mac
#442Earlier quoted context omitted.
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)…
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.
Re: React Native for Windows and Mac
#443Earlier quoted context omitted.
The purpose of that kind of package is to provide a standalone implementation of a function. To criticize this organization, you would need to understand why people find that to be valuable and show a better approach. You’re attributing it to “culture” but there may be deeper, less arbitrary reasons. Look up “ponyfill” if you are interested in learning about it.
Wouldn’t the alternative simply be bigger libraries grouped around common functionality or extension points? Like jQuery or similar (only an example, not sure what is hip today). I’d rather trust a fairly big library with an organized open source group behind it than thousands of small libraries by unknown developers.
The NaN library is literally just testing if the value is a number with typeof v === 'number' then tests if v !== v. This is not something you need a library for at all, big or small.
Re: React Native for Windows and Mac
#444Earlier quoted context omitted.
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.
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.
Re: React Native for Windows and Mac
#445Earlier quoted context omitted.
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)…
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.
Re: React Native for Windows and Mac
#446Earlier quoted context omitted.
Wouldn’t the alternative simply be bigger libraries grouped around common functionality or extension points? Like jQuery or similar (only an example, not sure what is hip today). I’d rather trust a fairly big library with an organized open source group behind it than thousands of small libraries by unknown developers.
The NaN library is literally just testing if the value is a number with typeof v === 'number' then tests if v !== v. This is not something you need a library for at all, big or small.
Yeah, this is my philosophy when developing Erlang software as well (also seems to be shared by most of that community). A few dependencies less are always worth a few functions more.
Re: React Native for Windows and Mac
#447Earlier quoted context omitted.
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 o…
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.
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.
Re: React Native for Windows and Mac
#448Earlier quoted context omitted.
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…
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 shoeh…
As hated as flash was, there was a whole creative ecosystem of really unique games / art pieces that died off with it. A shame.
Re: React Native for Windows and Mac
#449Earlier quoted context omitted.
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…
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.
Re: React Native for Windows and Mac
#450Earlier quoted context omitted.
> 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 v…
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…
> 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.