221–230 of 505 posts
I'd love to abandon my C/C++ UI frameworks for React, but I need - consistent rendering/support across multiple platforms and versions - multiple windows - rendering to a window that isn't owned by the UI being rendered or created by the framework Can I do that all in React native? Edit: don't need to bring up electron.
Wasm
Earlier quoted context omitted.
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.
Wouldn't Flutter be the killer app to Dart as Rails was to Ruby by your analogy?
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?
Not sure what the advantage here is over Electron. I know the chromium engine is a resource hog, but the scalability/mix between platforms makes it worth it. Curious to know what your thoughts are folks!
> 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…
Earlier quoted context omitted.
"Useful" as long as you don't care about battery life, memory usage, taking advantage of features of the host platform, or the native UI. As an end user why do I care about "openness"? If I pay a premium for my platform, why would I want second rate cross platform software?
As an end user you might not get that software at all if no one is motivated to build it.
Earlier quoted context omitted.
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?
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".
Earlier quoted context omitted.
Sciter then ( https://sciter.com ): - multiple platforms... Yes: Windows (x32,x64, ARM64), from XP to 10, MacOS, Linux/GTK, IoT and mobiles. - multiple windows - Yes. Multiple desktop windows and you can even render separate DOM elements in popup windows. - rendering to a window that isn't owned by the UI being rendered Yes, you can render it on top DirectX, OpenGL, Vulkan (coming) or in child window/nsview/gtkwidget…
HTML is half of the problem, the DOM is just fundamentally unsuited for app UI rendering, and CSS is a nightmare when applied to UI controls rather than text documents. What we need is a cross platform well-thought-out scene graph like Flash had or Flutter (kinda) has.
Consider the following:
Native UI: is a tree of widgets. Each widget has sematic properties / attributes. Each widget may have style properties (colors ,fonts, etc.). Each widget has exactly on parent and may have multiple children. There is an API for all of these.
HTML/DOM UI: Same as above, just replace "widget" by "element".
Could you explain then why one of these is "fundamentally unsuited" and other is a perfect match?
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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…
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.
Earlier quoted context omitted.
React, almost 10 years? It was only open sourced 7 years ago and definitely took time to fully catch on..
I'm truly amazed to still encounter "omg React is so new and unproven how can we possibly keep up with stuff like this?" posts. Next up: is no-sql just another fad or will it catch on?