Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React Native for Windows and Mac

microsoft.github.io

Post reply on HN
Print view View original

251–260 of 505 posts

Re: React Native for Windows and Mac

#251

Post by c-smile »

Sophistifunk wrote: post #240
c-smile wrote: post #227

Earlier quoted context omitted.

> the DOM is just fundamentally unsuited for app UI rendering... Consider the following: Native UI: is a tree of widgets. Each widget has sematic properties / attributes. Each widget may have style properties (colors ,fonts, etc.). Each widget has exactly on parent and may have multiple children. There is an API for all of these. HTML/DOM UI: Same as above, just replace "widget" by "element". Could you explain then w…

The most glaring is the ability to measure things (including text) in order to lay them out, rather than adding stuff to the tree and waiting a while for somebody else to lay them out in order to measure them. Followed closely by absolutely everything about the way overflow "works". After that I'd add the absolutely batshit insane hoops through which one still must jump to build any sort of text editing component wit…

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

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

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

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

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

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

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

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

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

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

Re: React Native for Windows and Mac

#252

Post by fermienrico »

andai wrote: post #156
fermienrico wrote: post #140

Earlier quoted context omitted.

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

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

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

Re: React Native for Windows and Mac

#253

Post by diss »

scarface74 wrote: post #247
diss wrote: post #237

Earlier quoted context omitted.

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.

Re: React Native for Windows and Mac

#254

Post by eyelidlessness »

Spivak wrote: post #199
eyelidlessness wrote: post #183

Earlier quoted context omitted.

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

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

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

Re: React Native for Windows and Mac

#255

Post by svieira »

wyc wrote: post #17

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…

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

Re: React Native for Windows and Mac

#256

Post by friedman23 »

scarface74 wrote: post #142
wyc wrote: post #17

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…

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.

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

Re: React Native for Windows and Mac

#257

Post by friedman23 »

scarface74 wrote: post #201
diss wrote: post #195

Earlier quoted context omitted.

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?

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

Re: React Native for Windows and Mac

#258

Post by mythz »

wyc wrote: post #17

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…

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

Re: React Native for Windows and Mac

#259

Post by toastercat »

antigirl wrote: post #224
comex wrote: post #58

Earlier quoted context omitted.

> I know the chromium engine is a resource hog, but the scalability/mix between platforms makes it worth it. Worth it for some. Personally, I refuse to use any Electron apps because they have a highly non-native-feeling UX and because they're resource hogs. This announcement excites me, because React Native is likely to be an improvement on both counts. The UX still won't be quite as native-feeling as a single-platfo…

VScode looks and feels native and not memory intensive

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

Re: React Native for Windows and Mac

#260

Post by dwaltrip »

mythz wrote: post #258
wyc wrote: post #17

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…

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

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.

Post reply on HN