It'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.
I'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)?
The 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.
My 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.
Since 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.)
That 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.
Yes. 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.
Does 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.
Same 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.
Well, 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.
I 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.
From VS2013 Menu Select "Tools", then Select "External Tools". Enter as below:
Title: "VS2013 Native Tools-Command Prompt" would be good
Command: C:\Windows\System32\cmd.exe
Arguments: /k "C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\VsDevCmd.bat"
Initial Directory: Select as suits your needs.
Hopefully 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.
For 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.
Yeah, 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.
Or rather, the new phone would burn jet fuel even more.. That's the main problem, we shouldn't be coding for saturation of resources. It's ridiculous how wasteful apps are these days.
Yes, that is the exact issue. Upgrading just costs money and does not really improve anything.
I see it myself, upgraded from Huawei Ideos X3 (2.3.7) to Motorola Moto G (5.0), and it’s just as slow as the old phone was. Despite being twice as expensive.
Did 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.
If 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...
> 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.
I 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.
Thing 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.
Yep. 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.
I 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/) 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.
What we've done with GitHub Desktop is very different than the write-an-entire-app-in-JS approach that a lot of apps have taken. There's a small piece of custom UI that's built with HTML, JS, and CSS; but even it is controlled by native code. GitHub Desktop is still mostly native code on both platforms.
58 comments
[ 2.9 ms ] story [ 121 ms ] threadI'm curious - when is Servo going to be smacked inside Firefox? We need that lovely thing right now.
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.
(I realize at least the OSX version probably predates Electron, still might have paid off to completely rewrite.)
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.
A better solution would have been something like OpenGL.
This answers it all.
Maybe these companies prefer the web stuff because most developers know it anyway.
Also, any similarities to Atom are superficial at best on OS X. We use WebKit (where Electron/Atom use Chromium) and most of the app is native code.
I'm less knowledgable about the Windows side, so I can't comment on it.
That was already the only thing I used GitHub for Windows for, and that's only because Visual Studio doesn't speak SSH.
External tools is how you access things like SSH or the developer console in visual studio.
http://stackoverflow.com/questions/21476588/where-is-develop...
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.
Theoretically all of this problems can and will be solved. The advantage would persist.
But agree. Reality looks often different
Even my mum complains every day about it. "Can’t be that a 4 year old smartphone can’t run a chat app like whatsapp fluently"
But she refuses to buy a new phone, because that would just fuel this even more.
I see it myself, upgraded from Huawei Ideos X3 (2.3.7) to Motorola Moto G (5.0), and it’s just as slow as the old phone was. Despite being twice as expensive.
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.
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.
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.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.
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.
What alternative real native GUI clients are there for Git on Windows?
I rather use tools that embrace the native platforms.