7 ms·
Cross-Platform UI in GitHub Desktop
- Cshelton 11y agoIt'd be interesting to see something like Servo (browser rendering engine by Mozilla, written in Rust lang) possibly work with web views in a "native" app. This would enable rendering the view multi-threaded, like native rendering engines.
- htor 11y agoAgreed. Servo (or any other multi-threaded engine) will definitely be a game changer. I'm curious - when is Servo going to be smacked inside Firefox? We need that lovely thing right now.
- mwcampbell 11y agoI'd like to know more about why the .NET WebBrowser control was deemed unworkable. Is the problem with the actual WebBrowser control provided by the IE engine, or just the .NET interface to it (presumably the one provided by WPF)?
- myoon 11y agoThe WPF browser control is pretty weak. You don't have great control over which rendering engine it will use (default is to go to IE 7 mode!) except via writing a registry key to switch it. It provides almost no bridge between the JS and native code as well. I haven't used CefSharp, but I have used Awesomium, which provided pretty good JS-C# bindings, so I assume CefSharp has at least working JS-C# bindings.
- m_fayer 11y agoI've also had a great experience with awesomium which imo has a more powerful api than cefsharp, I'm curious why they chose it over awesomium.
- julionc 11y agoI guess the reason is that they (Awesomium) don't provide an Open Source license like MIT or GPL. Instead Github Team choose CefSharp.
- softawre 11y agoMy key problem, working with it, is you're stuck with whatever IE the user has installed on their machine. With CEF (which I've used, as have many other big companies - search your Windows PC for the dlls if you don't believe me), you're guaranteed every user has the same version of Chromium.
- szx 11y agoSince the app already bundles web views and resources, I'm curious to hear if they considered making it an Electron app, and if they did - why they decided to go with multiple native apps instead. (I realize at least the OSX version probably predates Electron, still might have paid off to completely rewrite.)
- mdiep 11y agoThat is something that we've considered. Both Mac and Windows clients predate Electron (but maybe not the initial versions of Atom). Rewriting from scratch in an unfamiliar environment would have taken a lot more work. There are tradeoffs to both approaches, but using the existing native apps let us ship a less buggy release more quickly.
- ghuntley 11y agohttp://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html
- signal11 11y agoWhat are the power consumption implications of embedding a web component like this? Will this be harder on the battery than using native drawing APIs?
- kuschku 11y agoYes. You have to start a webbrowser control, which reads the JS code and compiles it every time it runs, additionally the added sandboxing and abstractions (that are unnecessary in this case) also add to power usage and lower performance. A better solution would have been something like OpenGL.
- mwg66 11y ago"better"
- wereHamster 11y agocoffeescript? I thought by now they'd switch to a more advanced language (say, TypeScript or ES6+flow).
- twerkmonsta 11y agoI was wondering why the performance was so awful, and reminds me of Atom in it's slow startup... This answers it all.
- andresmanz 11y agoYes, that's not unusual these days. I wonder if they even care when the user experience gets destroyed just for a bit less development time.
- xorcist 11y agoDoes it web tech really have lesser development time? My experience is definitely the other way around, and I probably have put more hours in on the web side. Web is unbeatable for things like responsive UIs, but when you want pixel based it's hard to beat the development speed of Visual Whatever or Qt Designer.
- king_magic 11y agoSame in my experience. Often times (and yes, this is anecdotal), using a web framework for desktop - or mobile apps - greatly extends development time, when you take all of the littles thing that it takes to build a production-ready system into account.
- andresmanz 11y agoWell, at least that's what I read all the time. I couldn't confirm it, too, but I always thought that's just because I'm perfectly fine with Qt. QML is also pretty good for responsive UI. Maybe these companies prefer the web stuff because most developers know it anyway.
- rhodysurf 11y agoI think its because so many devs are trying to move away from C++. Qt really is great and its sad to me because its a much better solution than these crappy browser apps.
- rogerbinns 11y agoHopefully this means they will end up releasing the gui app for Linux too. While the command line isn't a problem for experienced developers used on a daily basis, it is a problem for those contributing who aren't the core developers.
- deleted 11y ago[deleted]
- sz4kerto 11y agoI find it horrifying that on a Haswell i7 a chat app or a text editor STUTTERS. It's really ridiculous and sad at the same time.
- deleted 11y ago[deleted]
- zanny 11y agoFor every clock your CPU gets, a developer will find a way to waste it. Why is there so much interest in HTML + Javascript based normal applications? They are slow, the langauges are awful, but besides Qt they are the ultimate portability. So sacrifice all those hz gains and power efficiency to make the developer workload minimal.
- andreasklinger 11y agoI assume because developers approach it with a different mindset: Theoretically all of this problems can and will be solved. The advantage would persist. But agree. Reality looks often different
- pjmlp 11y agoBesides Qt, JavaFX, wxWidgets, Xwt, even Gtk offer a better native experience than a browser widget.
- Shorel 11y agoScript kiddies are cheaper than C++ developers.
- swah 11y agoHear, hear. http://handmadehero.org http://handmadehero.org is almost therapy for me in that regard: Casey looks at assembly output from the compiler all the time.
- svdree 11y agoYeah, it's amazing. We've had decades of improvements in hardware performance, only to end up with software that's slower than anything that came before it. Yet apart from a small minority, nobody seems to bat an eye.
- thecrumb 11y agoCross platform would work on Linux.
- fsloth 11y agoDid I understand correctly? So they include the whole browser tech stack for a simple graph? Am I the only one who finds it strange - rendering text and polygons is not exactly rocket science.
- blub 11y agoIf done in HTML, it is rocket science. When I started reading and they mentioned that only a graph is cross-platform, I was thinking - "oh, they probably used OpenGL". Little did I know...
- pjmlp 11y agoIt is called canvas and 2D drawing hardly rocket science.
- currysausage 11y ago> So they include the whole browser tech stack for a simple graph? And they have the balls to post it on a blog with "Engineering" in its title. Then again, this appears to be the new standard of doing things. We consider the browser to be today's operating system, and modern apps (Spotify, Visual Studio Code, Atom, etc.) bring their own operating system. Fire up your editor and jot down a quick note? Yeah, why not make coffee while it's loading. Back to the future, I guess.
- deleted 11y ago[deleted]
- lpsz 11y agoI have to say, I miss the age of native apps. I understand that it's awesome cakes for Spotify, GitHub, etc. engineers to share JavaScript bits between devices. But it sucks for me as the user! The Spotify app (on my Mac) has become a resource hog over the years. Same with Slack's Mac app. As beautiful as it is, there's just something that doesn't feel 100% responsive/right with a web-based app. "With separate code bases for OS X & Windows converging on a single design, we knew that sharing code would be essential going forward. Sophisticated as the graph is, implementing it twice would have been a significant burden." How is it ever reasonable to prioritize coding convenience over the end users' experience? This team set out to solve a cool engineering problem (code reuse) and forgot altogether that people are actually going to be using this stuff.
- gcr 11y agoThing is, by using a cross-platform drawing library like Cairo or OpenGL, a lot of this code could have been reused anyway. It wouldn't have been as nice or expressive as Javascript though. But it also wouldn't have required hacks like stitching together a giant string to be `eval`', for example. So there's a tradeoff.
- lpsz 11y agoYep. They could also use some shared C/C++ bits to generate various drawing metadata ("the model") and delegate the rendering/input handling to whatever platform-specific APIs. It may be more work, but if you're not going to build an actual native app, why bother? These apps are built as a sales point ("look, we have a Mac app!"), without the customer in mind.
- merogin 11y agoI haven't used the application (can't on Linux), but if the graph doesn't require user interactivity, using Cairo or some other software renderer (e.g. http://www.antigrain.com/ http://www.antigrain.com/) to just render the graph into a bitmap, would do the job faster and with less resource usage. Adding user interactivity on top of that shouldn't be a lot of work either.
- 11y ago
- cheez 11y agoYet another way to avoid using C++