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

React Desktop – React UI Components for OS X El Capitan and Windows 10

github.com

Post reply on HN
Print view View original

31–40 of 74 posts

Re: React Desktop – React UI Components for OS X El Capitan and Windows 10

#31

Post by discreteevent »

Tehnix wrote: post #20
eykanal wrote: post #4

Please forgive the simple question, but... Why does this exist? Is creating desktop programs out of HTML code really a good idea?

Because working with things like GTK and QT is horrible compared to working with HTML/JS/CSS, for anything other than trivial things. That said, it'd be cool to have native code generation from this though.

Have you used Qt and QML? For me it's much more productive and straightforward than html/js/css. Delarative legible ui with built in dataflow/reactive properties. Performs straight out of the box without having figure out how to work with the mechanisms buried in this hugely complex and opaque machine called a browser. In fact its a relief to work with it. Could you say where you think its so 'horrible'.

Re: React Desktop – React UI Components for OS X El Capitan and Windows 10

#32

Post by mikekchar »

trymas wrote: post #22
voltagex_ wrote: post #6

Earlier quoted context omitted.

Because NodeJS is popular and desktop apps were getting small and efficient so we crammed a 30MB Chrome runtime in there.

+1 With all respect to leichzeit0 comment, IMHO, JS is an ugly language, with way too many pitfalls [0]. Even big boys [1] use CoffeScript to transpile into JS. JS for cross platform desktop development may be an easy thing to manage, though it can become unusable and clunky super fast. You can spot JS desktop apps, just by the size of executable, which is at least 5-10 times bigger than you could expect (Spotify - 1…

JS has an ungainly syntax, but then so do many other languages. I have been really surprised at how nice it is to work with a transpiler for JS (I do a lot of CS these days). One of my first jobs was working with CFront, which was a gigantic hassle so I was a bit apprehensive about moving to CS. Nevertheless I think it hits quite a nice sweet spot of giving you nice syntax but not being so different from JS that you forget what you're doing.

As for pitfalls, most languages also have pitfalls. The "this" convention in JS is downright weird, but I've actually used it to my advantage (admittedly only once). The only other thing I can really think of that is actively hostile is automatic coersion of various types.

The core of JS is actually quite small and elegant, though (IMHO). I really like the prototypical inheritance. Once you understand how it works, it is very flexible and easy to work with. It lacks a lot of explicit facilities, but it is usually very easy to implement them if you want.

The main thing JS lacks is decent standard library. The recent Ecma script standards are moving in the right direction, but it is slow progress (understandably).

I've worked professionally with FORTH, C, C++, Perl, C#, Java, Ruby, Go and probably a few more which I'm forgetting. When I'm programming in Coffeescript, I never feel like I'm missing out. When I'm programming in JS, I'm frustrated by all the parens and "function"s that I have to type, but otherwise quite content. I like types, though, so will probably checkout typescript or something similar one day.

Re: React Desktop – React UI Components for OS X El Capitan and Windows 10

#33

Post by SturgeonsLaw »

cristianpascu wrote: post #29
trymas wrote: post #22

Earlier quoted context omitted.

+1 With all respect to leichzeit0 comment, IMHO, JS is an ugly language, with way too many pitfalls [0]. Even big boys [1] use CoffeScript to transpile into JS. JS for cross platform desktop development may be an easy thing to manage, though it can become unusable and clunky super fast. You can spot JS desktop apps, just by the size of executable, which is at least 5-10 times bigger than you could expect (Spotify - 1…

>> "JS is an ugly language" >> "riddled with complex JS" If you pick a technology by the aesthetics of the language, I'm pretty sure you'll make a bad decision no matter what. Not you like in you, but in principle. :) The code is clean if you write it well. Ugly code comes in all parentheses positions.

That's why I do all my coding in brainfuck. People can't tell if it's ugly or not.

Re: React Desktop – React UI Components for OS X El Capitan and Windows 10

#34

Post by voltagex_ »

MichaelGG wrote: post #27
trymas wrote: post #22

Earlier quoted context omitted.

+1 With all respect to leichzeit0 comment, IMHO, JS is an ugly language, with way too many pitfalls [0]. Even big boys [1] use CoffeScript to transpile into JS. JS for cross platform desktop development may be an easy thing to manage, though it can become unusable and clunky super fast. You can spot JS desktop apps, just by the size of executable, which is at least 5-10 times bigger than you could expect (Spotify - 1…

True. Popcorn Time is written with NodeJS. Hence it takes a very long time to install or upgrade (has to handle thousands of files) and has rather high CPU use at runtime.

I wonder if it read from a tar file instead of individual files on slow (NTFS) filesystems it'd be faster.

Re: React Desktop – React UI Components for OS X El Capitan and Windows 10

#35

Post by voltagex_ »

trymas wrote: post #22
voltagex_ wrote: post #6

Earlier quoted context omitted.

Because NodeJS is popular and desktop apps were getting small and efficient so we crammed a 30MB Chrome runtime in there.

+1 With all respect to leichzeit0 comment, IMHO, JS is an ugly language, with way too many pitfalls [0]. Even big boys [1] use CoffeScript to transpile into JS. JS for cross platform desktop development may be an easy thing to manage, though it can become unusable and clunky super fast. You can spot JS desktop apps, just by the size of executable, which is at least 5-10 times bigger than you could expect (Spotify - 1…

What would help is if the Node.js foundation could ship a Node Runtime, similar to the CLR for each platform and then applications could use that. You know, dynamic linking like we've done forever.

Go and Node seem to be heading back to static linking.

Meanwhile Australia is getting left further and further behind. Our internet speed isn't increasing, yet webpages, games, movies and applications are getting bigger and bigger. Help!

Re: React Desktop – React UI Components for OS X El Capitan and Windows 10

#36

Post by blumkvist »

Tehnix wrote: post #20
eykanal wrote: post #4

Please forgive the simple question, but... Why does this exist? Is creating desktop programs out of HTML code really a good idea?

Because working with things like GTK and QT is horrible compared to working with HTML/JS/CSS, for anything other than trivial things. That said, it'd be cool to have native code generation from this though.

Did you mean the other way around?

Re: React Desktop – React UI Components for OS X El Capitan and Windows 10

#37

Post by IshKebab »

marcus_holmes wrote: post #16
evinism wrote: post #12

Earlier quoted context omitted.

This is the question I was going to ask. It seems like porting many of the poor decisions that were made in creating the web to native desktop.

But that's the point of React - providing an abstraction layer over the poor decisions that were made in creating the web. Apart from Javascript, of course. But that particular "bad decision" is getting modified with every version into something more acceptable ("now with classes!"). I guess the endpoint is that React + Javascript (+ Redux) becomes the defacto language for developing UIs in, and what implements that…

> But that particular "bad decision" is getting modified with every version into something more acceptable

True, but it definitely seems like they're only fixing the low-hanging fruit. They're never going to fix the insane type system.

Re: React Desktop – React UI Components for OS X El Capitan and Windows 10

#38

Post by scrollaway »

voltagex_ wrote: post #34
MichaelGG wrote: post #27

Earlier quoted context omitted.

True. Popcorn Time is written with NodeJS. Hence it takes a very long time to install or upgrade (has to handle thousands of files) and has rather high CPU use at runtime.

I wonder if it read from a tar file instead of individual files on slow (NTFS) filesystems it'd be faster.

That's the logic behind most games. They implement a package format (sadly usually their own) for the game files for fast access.

Re: React Desktop – React UI Components for OS X El Capitan and Windows 10

#39

Post by scrollaway »

trymas wrote: post #22
voltagex_ wrote: post #6

Earlier quoted context omitted.

Because NodeJS is popular and desktop apps were getting small and efficient so we crammed a 30MB Chrome runtime in there.

+1 With all respect to leichzeit0 comment, IMHO, JS is an ugly language, with way too many pitfalls [0]. Even big boys [1] use CoffeScript to transpile into JS. JS for cross platform desktop development may be an easy thing to manage, though it can become unusable and clunky super fast. You can spot JS desktop apps, just by the size of executable, which is at least 5-10 times bigger than you could expect (Spotify - 1…

I'm going to elaborate on your comment a bit because this infuriates me and I don't think people truly understand the reasons behind why web-apps-for-desktop generally suck and there's nothing you can do to fix it in yours.

Background: I'm the lead dev/UX on LXQt, a linux desktop environment (http://lxqt.org/).

First one that comes to mind is accessibility and consistency of interactions. Apps that do not respect a host of user settings because the devs don't even know they exist -- but on desktop frameworks, you get these for free. You find this on the web, too. People hijacking scrolling behaviour on websites, without a damn clue that not everybody is on a fucking iphone. You don't respect smoothscroll options, you don't respect autoscroll, you don't respect lines-per-tick, it's infuriating. Zooming? What's that? Let me disable it for whatever hacky performance reason. Who zooms anyway, people who can't see well? FUCK EM!

There's a lot of those examples. Maybe one day I'll write about all of them. They infuriate me as both a user (who is used to some specific behaviour) and a UX guy.

Second reason is the performance. Both in executable size and general runtime performance, as you yourself mentioned. We, as engineers, spent a lot of time and effort working around all the design flaws of js and the web because it was the most pragmatic thing to do. But if you bring these problems with you on the desktop, you are doomed to lowering the quality of the experience we have on our machines. And the user won't understand why their battery now drains at twice the rate - they'll blame it on Lenovo's shitty hardware, so you can get away with it. sighs

And the final one is the direct consequence of lowering the barrier of entry. You often deal with worse quality code. Because of the reasons I cited above, serious devs work with different languages when dealing with the desktop.

There are better ways, that's the worst thing. Qt and QML are extremely productive, work well on mobile and don't have all of these issues. They also work on more platforms than you'd be able to enumerate. Don't get me wrong, I am a proponent of lowering the barrier of entry, and I want to bring the advantages of the web to the desktop. But you can't just move the web there, lest you get its serious flaws and throw away decades of good engineering and UX.

Re: React Desktop – React UI Components for OS X El Capitan and Windows 10

#40

Post by pjc50 »

bengotow wrote: post #14

Man it's great to see effort being put into a platform-sensitive React component set. We've been working on React components for N1, and it'd be cool to swap them out for an open source set one day. The thing is, I'm not sure 100% native appearance is the way to go. I think Spotify nailed a cross-platform desktop experience using a UI that is distinctly non-native. For folks just learning about Electron / web-based d…

Didn't we go round this with Java?

Round 1: AWT. Uses the native widgets. Therefore the layout is slightly different on different platforms.

Round 2: Swing. Cross-platform identical, and therefore looks nothing like native apps. You could 'skin' it, at which point it would look native but behave subtly differently.

Round 3: SWT. Back to native widgets for Eclipse.

Round 4: Everyone throws up their hands in despair and stops writing desktop applications.

Post reply on HN