Hacker News Reader

Comment by bitwize | Hacker News Reader

An internet points out that Hackernews' favorite text editor takes up more CPU than the average Hackernews would have had at their disposal 20 years ago just to make the cursor blink on and off. Hackernews circles the wagons to justify the stupid engineering design decisions behind said editor based solely on the fact that embedding a complete Web browser just to draw buttons and text fields "won" over any sensible GUI implementation, and they can't live without the crutches VSCode provides when shitting out Go microservices.

Many of these same people will argue vehemently that X11, the shitty GUI layer for Linux that ran perfectly fine 20 years ago, is "slow" and "bloated" and needs to be replaced with Wayland, a new, completely different, shitty GUI layer.

View on HN

You're wrong and don't know what you're talking about.

I dislike the implementation of Atom and have been highly critical of it on HN, even crashing a release thread once by pointing out how harebrained it is to implement complex text layout on top of browser APIs when the browser has access to a much richer text shaper itself - we'd know because we wrote it for Qt originally.

Because I've also worked on KDE for 12 years, wrote a big chunk of Plasma 5 and am one of the people porting it to Wayland. We want Wayland for many of the same reasons that make Atom bad, such as state synchronization problems and overhead with X11 (along with its very dire security story).

The intersection you suggest isn't real or doesn't matter. No one working on Wayland uses Atom.

I don't think one should take obvious satire to seriously. There's not enough time in the day to point out details in posts that are written just for laughs.

However, just to be pedantic ( ;-) ), I'll have to point out that "a big part of the people defending VSCode in this post agree that X11 is slow" does not imply "a big part of the people agreeing that X11 is slow defend VSCode in this post". The two aren't commutative, since one set of people is quite likely much larger than the other.

Edit:

Oh, and since you mentioned working on Plasma for over a decade: Thank you for making awesome FOSS! :)

:) Fair enough. I am a bit less cranky after my morning coffee now ;). Thanks for the warm words!

I'd say you absolutely have to point out factual flaws in comedy. Comedy is truth, that's why you probably believe that David Cameron put his penis in a pig's mouth and Donald Trump was peed on by Russian prostitutes. There's no evidence, but it's funny so you believe it anyway.

Best bit is that X11 runs really well these days -- responsive, fast, reliable. Emacs runs great, gitk, xterm, xosview, mplayer window manager, even Firefox is alright. Renoise, Maya, Blender too. Not to mention network transparency when I need it. It's a great environment to get my work done, and 3x hi res displays is the stuff I dreamt of 15 years ago.

So it's a good job we're about to throw it all out and start again, eh folks?

If by "responsive, fast, reliable" you mean awful screen tearing when you mix X11, OpenGL, and/or video playback. Fixing it on any given machine is often possible through some voodoo and a hand-rolled combination of driver and software settings, but that voodoo works only for one specific combination of hardware and driver version, and every update means more rounds of trial and error...

This is not because of X11 the protocol though, just implementation bugs. Thus not a good reason to start from scratch.

How would you suggest we fix the core pointer protocol? (It's not an extension)

> X11 runs really well these days -- responsive, fast, reliable

Well, you haven't seen Windows then - the graphics stack is phenomenal and a marvel of engineering. nVidia drivers crash? I only get a second of black screen and then resume my work. Yep, that's right - no other GUI program crashed, I didn't had to do anything, literally just 1 second of black screen.

Oh and you can have one window on two monitors and both parts of window will have full vsync - insane, huh? :)

It's scary how good Windows is.

Yes, and it only took 30 years, too!

I don't much about graphic stacks, but in my experience the best, as least from the perspective of someone using multiple HiDPI displays macOS is far and away the best. Many windows applications don't scale properly or if they do they require special settings to do so. If you have monitors with different levels of scaling your going to have a terrible time on windows.

On the other hand, connecting a 4k display in windows will default to configure it at 200% scaling, in mac it defaults to render everything tiny as ants.

I think it's only 150%, currently running windows on a 28" 4k monitor makes me think 200% would be too much?

Oh I should also add that I haven't ever had any of the DPI issues the parent's parent is referencing. The only problem with multiple display DPI in Windows 10 is the shockingly bad fuzz you get on your secondary display from the thing being rendered either smaller or larger than normal (depending on whether the 4k is your primary or secondary) and then scaled up or down to fit the monitor.

It may somehow be detecting the size of the display. My 13" laptop likes 250% scaling, while my 27" monitor likes 150%.

That would make sense, your DPI scaling is all to do with readability after all :)

>... in mac it defaults to render everything tiny as ants.

I'm a fan of no DPI scaling (100%) at 4K, at least on my 27" monitor. It takes 2-3 months of getting used to, but once your brain and eyes adapt, significantly lower dot pitches become completely unusable. The only thing I change is bumping up my terminal or editor's default font size a tad.

That said, I'm not sure how people with 24" 4K monitors do it without DPI scaling. I'd probably even prefer 30" myself.

I once used 15" MBPr without DPI scaling (2880x1440 native res) for a while. Then I became too worried about my eyes.

>...significantly lower dot pitches become completely unusable.

Correction/clarification: significantly higher* dot pitches, as in lower pixel density. "Completely unusable" was meant in the sense of how it'd feel to return to 800x600 after being accustomed to 1080p. 4K is four times 1080p, so it's roughly comparable.

It wasn't my intention to offend anyone with poor eyesight, or suggest that people ruin theirs. Just that it's possible to get used to really low (dense) dot pitches, and once you do it's simultaneously really enjoyable and weird at the same time.

Windows 10 refuses to work properly with my 4K Dell monitor.

After it goes to sleep, then I wake it up all open Windows have been resized into a tiny part of the screen and scaling goes weird.

https://duckduckgo.com/?q=windows+4k+monitor+resize+after+sl...

Terrible.

Having said that on macOS my external 5K LG monitor is causing complete system crashes now and again :(

I have a 43" 4k screen. It's near impossible to make Windows NOT use scaling, even if you disable it everywhere, the next Windows updates usually reset your carefully created registry hacks.

I wish Windows based scaling on DPI instead of resolution, the system seems to be aware of both. On a more general level, I wish there was any hope of passing feedback to Microsoft/Apple/etc.

I think that's a case of necessity being the mother of invention. IME the windows 10 drivers crash much more frequently than the linux or windows 7 ones ever did.

I don't think it's fair to blame the OS for driver crashes. Those are a result of third parties and can happen on any platform.

That varies on the OS/driver/hardware, but IMO, the new AMD graphics drivers being in the kernel tree are the way to go, or something similar like a partnership between MS/AMD/Nvidia.

As a consumer it's incredibly frustrating to have a buggy driver and not know who is responsible. Is it MS? Windows comes with a lot of drivers so blaming MS seems fair. Is it the hardware manufacturer? Sometimes you can get the latest drivers but the OEM hardware isn't quite standard so you're screwed. Is the OEM to blame? Usually, because they have their own driver update system, but then the question is why can't they use the native windows update system?

The current situation on windows seems to be that no one is responsible.

You're making this harder than it needs to be. All Windows drivers are signed. Blame the party that signed the buggy driver.

The point is, users will blame windows because they don't know what a graphics driver is or that they have one, so MS took steps to avoid people thinking windows is buggy. MS has a long history of this, going as far as reproducing bugs.

You sign an executable to attest that it is authentic, not that it is bug-free.

Many vendors do use the Windows Update system. Looking at my old Windows 10 box, in the last three months it's received display driver updates from Intel and nVidia (it's an Optimus system so yay, twice the driver update joy). It's also got a mouse driver update from something called ELAN.

Also, Windows has this thing called minidrivers where Microsoft essentially writes a chunk of your driver for you (the generic chunk), and you only have to write the bits specific to your device. The idea is that Microsoft could QA their drivers better than J. Random OEM ever could, and so this'd reduce cost for OEMs and also make the Windows platform more stable.

https://msdn.microsoft.com/en-us/windows/hardware/drivers/ge...

> then the question is why can't they use the native windows update system?

Cynical answer, and I will grant that gpu vendors are less bad than e.g. printer or smartphone drivers, but it just distributes drivers and so doesn't provide all the opportunities to upsell/advertise to/lock in the users that their bundled crap they can pair with the driver with their own installer allows

FWIW my graphics drivers crashes on Ubuntu always recover. Even a complete GPU hang. It sees the driver is hung and restarts it causing a few seconds of minor glitching.

Configuring X is not for the faint of heart, but in Unity it is basically magical and deals with HiDPI displays, etc. just fine. Feature for feature it is very similar to Win or Mac on the display and GPU driver front. The total package still feels rougher around the edges, but it is still good.

My only issue with configuring X is that 'load "glx"' will not fetch the correct libglx.so with nvidia drivers loaded unless you tell it to go looking in /usr/lib/nvidia-[VERSION]/ :| took me a very very long time to get GLX working on my setup.

As someone who remembers NT4 video driver crashes bringing down the whole system, when I saw Windows 10 recover from a video driver (yes, nVidia) crash I was massively impressed.

There's always room to improve but I'm really happy with the stability improvements they've put in.

Yes, but only if you have the Aero compositor turned on... which adds at least one frame of latency to everything. Without Aero, Chrome can't play video without tearing like crazy. Oh, and that white pixel in the top left corner of the screen if you've got Aero turned on but turned off the annoying as crap transparent windows. Yeah, scary good...

Windows' stack is still a ways from being reliable in a lot of somewhat important cases like (real) fullscreen, but it's certainly miles beyond X11 and Linux.

(I don't have enough experience with Mac's to speak to it).

It's the GNOME style of development: as soon as a bug appears which takes effort to fix, mark it EWONTFIX, declare it to be a symptom of the inherent brokenness of the current stack, then burn the whole thing to the ground and start over. Don't even let that which was burned fertilize new growth; it is tainted and must be purged entirely.

How have you managed to make an argument about embedding a web browser about GNOME?

As it were, GNOME's IDE (which I wrote) uses 0% CPU at idle.

Gedit is fantastic. Thanks for all the work on it. I used it for years before VS Code, and I still use it outside of work on my personal projects.

Amazing how much work you can get done by just typing the damn code into the editor, sometimes.

However, writing typescript in vscode genuinely changed the way I think about editors. It's a smalltalkish sort of feeling where my code (at least the textual level) lives and breathes in the editor, automatic tooltips that are actually relevant, etc.

Idk. I like both.

I work on Builder, not Gedit. However, Gedit does get various features as we push them up into Gtk/GtkSourceView. The overview map is one such example. The pixelcache in GtkTextView enabling smooth 60fps scrolling is another.

To be fair, the conversation had already shifted to X11/Wayland. GNOME does have a history of starting over from scratch every few years; you probably had a good reason for writing Builder instead of working on Anjuta, and that's just the way the GNOME community seems to do things.

This makes people, especially power users, disproportionately angry because when you rewrite something, it will be different (that's sort of the whole point);this is compounded by the fact that at the beginning it will be feature-poor compared to the older system.

"Why did you replace X with Y? With X, I could configure it to treat mouse-button-3 as mouse-button-2, but only when my USB mouse was not attached and I wasn't holding down any modifier keys."

See also: https://xkcd.com/1172/

Before I did any serious software development, I was on that side of the table being frustrated (I still cry a little inside any time I remember Galeon. Rest in Peace, my favorite browser).

I can also neither confirm nor deny that my windows are being decorated by sawfish and that I wrote a compositor in librep so that I could get modern features while using it.

> GNOME does have a history of starting over from scratch every few years;

The GNOME project will be 20 years old in a couple of months. So while it might feel like "every few years", we really don't change direction all that often.

As you can imagine, those that show up to do work have a great deal of say in where the project goes.

> you probably had a good reason for writing Builder instead of working on Anjuta, and that's just the way the GNOME community seems to do things.

> This makes people, especially power users, disproportionately angry because when you rewrite something

You've sort of made my argument for not changing Anjuta over the years. We knew the amount of stuff that had to be changed would leave both the code-base and UI looking very little like Anjuta. Best to let people continue using it in the mean time.

> (I still cry a little inside any time I remember Galeon.

It lives on as Epiphany and is the primary driver of the WebKitGtk backend.

> Not to mention network transparency when I need it

You realize that no X client draws like this nor has for 20 years right? They all use xshm to upload pixels so this "network transparency" is just buffer copying over the network. Not entirely different from a texture upload to a GPU.

> So it's a good job we're about to throw it all out and start again, eh folks?

Yes, by those of us who have been working on the same platform you claim to love, for the better part of a couple decades.

> You realize that no X client draws like this nor has for 20 years right? They all use xshm to upload pixels [...]

You seem to be misinformed. Of the applications I mentioned, the main ones (gitk, xterm, emacs, xosview) are not doing that; seen clearly by analysing the X traffic.

Of course, some of these could be built with an optional Qt front-end, in which case I would not be surprised.

So you stated clearly "all" applications (for "20 years") which is provably incorrect; and I home in on this because it's a recurrence of another 'well, you never had it before' argument (that really might be better directed at the decaying state of X11 client toolkits)

X11 isn't perfect, I have no doubt something better can be engineered (especially if it involves those who worked on X11). But people are missing the point that to replace X11 is a different matter from designing a better one. It involves acknowledging those who are quietly and successfully using X11 on a daily basis for the majority of their work and existing applications -- not telling us how wrong we are.

That's precisely why I stated 20 years. Those programs were written before that and largely haven't changed since.

If you wan't anti-aliasing in any of those above (gitk/emacs come to mind) you'll be doing client side rendering of fonts and copying pixels.

> no X client draws like this nor has for 20 years

If something was written a long time ago and hasn't changed in this respect, BUT is still widely used... you can't say that "no X client draws like this nor has for 20 years."

"Copying pixels" is the dominant mode of operation in other remote GUI protocols like RDP, so it's not the end of the world.

Indeed. Especially since TCP-based X would require that you stall operations if you drop a packet so that draw-ordering is preserved.

If you want to optimize for choppy networks that have too much packet loss for interactive TCP applications , then the current X11 is not a good fit. But that would be a whole different niche.

Could have sworn that there exist multiple takes on extensions for that, but none that has been rolled into Xorg proper. This either because lisencing, or because the current devs have GPU stars in their eyes.

BTW, it is downright funny how just about every Gnome guy i have encountered online seems to come across a pedantic grump. that would not know a joke if it fell on his head...

Interesting how one person is a common denominator in all those interactions ;)

And most of the comment gets ignored for a cheap retort, as expected.

you've mentioned something i've not heard about without linking to it or providing a name to help me find it myself. so i'm not sure what you'd like from me.

Actually, RDP is GDI over the wire, which is not too dissimilar from X.

RDP has efficiency gains because clients send pixmaps over the wire to be stored on the server, and then send draw calls to display those pixmaps in certain places, composing a display. You can do this with X11 too, but the GTK developers don't want to because using the protocol is hard ;_;

gtk+ certainly does use server-side textures and positioned draws. That is why the documentation is so adamant about using API like create_similar_surface().

Even the pixelcache uses server-side textures when available.

This is what Xshm does and why everything modern uses it. You get a server-side texture, but mapped into client address space so you can do direct draws and then XCopyArea() into your final location for double-buffering.

But gtk+ isn't really in the position to be able to control everything so precisely all the way down the driver stack to network transparency layers. So unless you connect to our process directly, like the HTML5 broadway backend, there is only so much we can do.

The broadway backend does employ various techniques to reduce the amount of content passed using a sort of rolling hash.

https://git.gnome.org/browse/gtk+/tree/gdk/broadway/broadway...

I expect forthcoming app/display network transparency layers in GNOME's Wayland compositor to employ a similar strategy.

It is reminding me that webkit is grand child of QT. QT > KDE > khtml > webkit

In 2000, I don't think many open source X clients (typically Linux stuff) used xshm. Not using X any more, I can't really comment on the current scene. But apart from things like MAME and vlc, what app needs it? And web browsers, of course.

(Accelerating OpenGL in hardware but displaying in an X11 window is a different question.)

To be fair, X11 can't handle multiple displays with mixed DPI.

You sort of can with xrandr scaling.

Last time I did that, my CPU was always spinning and the rendering looked blurry and non-crisp. Now I just prefer to reduce my emacs and terminal font size, and keep Chrome in one display forever.

X11 may "run really well these days" if your reference is X11 twenty years ago, but if you compare X11 to e.g. macOS, it's pretty obvious why Wayland is needed.

X11 network transparency was nice feature when 10 mbit ethernet was hot as pizza, but these days remote desktop protocols offer more practical alternative.

Don't forget to install the plugin that actually allows you to run a web browser inside your web browser-based editor:

https://atom.io/packages/browser-plus

I enjoyed your comment. The non-funny response is that all GUI layers suck, possibly because visual interfaces and abstract code are inherently incompatible. Since no one has managed to make the perfect GUI, we constantly look to improve on the tradeoffs we must make, which are different for different applications. 13% idle sounds egregious but higher battery usage isn't a problem for most if it excels in the areas that matter: responsiveness, design, power, completeness. In contrast, Wayland improves not just idle, but also overall performance, which is the main consideration for a low level API.

"3% idle sounds egregious but higher battery usage isn't a problem for most"

Oh God this is why we can't have nice things. How the heck is someone actually justifying this stupid shit here?

What do you find stupid? The way I see it, HTML/JS is a pretty good higher-level GUI language, and much effort has been spent making it work well. The overhead is worth it if it makes developers more productive.

Fair enough, but double-digit usage of an entire core... when the program is IDLE? how can you justify that? That's just broken.

They will indeed fix this. At minimum, they can freeze the editor when it's out of focus. So there is no need to justify--this is a minor oversight, as someone phrased it over at Slashdot.[1]

I was responding to those who believe that this demonstrates a fundamental flaw in using Electron. My response emphasizes the tradeoffs involved. If they couldn't fix it, 13% background is undesirable, but it's not a dealbreaker for me if there are redeeming qualities. And it seems that VS Code certainly has some redeeming qualities.

[1] https://developers.slashdot.org/comments.pl?sid=10406465&cid...

Is it? The costs which you offset with developer productivity get multiplied times the number of users, which is orders of magnitude more than number of developers.

And value delivered also gets multiplied by the number of users. VS Code users decided that they like it even after accounting for Electron. Clearly, then, VS Code has certain strengths, and I'd argue that some of those strengths are made possible by Electron. Second, great design requires experimentation, and Electron makes it easier to experiment with editor UI. VS Code could become a place to prototype ideas that eventually improve your more efficient editor.

Why I agree on "much effort has been spent" it is very hard to agree about HTML which was meant to be used for marking up static documents combination with ad-hoc scripting language being "pretty good" for GUI. More like "possible to work around a bit".

> higher battery usage isn't a problem for most if it excels in the areas that matter

As engineers it's our responsibility to not spend our users' resources unnecessarily. This thinking is how we got to the bloated web where pages need a megabyte (or several) of code just to render. Could you imagine an architect saying, "yeah, this design costs 2x that other one, but my clients are rich so it doesn't really matter"? The old saw that "anyone can build a bridge that stands up; it takes an engineer to build a bridge that barely stands up" applies.

I'm glad at least we made fun of both sides.

I really wish there was a good option for GUI toolkits. Nearly all are either too primitive to make more than freshmen college (or tenured physics professor) level work or asymptotically approach web browsers without all that tedious attention to improvement and accessibility.

Qt pretty much nails this balance, WPF isn't bad either. Both will run circles around browsers at rendering performance and are much less tedious to develop in unless you've only done web dev before.

If you learn React, you can write for web, multi-platform desktop and (native) mobile, with React Native. Same can't be said for Qt or WPF.

Also the Qt community is minute compared to the JS community, that is significant.

js community is filled with 20-somethings with ADHD (i'm 26) that reinvent the wheel every 2 weeks instead of helping polish other projects.

"If you learn how to build doghouses, you can build skyscrapers, bridges, and nuclear power plants."

Use the right tools for the job. Trying to shoehorn everything into "the web" makes everything just as shitty as the web.

> Use the right tools for the job

i wonder if this expression constitutes a thought-terminating cliché.

It does, inasmuch as objective metrics for "correctness" don't exist in our field. The best we can do is show "incorrectness." It's absurd to say, "My tool is correct and therefore should be used," when all we really can demonstrate is, "My tool lacks these specific deficiencies I can identify in another choice."

This bug comes nowhere near demonstrating that Electron or VS Code or Atom are built incorrectly or incorrect tools

It sounds a bit like one, but I think the point is that while the web can be used for everything, that doesn't mean it should. Like if we built XML into filesystems directly, instead of doing it just in the layers above.

> Trying to shoehorn everything into "the web"

'Trying to shoehorn' is just your opinion.

> Use the right tools for the job.

What does that non-sequitur even mean in this context? Use a different native platform to write each native version of the app? That simply isn't viable for anything but very large companies.

Or should I use Qt, with it's tiny support community?

Also why is React/React-Native not 'the right tool'?

> [...] just as shitty as the web.

Again your opinion. In my opinion the web is a joy to work on compared to the cesspool that is native app development.

It's unfortunate that your opinion–that of the two most successful programmer's editors currently in use today are doing something right–is being heavily downvoted by people who object to the "web" invading on their territory for reasons unknowable.

"Eating too many CPU cycles while idle" is a problem many, many text editors have faced. It's purely an unfair bias in this case that this is justification for trying to invalidate the project.

By the way, if you'd like to really throw a stick into Qt proponents spokes, ask them what sort of accessibility story QT has for custom rendering components. Ask, "How can I support a colorblind or legally blind person with this component?"

Qt's developer story here is not nonexistent, but it throws into sharp contrast how _complete_ the web is from the perspective of accessibility for people who need auditory assistance or do not use conventional input devices.

Yes it is sad that it is one of those topics that HN users seem incapable of discussing objectively. Meanwhile Electron usage grows and grows, and will continue to until someone comes up with a viable alternative.

If you disagree, tell me what I should use instead of Electron, that is feasible to use for a small team to have a wide platform reach, and with a community comparable to even just the 'React' part of web dev.

The drive-by downvotes really just prove my point.

Yeah, thought so.

As someone who maintain other peoples code I really don't look forward to deal with js a few years from now:

What build system did they use?

Where is that package? Does it even exist anymore.

Etc.

Had similar problems trying to maintain a delphi project as an almost fresh from scool developer. At that point I understood the value of Java and Maven.

Typically in Javascript, you would use npm's package.json for building, or you would use npm to install some well defined version of some build system, like you do for other packages. Like Maven builds, it works smoothly and predictably.

It's true, but there is an interesting mitigating effect here. If at some point you come across an old project that appears to be a product of herculean effort, note that these days its a matter of a few days effort.

The platform that JS is based upon moves incredibly fast.

If you're meaning to say you can write "multi-platform desktop" apps using Electron... I suppose you're technically correct, but they don't feel native on any platform, are generally slow, massive to distribute, don't integrate well with other applications and generally have weird non-native-app-like behavior. Like Discord I can resize and have the minimize/maximize/close buttons overlap the window. Atom and VS Code still can't do DPI scaling right. I wouldn't say you can build good desktop apps with them. Just crappy little ones. Maybe that's necessary to interact with one library or another, but that's a tradeoff. And a big and important one to recognize.

Maybe React Native will work on desktop and fix all this eventually, but IMO React Native is just not there yet, it doesn't even feel native on mobile.

I say this as someone who writes both an app with both an Electron/React portion (in order mainly to interact with a specific JS library) and a Qt portion. I really do like the way React does a lot of things and npm seems like the exact right way to do package management in a programming language - but the JS ecosystem is a mess. While I'll agree the wealth of developers on it has had many good results, it's also created a horrible moving target. There are half at least 5 different and fairly popular module systems, module loaders, etc. There are constant attempts to use language features which aren't official yet or even at a final spec via babel. The build and packing systems are a mess, everyone has their own different series they prefer and getting working integration between a few can be problematic.

> If you're meaning to say you can write "multi-platform desktop" apps using Electron... I suppose you're technically correct, but they don't feel native on any platform,

You know, people say this, but I'd like to push back on it. "Platform native feel" is not something that I think most folks care about. You may need it if you're looking to ship an app for a pay-for-a-copy model, but the vast majority of computing hours people spend are already mitigated by their web browser of choice, and that seems to not really cause any substantial problems.

Electron is a flawed framework for building an app, sure, but you could argue Cocoa or Windows Universal are equally flawed in many ways. They also require a lot more code to get equivalent layouts, are almost never very good at reactively resizing (you may say it doesn't matter, I say I unplug in an external monitor and expect to have something sane happen). The fact that a bug exist causing repeated simple draws to be more expensive than expected is normal for text editors. You can find issues caused by similar problems in Sublime, Emacs, and even Notepad++.

Maybe it's just me, but I always avoid apps that don't integrate well with my platform. They're just not pleasant to use. I want the same look and feel, I want the same file browser, I want the same DPI scaling my desktop uses and I want the same UI standards followed, not some giant mess of whatever every individual dev decides seems nice that day.

I'm not so sure it's mitigated by the web - people may browse Facebook and a few news sites, but those aren't complex applications at all and they have very simplistic UIs that don't attempt to imitate familiar desktop controls or to show desktop concepts like files and folders.

I have far more problems with Electron app sizing than I do with proper desktop apps - see my examples above.

> I want the same DPI scaling my desktop uses and I want the same UI standards followed, not some giant mess of whatever every individual dev decides seems nice that day.

You must not use OSX native apps then with multiple monitors then. They don't work right (at least not for me!) One of the reasons I use Chrome for so much is that when I change my workspace (as someone who does both coding and project management this is increasingly a requirement) I don't want my UI to clip off the frame unrecoverably or render as a blurry mess.

> I'm not so sure it's mitigated by the web - people may browse Facebook and a few news sites, but those aren't complex applications at all and they have very simplistic UIs

You should look at the Chrome Web Store. But... also... "Facebook?" "Simplistic?" Simplistic is hacker news, where I can't use an Emoji.

> that don't attempt to imitate familiar desktop controls

One last thing: this is much more a sign of the current UI style of the time, and is very much a product of a post iPhone world where unique visual styles are expected. Even then, a text editor is such a specialist piece of work even native apps struggle and cheat, doing things like avoiding sheet animations and providing unique UI and UX components. Native apps have been introducing their own file hierarchy and multi-modal buttons since the time of emacs.

Such a pity that WPF was never ported to other platforms That's a UI framework that was done right in my opinion. Fast, incredibly flexible and sane.

That it's been relegated to boring internal only enterprise app development is pretty sad. I enjoyed working with it immensely.

It also suffers similar problems to the one posted here (or at least used to), an idle app will consume quite a bit of CPU.

A WPF app is just a .Net app. I can't recall the problem described ever having been an issue.

Avalonia is a decently nice cross platform C# + XAML GUI toolkit. It doesn't cover every use case WPF does, of course, but I've still found it pleasant to use.

AppKit/Cocoa is very good too, if not cross-platform. Consistent, dynamic, extensible, and there's so much your apps get for free, and new features often become retroactively available for past apps, like when NSDocument got autosaving, and now tabs for multi-document apps, the wide-gamut-aware color pickers and so on.

A project I've been keeping my eye on is libui (https://github.com/andlabs/libui), it's basically a thin wrapper around the native libraries (very SWT like) that can be used in a number of languages.

I have done both and I am not at all a fan of QT.

Seconding Qt, there's a bunch of bindings for non-C++ languages as well. It hits the uncanny valley sometimes but overall it's much better than the alternatives (like WxWidgets).

wxWidgets has improved a lot, give it a try.

If you could n-gate every article as it's posted, that would be awesome.

bummer n-gate didn't comment on its own hn post

I was really looking forward to that write up, as well. Unfortunately, the author must have some rule about not breaking the fourth wall. Or they avoid softballed summaries?

I think a recursive n-gate situation would be delightful. Someone should make this happen.

One Hackernews asks some Hackernews to ask the internet to make a satire about a satire of some Hackernews. Hackernews becomes Stackoverflow.

Some internets post weekly bitter satires of Hackernews to the internets. Hackernews finds it and misses the point entirely, of course: Hackernews is being laughed at, not with.

An internet finds a bitter satire of his industry and is endlessly amused at taking the piss out of sincere but naive youngsters who debate technical concerns without understanding the appropriate context and history. The mocker misses the point entirely: Hackernews didn't fail, the generation that came before did, in letting their culture die.

For those who missed it, n-gate satirizes some HN posts, to the delight of all: http://n-gate.com/hackernews/

Oh my god... n-gate is pure gold!

They had me at "Hacker" "News". Thank you so much for sharing this! (Hell, I mostly quite like HN and I'm sure I'm often part of the problem, and this is still wonderful.)

Yes, embedding a web browser is wasteful.

But, it is EXTREMELY EASY. There's a reason why Github, Microsoft, Facebook, Adobe etc converged on this decision, and it's not the bandwagon effect. Faced with the same task recently, I did my research, and it is indeed easy.

Since I work on the JVM, my alternative was JavaFX. That didn't seem so bad, but it was much more work. If you look at say IntelliJ IDEA on some platforms, you'll see the text rendering is much uglier than on Atom. Regrettably, if you want to acquire users, that matters more than conservation of resources.

I'm curious: have you ever tried interfacing with X11?

I mean, I couldn't agree with you more about the asininity of embedding a browser in a 'native' app (for anything other than web browsing). But I use VSCode all day, every day, and subjectively it feels zero-latency on my aging laptop.

It's kind of a crazy concept, especially if you are old enough to remember the days where RAM was counted in kilobytes and you would optimize assembler code to save clockcycles.

On the other hand, this is 2017, and people apparently don't care much about the footprint of their software, as long as it's convenient and it solves their problem. And ultimately that's what counts I guess.

So today I noticed that when you try to select text in a tool window, it really does act like a browser. The window won't scroll. The selection spills into other windows. There's no way to select anything you'd have to scroll to.

https://pavelfatin.com/images/typing/editor-latency-windows-...

You know what would be fast for display updating, ncurses. I wonder why they didn't use that? If only we had an ncurses based text editor.

Someone should write a webkit based ncurses! Why haven't we seen the light before !? ;)

There is already an ncurses library for JavaScript [1] so one for WebKit shouldn't be far off ;)

[1] https://github.com/chjj/blessed

Ncurses is the worst gui toolkit there is (from a developer point of view), although it indeed is lighter on resource usage than most of the others if you do it right.

I was with you until the non-sequitur about Wayland. What exactly is shitty about Wayland? It is way less bloated than X11.

The design of Wayland might be (and I believe is) superior to X11. Although as every piece of software on this planet in first years of its existence it will be incomplete, buggy and not compatible with all the other things that already exist. For some people this might be shitty compared to mature software, that is buggy but at least most of it's bugs are already known and worked around.

Love your meta comment

Consider writing a douglas adams style book

I see this argument against electron again and again. Sure, sometimes its overkill - I've seen tray notification apps built with it - but sometimes, it's not. Sure it's not as efficient as something written in .Net, but its a great, hassle free way to go cross platform.

People don't complain that web IDEs are bloated and slow because they need a web browser

Really the argument gets less and less valid over time, for every one of these issues that get discovered, a patch gets made that solves the issue. The platform evolves and gets better until someone else finds an inefficiency, that seems like a pretty typical advancement to me.

You're projecting quite a bit there. There's tons of comments lambasting what's going on in the article.

Reply on news.ycombinator.com