Live data from Hacker News

Electron is flash for the desktop (2016)

josephg.com

411–420 of 1001 posts

Re: Electron is flash for the desktop (2016)

#411

Earlier quoted context omitted.

That's nonsense . Desktop apps have been frequently released since forever. The underlying issue here is that Electron reduces the barrier to entry for cross-platform development . That is, it's cheaper to build a single cross-platform application in Electron than it is to build two or three native applications, and you can re-use your existing web experience. I can completely understand why companies might choose th…

OneNote is a great example. It has fairly well-regarded native apps for each platform it supports, _and_ a decent web (HTML5) interface. I think the issue is time and resources. Small teams, like Slack, would like to create a slick experience but they don't have the time. Companies like Facebook went the other route -- HTML5 on mobile, got their fingers burnt, and went all-in on native. StackOverflow's iOS app appear…

Facebook's HTML5 app was 5 years ago, this example comes every time but it's outdated. technologies like Electron or React Native didn't even exist at the time.

5 years is huge when it comes to web technologies.

Re: Electron is flash for the desktop (2016)

#412

Earlier quoted context omitted.

Put simply: time to market. Experienced front-end devs with a designer on hand could put together the UI inside of a day, with a workable user experience. Hell, if you're not afraid of bloating in the codebase, you could use a large number of libraries to put together a basic, working version inside of a day or two. Stretch that to a couple of weeks (at most) and you have a prototype you can release. The proof is in…

> Experienced front-end devs That's the problem right there(?). People bringing a DOM to the desktop because the developers were fluent in JS. > time to market If there were no drawbacks in terms of complexity/performance/size etc then I'd agree, but now when you have a perf issue that is too large it might be a huge issue to fix. You also only get one chance for a first impression - and poor performance is a huge tu…

Agree, I think this is a combination of lack of imagination by developers who only know JS, and management who has bought the myth that cross platform development is 3x faster than making native apps.

I saw this happen at work. My team were all experts on native mobile development. We could crank out stuff fast, because we knew our tools well. But then some management dude got the idea that we would do it 2-3x faster if we went with JavaScript.

Turns out it was more like 2-3 slower than making all the native versions, because we did not have strong experience with these tools and APIs were more limited, poorely documented, buggy, and the tools were subpar.

Re: Electron is flash for the desktop (2016)

#413

Earlier quoted context omitted.

> You know what the alternative to all of these Electron apps coming out is? A single page web app? That's all most of these are. Particularly the Slack/Hipchat/Discords of the world. > People are excited about the Desktop again If by desktop, you mean "need to be connected to mains power to run for more than 10 minutes", yeah, people are excited for desktops again. Electron only really makes Javascript developers ha…

>> As a consumer, I fail to see the value in having to download large single page webapps that are equivalent (or worse) than their online counterparts. I use the Slack app for Windows, and the value for me is that it gets its own easily identifiable presence in my Windows task bar. I have a (self-inflicted) problem with tab proliferation, and because I rely heavily on Slack, it's just way more convenient to use the…

> It doesn't bother me at all that the Slack app is an over glorified web browser running the Slack web client.

It kinda should, though, because if the browser component isn't up to date on the regular then it's possible you're looking at (what should be) a simple chat app with a potential RCE.

Re: Electron is flash for the desktop (2016)

#414

Earlier quoted context omitted.

> Nobody cared about writing Desktop apps before Electron came along, there's basically zero money in it, and it's massively expensive, both in terms of actual dev time per feature (easily 10x the cost), and also in finding specialist developers who know these dated technologies. Clearly Java never existed. I've been experimenting with Swing lately because Java has a library I'm interested in using. It's a breath of…

Layout management: I do wonder sometimes how much awareness the HTML/CSS/JS community has about how layout management is handled in things like Java's Swing or Apple's Auto Layout - or do people think that "desktop style" UI layout management is the "old way of doing things", and obviously HTML/CSS/JS is much more modern and therefore must be better? I don't think it is better, to be honest, and so I also wonder why…

Can't help thinking that Visual Basic had a better layout manager than CSS. I hate fixing CSS issues with a passion. I watch a designer whip up something in Illustrator and can't help thinking that CSS & HTML are a primitive way to do layouts.

Smalltalk had a GUI based approach to design in the 70s on a 2 mb disk, and most web layout is generating html & css, then tweaking that stuff. It doesn't feel like web layout is a progression.

Re: Electron is flash for the desktop (2016)

#415

Earlier quoted context omitted.

I can't help but think there's a different flavor to this than with higher-level languages. This is adding a platform on top of another platform. The same objections existed years ago with Java when Swing was released. Java is a cross-platform high-level language but Swing is basically an entirely new platform. It's this platform on top of a platform that is objectionable from a performance, memory, storage, and inte…

We see the same thing with containers. Docker, flatpak, snap... It's just the right time for it. Languages have evolve to change the way we handle constraints like memory, speed, readability, expressivity etc. We are arriving at the pick of what languages can bring on the table. Sure we can improve things here and there, but the huge challenges now are integration, packaging, distribution, updates, communications, mu…

I agree. Containers should be unnecessary -- all that they could provide could be done at the process level with an operating system designed to isolate computing resources appropriately. But operating systems were not historically designed for that so another (somewhat ridiculous) layer is added on top.

Re: Electron is flash for the desktop (2016)

#416
post #80
post #20

Earlier quoted context omitted.

I want to say that VS Code had the same issue because of the blinking cursor, which was controlled by a CSS property to toggle.

I'm consistently blown away that stuff like this gets past testing. Personally I think every software engineer should have a CPU meter of some for running on their machine while developing. Its an essential element of seeing what you're doing. How can you write decent software without having even that much visibility over what your computer is up to while your code runs? These huge CPU sinks making it through to rele…

I think this thinking is exactly how it gets past testing. You could force every engineer to have a CPU meter, but that alone won't help; they'll ignore it, assume it was a coworker's change that made the usage higher, or just assume their CPU is high because of their 30 Chrome tabs currently open while developing.

A better solution would be to have CI monitor CPU usage so that increases/decreases could be monitored and reported over time/per commit.

Re: Electron is flash for the desktop (2016)

#417

Here's the thing. You know what the alternative to all of these Electron apps coming out is? If your answer is "A native Cocoa/WPF app", you are on another planet, the answer is, "It wouldn't exist at all". Nobody in the last 5-10 years cared about writing Desktop apps before Electron came along, there's basically zero money in it, and it's massively expensive, both in terms of actual dev time per feature (easily 10x…

>Here's the thing. You know what the alternative to all of these Electron apps coming out is? If your answer is "A native Cocoa/WPF app", you are on another planet, the answer is, "It wouldn't exist at all".

A higher barrier to entry has that effect. Low quality crap doesn't get in as easily.

>Nobody in the last 5-10 years cared about writing Desktop apps before Electron came along, there's basically zero money in it, and it's massively expensive, both in terms of actual dev time per feature (easily 10x the cost), and also in finding specialist developers who know these dated technologies.

I find this argument absurd. Desktop (and mobile native) apps are multi-tens of billion business. Ask Microsoft, Apple, Adobe, and thousands upon thousands of smaller businesses (down to SMEs like Panic and one-man-shops like Sublime Text).

If anything it's those web-based unicorns that are either merely burning VC money, or selling the user to advertisers -- in both cases, there are not much money in selling them directly.

And there's nothing about web development that couldn't be achieved just as easily if instead of all those money on browser engines and teams to create things like Dart, there was some effort towards a nice, cross platform, mobile and desktop UI library.

It could even have JS bindings for all web devs to use -- just without the web stack crap. React Native is something akin to that, but imagine if it had been going for years, and had more industry support, instead of the nth attempt to put lipstick on the web stack.

Re: Electron is flash for the desktop (2016)

#418

Earlier quoted context omitted.

That's nonsense . Desktop apps have been frequently released since forever. The underlying issue here is that Electron reduces the barrier to entry for cross-platform development . That is, it's cheaper to build a single cross-platform application in Electron than it is to build two or three native applications, and you can re-use your existing web experience. I can completely understand why companies might choose th…

> Electron applications are shite in comparison with proper native applications. They fail to integrate with the host platform, they are slow, they hog memory and drink power. Are they though? The two applications that use the most energy on my Mac - by far - are Steam and Skype. Steam still has trouble with HiDPI and freezes when performing various UI interactions. The number of problems with Skype are uncountable.…

VS Code has way fewer features than Visual Studio, especially for C#/.NET development. VS Code is a minimalistic IDE, very useful, especially for javascript development where tooling is quite minimal anyways. But let's not think that VS Code outclasses visual studio.

Re: Electron is flash for the desktop (2016)

#419

I've slowly started to remove Electron apps from my workflow. I used to use Atom, but I've switched to an paid for Sublime. The last two apps I have which use electron are Hyper and Slack. Hyper could go, but I really like the interface and Slack probably isn't going anywhere. Real-time update: I just checked Activity Monitor and Hyper is leading average energy impact followed by Xcode. Looks like I might be switchin…

What is the draw of Hyper over iTerm2?

It runs Javascript! You can tune and theme it with CSS and JS!

That's actually the biggest selling point. I couldn't imagine using Hyper: I open terminals very often and waiting for Chrome to load when I need to just run a command would be very exhausting.

Re: Electron is flash for the desktop (2016)

#420

Earlier quoted context omitted.

> Nobody cared about writing Desktop apps before Electron came along, there's basically zero money in it, and it's massively expensive, both in terms of actual dev time per feature (easily 10x the cost), and also in finding specialist developers who know these dated technologies. Clearly Java never existed. I've been experimenting with Swing lately because Java has a library I'm interested in using. It's a breath of…

Java isn't new and shiny anymore. Having been around for the great Java hype of the 90s, it's crazy that Javascript has now replaced it. Nobody would have predicted that back then.

Javascript, Java, it's all the same after all ducks
Post reply on HN