5 ms·

What people don't realize is that modern, high-level languages and abstractions give you much more than just speed of development. If you use a garbage collect

What people don't realize is that modern, high-level languages and abstractions give you much more than just speed of development. If you use a garbage collector, you don't have to do manual memory management, which is amazing for security. You also don't need to worry about buffer overflows and weird pointer exploits. If you use web tech, you get a lot of important stuff, like sandboxing, handling of esoteric keyboards, RTL languages and screen reader accessibility almost for free. If you use some extremely fast, small and lightweight GUI framework, you will probably not implement those, as they seem boring, and who needs that anyways. If you go the handcrafted, lightweight and fast route, you're sacrificing a lot of features, possibly without even being aware of what you lose until it's too late. I will happily shelve a few more bucks for RAM and wait a few more seconds to get an accessible, secure Messenger, instead of one that is going to steal my bank details the moment some stranger sends me a malicious GIF.

mwcampbell 6y ago
> If you go the handcrafted, lightweight and fast route, you're sacrificing a lot of features, possibly without even being aware of what you lose until it's too late. And, just to amplify the point about accessibility, you may be blocking some people from using your app. So it's not entirely about what you lose. That's not so bad if you're developing a game. But the projects on this site include a programmer's editor and a debugger, both of which are completely inaccessible with a screen reader because, of course, they use a handmade GUI.
- miki123211 6y ago
  Handmade GUIs, frameworks drawing on canvas instead of using DOM, and abominations like VNC over web instead of normal desktop apps seem to be the new accessibility plague. We're pretty much done with Flash and Java on the desktop, QT isn't that bad any more, accessibility-wise, but this kind of stuff is now becoming more and more popular. I've heard of systems that promise you better utilization of your licensing resources, but what they do is put your precious 10 computers with some expensive software on the internet, letting any employee with a web browser book some time and access them via Web VNC. That's a brilliant way to turn a perfectly-accessible Windows app into something you can literally do nothing with.
  - CyberDildonics 6y ago
    Not everything needs to prioritize accessibility. This page is mostly tools for video games which typically have no accessibility. I think you may be bringing a pet concern into an area that isn't relevant.
    - mwcampbell 6y ago
      What we, or at least I, want to ensure is that developers outside of the gaming context don't get too fired up by this manifesto, develop non-game-related tools in that spirit, and thereby block someone from doing their job because the tool is inaccessible.
      - CyberDildonics 6y ago
        Not everything is going to work for everyone from the very start. You don't need to stomp on every piece of software because it doesn't have niche features that you care about intensely. Pick your battles, each of these programs were created by a single person and are open source. They aren't government websites, they aren't even the only way do the things they do.
      - deleted 6y ago
        [deleted]
    - deleted 6y ago
      [deleted]
  - guidoism 6y ago
    Pretty sure OP’s article is advocating completely removing that whole massive stack of trash of web tech and instead use technology designed for the particular computer they are running on.
mrmonkeyman 6y ago
Malicious gifs are the exact problem that you will solve with simple to the point software. It'a the behemoths that we are producing at an astonishing rate that are the problem.
justin66 6y ago
> If you go the handcrafted, lightweight and fast route, you're sacrificing a lot of features, possibly without even being aware of what you lose until it's too late. The notion that an engineer signing on to make high-performance software in 2020 doesn't know what they're "sacrificing" is a little unreasonable. Conversely, it seems unlikely most people developing the kind of software you're advocating for understand the tradeoffs they've made at all. This is all simply about where engineers start off today, and how woefully uninterested they often are in expanding their horizons, and how uninterested they tend to be in studying the history of their discipline.
- mwcampbell 6y ago
  You make good points. And I do think miki123211 is conflating memory safety with GC. But the concerns about Handmade software lacking important user-facing things like accessibility and internationalization are real. TO take one particularly ironic example, lots of tools in the field of audio production roll their own GUIs, and invariably, these UIs are completely inaccessible to screen reader users. I say this is ironic because "blind musician" is such a stereotype. To dispense with a straw man, it's true that Electron would not be a good fit for these tools. But maybe their developers could accept the size of something like Qt in exchange for a GUI that works for all users without having to roll it themselves. You say that engineers should be aware of trade-offs, but in my experience, way too many, even very talented engineers, seem to ignore this one.
  - ratww 6y ago
    A lot of VST/AU plugins already use Qt, JUCE or SynthMaker for the GUI and are completely inaccessible. On the other hand, there are a lot of web pages and Electron apps that are completely inaccessible as well, despite using accessibility-ready web tech. The problem is not really the lack of an abstraction layer, but more the fact that those developers are doing a shitload of work to make something look über cool and different from everyone else without taking a couple weeks (or maybe not even that much) to iron out accessibility issues. By the way, at least for plugins, another option is not doing any GUI at all and just exposing all parameters to the host, like the AirWindows guy does [1]. Or using native OS controls. This is both very accessible and EXTREMELY cheap. [1] http://www.airwindows.com http://www.airwindows.com
beached_whale 6y ago
A pedantic point, buffer overflow protection and the GC are separate things. Buffer overflow protection is bounds checking, GC's are ensuring memory that is no longer in use is reclaimed. But the boundaries on the programs you mention, are more to do with the system not allowing these actions than the language. Also, there are other ways to achieve memory safety for all but maybe a few cases without a GC. One being ref counted structures that have loops in the links. Another case, but it has work arounds, is postponing the cleanup until a later time. But C++ provides guarantees like, at scope end the destructors(finalizers) are run and the values are cleaned up. This allows for more than memory safety and can include other resources too. This is easier in greenfield projects where old idioms/C compatibility are more common. To add to your point, high level abstractions allow for optimal code as it is more declarative. The low level constructs to make it fast are of no concern to the caller. And one can build upon this for new higher level abstractions.
- beached_whale 6y ago
  I should have said, less common in greenfield projects. oops
- deschutes 6y ago
  What is your point? The way refcounted smart pointers are used in modern c++ doesn't come close to addressing all the memory safety issues. Iterator invalidation, bounds checking, use of uninitialized memory, use after move, dangling reference (outside the aforementioned cases), etc. What they're pretty good at is solving for use after free. Even there, caveats apply (see widely documented thread safety fiasco of shared_ptr).
stephenr 6y ago
> If you use web tech, you get a lot of important stuff, like sandboxing, ... for free That’s very context dependent, no? Electron removes a heap of sandbox limitations does it not?
- mwcampbell 6y ago
  Actually it has been adding them back in the renderer process, and encouraging developers to use explicit IPC between the renderer process and the main process.
- onion2k 6y ago
  Electron removes a heap of sandbox limitations does it not? That's not really web dev. It's the application of web tech to something that isn't web. A slightly pedantic point I guess, but if you choose to give up the benefits of a browser you can't really complain that you don't have them any more.
  - stephenr 6y ago
    > That's not really web dev. I didn't claim that it is. > It's the application of web tech So you can see then why I quoted the part of the parent comment that says: > If you use web tech, you get a lot of important stuff, like sandboxing, ... for free The parent didn't say "if make a web site" s/he said "if you use web tech".
ratww 6y ago
If you want the advantages of the garbage collector but the power of native there are languages like D, Go, Rust, Objective-C, Swift. If you want an "extremely fast, small and lightweight GUI framework" that also handles esoteric keyboards, RTL languages, screen reader accessibility and other things you can use your OSs native controls. I bet most naïve (and native) Cocoa/Win32 app will give you 100x better keyboard navigation than most Electron apps from large companies.
- mwcampbell 6y ago
  > I bet most naïve (and native) Cocoa/Win32 app will give you 100x better keyboard navigation than most Electron apps from large companies. That may be true for Cocoa, but it actually isn't for Win32. It takes work to make keyboard navigation work correctly in Win32, unless you're using a dialog with nothing but standard controls (note: dialog means something specific in Win32). Windows Forms helps with this. Also, as soon as you depart from the stock Win32 controls, you have to implement the UI Automation accessibility API entirely on your own, and that's not an easy task even for a single custom control. So there are actually good reasons why Win32 isn't a good choice for new projects. There's another reason why web applications tend to be more navigable with third-party Windows screen readers than native applications. For the mainstream web rendering engines, third-party screen readers enable a sort of virtual cursor that let's the user navigate the DOM in a linear way by pressing the up and down arrow keys. This makes it straightforward to navigate to anything in the document, even if the application itself doesn't implement keyboard navigation. Now, this same navigation model could just as well be applied to native applications, and the Narrator screen reader built into Windows actually does offer that option. The fact that third-party screen readers restrict that option to web content is arguably a deficiency, but one that developers who care about accessibility should consider when targeting Windows today. Disclosure: I work for Microsoft on the Windows accessibility team, primarily on UI Automation and Narrator. These are my own opinions though.
flohofwoe 6y ago
IMHO these are unrelated problems. There's nothing preventing those 'handmade' libraries from using memory-safe languages and development practices, or calling into accessibility APIs provided by operating systems (assuming they are provided by operating systems), and on the other hand, Electron is the opposite of the 'handmade philosophy', but is still not accessible. There's required complexity, and unnecessary complexity, and the latter is the worse problem in modern 'industrial' software by far, because industrial software isn't developed by customers needs, but by business needs, and the gap between what customers want and what the industry provides seems to widen more and more each year. This 'industrial software development' that doesn't serve the user anymore is what the handmade philosophy is providing an alternative to.
- mwcampbell 6y ago
  > Electron is the opposite of the 'handmade philosophy', but is still not accessible. On the contrary, Chromium probably has the single most mature and robust implementation of accessibility APIs across platforms. It's true that not all Electron apps are accessible, but it's way easier to make an Electron app accessible than to make a handmade GUI accessible.
  - flohofwoe 6y ago
    Yeah, ok, but the problem is the same: even though accessibility APIs might be provided (this time by Electron, not the OS), applications don't make use of them.
    - mwcampbell 6y ago
      Sure, we still have to fight that uphill battle. But it's way easier for a web application to implement ARIA than for a Win32 application with a custom control to implement UI Automation. Maybe that problem is unique to Windows.
      - deleted 6y ago
        [deleted]
vmchale 6y ago
> If you use a garbage collector, you don't have to do manual memory management Also easy higher-order functions. Plus it can be more performant in some cases. > I will happily shelve a few more bucks for RAM and wait a few more seconds I have 64GB on my desktop (happily!) but waiting is a bit of a pain! And it's often for silly reasons.
gameswithgo 6y ago
>If you go the handcrafted, lightweight and fast route, you're sacrificing a lot of features, possibly without even being aware of what you lose until it's too late. Some modern languages offer memory safety and very very high performance ceilings as well, if you are willing to learn how and work at. Examples include, C#, Rust, F#, and Nim. There are others! And any language, taking some time to understand performance pitfalls, and leveraging the language the best you can, can make a huge difference. Sometimes without any major maintenance or dev time penalty. It just takes caring, and practice.
fulafel 6y ago
The linked manifesto doesn't seem to be especially against garbage collection. And on their web site the latest news item is a "Lisp Jam"... The only reference to GC is in this sentencs: "The deadline is approaching or the rent is due or we have taxes to fill out and a manager on our back and someone asking us why we always spend so much time at the office, and we just have to stick the library or virtual machine or garbage collector in there to cover up the places we can't think through right now. " The situation is kind of choosing-shame-but-ending-up-in-war outcome[1] and is not saying that the referenced techniques (incl gc) would be generally bad. [1] https://richardlangworth.com/war-shame https://richardlangworth.com/war-shame
peacefulhat 6y ago
So bizarre to claim Messenger is secure because it was written in Javascript.
Olreich 6y ago
Doesn’t the ImGUI UI library have pretty good accessibility now without sacrificing on memory consumption and performance? JavaScript is difficult to program in a safe way, so I’m going to assume the Messenger app is written in something safer too.

mwcampbell 6y ago

> If you go the handcrafted, lightweight and fast route, you're sacrificing a lot of features, possibly without even being aware of what you lose until it's too late. And, just to amplify the point about accessibility, you may be blocking some people from using your app. So it's not entirely about what you lose. That's not so bad if you're developing a game. But the projects on this site include a programmer's editor and a debugger, both of which are completely inaccessible with a screen reader because, of course, they use a handmade GUI.

miki123211 6y ago
Handmade GUIs, frameworks drawing on canvas instead of using DOM, and abominations like VNC over web instead of normal desktop apps seem to be the new accessibility plague. We're pretty much done with Flash and Java on the desktop, QT isn't that bad any more, accessibility-wise, but this kind of stuff is now becoming more and more popular. I've heard of systems that promise you better utilization of your licensing resources, but what they do is put your precious 10 computers with some expensive software on the internet, letting any employee with a web browser book some time and access them via Web VNC. That's a brilliant way to turn a perfectly-accessible Windows app into something you can literally do nothing with.
- CyberDildonics 6y ago
  Not everything needs to prioritize accessibility. This page is mostly tools for video games which typically have no accessibility. I think you may be bringing a pet concern into an area that isn't relevant.
  - mwcampbell 6y ago
    What we, or at least I, want to ensure is that developers outside of the gaming context don't get too fired up by this manifesto, develop non-game-related tools in that spirit, and thereby block someone from doing their job because the tool is inaccessible.
    - CyberDildonics 6y ago
      Not everything is going to work for everyone from the very start. You don't need to stomp on every piece of software because it doesn't have niche features that you care about intensely. Pick your battles, each of these programs were created by a single person and are open source. They aren't government websites, they aren't even the only way do the things they do.
    - deleted 6y ago
      [deleted]
  - deleted 6y ago
    [deleted]
- guidoism 6y ago
  Pretty sure OP’s article is advocating completely removing that whole massive stack of trash of web tech and instead use technology designed for the particular computer they are running on.

mrmonkeyman 6y ago

Malicious gifs are the exact problem that you will solve with simple to the point software. It'a the behemoths that we are producing at an astonishing rate that are the problem.

justin66 6y ago

> If you go the handcrafted, lightweight and fast route, you're sacrificing a lot of features, possibly without even being aware of what you lose until it's too late. The notion that an engineer signing on to make high-performance software in 2020 doesn't know what they're "sacrificing" is a little unreasonable. Conversely, it seems unlikely most people developing the kind of software you're advocating for understand the tradeoffs they've made at all. This is all simply about where engineers start off today, and how woefully uninterested they often are in expanding their horizons, and how uninterested they tend to be in studying the history of their discipline.

mwcampbell 6y ago
You make good points. And I do think miki123211 is conflating memory safety with GC. But the concerns about Handmade software lacking important user-facing things like accessibility and internationalization are real. TO take one particularly ironic example, lots of tools in the field of audio production roll their own GUIs, and invariably, these UIs are completely inaccessible to screen reader users. I say this is ironic because "blind musician" is such a stereotype. To dispense with a straw man, it's true that Electron would not be a good fit for these tools. But maybe their developers could accept the size of something like Qt in exchange for a GUI that works for all users without having to roll it themselves. You say that engineers should be aware of trade-offs, but in my experience, way too many, even very talented engineers, seem to ignore this one.
- ratww 6y ago
  A lot of VST/AU plugins already use Qt, JUCE or SynthMaker for the GUI and are completely inaccessible. On the other hand, there are a lot of web pages and Electron apps that are completely inaccessible as well, despite using accessibility-ready web tech. The problem is not really the lack of an abstraction layer, but more the fact that those developers are doing a shitload of work to make something look über cool and different from everyone else without taking a couple weeks (or maybe not even that much) to iron out accessibility issues. By the way, at least for plugins, another option is not doing any GUI at all and just exposing all parameters to the host, like the AirWindows guy does [1]. Or using native OS controls. This is both very accessible and EXTREMELY cheap. [1] http://www.airwindows.com http://www.airwindows.com

beached_whale 6y ago

A pedantic point, buffer overflow protection and the GC are separate things. Buffer overflow protection is bounds checking, GC's are ensuring memory that is no longer in use is reclaimed. But the boundaries on the programs you mention, are more to do with the system not allowing these actions than the language. Also, there are other ways to achieve memory safety for all but maybe a few cases without a GC. One being ref counted structures that have loops in the links. Another case, but it has work arounds, is postponing the cleanup until a later time. But C++ provides guarantees like, at scope end the destructors(finalizers) are run and the values are cleaned up. This allows for more than memory safety and can include other resources too. This is easier in greenfield projects where old idioms/C compatibility are more common. To add to your point, high level abstractions allow for optimal code as it is more declarative. The low level constructs to make it fast are of no concern to the caller. And one can build upon this for new higher level abstractions.

beached_whale 6y ago
I should have said, less common in greenfield projects. oops
deschutes 6y ago
What is your point? The way refcounted smart pointers are used in modern c++ doesn't come close to addressing all the memory safety issues. Iterator invalidation, bounds checking, use of uninitialized memory, use after move, dangling reference (outside the aforementioned cases), etc. What they're pretty good at is solving for use after free. Even there, caveats apply (see widely documented thread safety fiasco of shared_ptr).

stephenr 6y ago

> If you use web tech, you get a lot of important stuff, like sandboxing, ... for free That’s very context dependent, no? Electron removes a heap of sandbox limitations does it not?

mwcampbell 6y ago
Actually it has been adding them back in the renderer process, and encouraging developers to use explicit IPC between the renderer process and the main process.
onion2k 6y ago
Electron removes a heap of sandbox limitations does it not? That's not really web dev. It's the application of web tech to something that isn't web. A slightly pedantic point I guess, but if you choose to give up the benefits of a browser you can't really complain that you don't have them any more.
- stephenr 6y ago
  > That's not really web dev. I didn't claim that it is. > It's the application of web tech So you can see then why I quoted the part of the parent comment that says: > If you use web tech, you get a lot of important stuff, like sandboxing, ... for free The parent didn't say "if make a web site" s/he said "if you use web tech".

ratww 6y ago

If you want the advantages of the garbage collector but the power of native there are languages like D, Go, Rust, Objective-C, Swift. If you want an "extremely fast, small and lightweight GUI framework" that also handles esoteric keyboards, RTL languages, screen reader accessibility and other things you can use your OSs native controls. I bet most naïve (and native) Cocoa/Win32 app will give you 100x better keyboard navigation than most Electron apps from large companies.

mwcampbell 6y ago
> I bet most naïve (and native) Cocoa/Win32 app will give you 100x better keyboard navigation than most Electron apps from large companies. That may be true for Cocoa, but it actually isn't for Win32. It takes work to make keyboard navigation work correctly in Win32, unless you're using a dialog with nothing but standard controls (note: dialog means something specific in Win32). Windows Forms helps with this. Also, as soon as you depart from the stock Win32 controls, you have to implement the UI Automation accessibility API entirely on your own, and that's not an easy task even for a single custom control. So there are actually good reasons why Win32 isn't a good choice for new projects. There's another reason why web applications tend to be more navigable with third-party Windows screen readers than native applications. For the mainstream web rendering engines, third-party screen readers enable a sort of virtual cursor that let's the user navigate the DOM in a linear way by pressing the up and down arrow keys. This makes it straightforward to navigate to anything in the document, even if the application itself doesn't implement keyboard navigation. Now, this same navigation model could just as well be applied to native applications, and the Narrator screen reader built into Windows actually does offer that option. The fact that third-party screen readers restrict that option to web content is arguably a deficiency, but one that developers who care about accessibility should consider when targeting Windows today. Disclosure: I work for Microsoft on the Windows accessibility team, primarily on UI Automation and Narrator. These are my own opinions though.

flohofwoe 6y ago

IMHO these are unrelated problems. There's nothing preventing those 'handmade' libraries from using memory-safe languages and development practices, or calling into accessibility APIs provided by operating systems (assuming they are provided by operating systems), and on the other hand, Electron is the opposite of the 'handmade philosophy', but is still not accessible. There's required complexity, and unnecessary complexity, and the latter is the worse problem in modern 'industrial' software by far, because industrial software isn't developed by customers needs, but by business needs, and the gap between what customers want and what the industry provides seems to widen more and more each year. This 'industrial software development' that doesn't serve the user anymore is what the handmade philosophy is providing an alternative to.

mwcampbell 6y ago
> Electron is the opposite of the 'handmade philosophy', but is still not accessible. On the contrary, Chromium probably has the single most mature and robust implementation of accessibility APIs across platforms. It's true that not all Electron apps are accessible, but it's way easier to make an Electron app accessible than to make a handmade GUI accessible.
- flohofwoe 6y ago
  Yeah, ok, but the problem is the same: even though accessibility APIs might be provided (this time by Electron, not the OS), applications don't make use of them.
  - mwcampbell 6y ago
    Sure, we still have to fight that uphill battle. But it's way easier for a web application to implement ARIA than for a Win32 application with a custom control to implement UI Automation. Maybe that problem is unique to Windows.
    - deleted 6y ago
      [deleted]

vmchale 6y ago

> If you use a garbage collector, you don't have to do manual memory management Also easy higher-order functions. Plus it can be more performant in some cases. > I will happily shelve a few more bucks for RAM and wait a few more seconds I have 64GB on my desktop (happily!) but waiting is a bit of a pain! And it's often for silly reasons.

gameswithgo 6y ago

>If you go the handcrafted, lightweight and fast route, you're sacrificing a lot of features, possibly without even being aware of what you lose until it's too late. Some modern languages offer memory safety and very very high performance ceilings as well, if you are willing to learn how and work at. Examples include, C#, Rust, F#, and Nim. There are others! And any language, taking some time to understand performance pitfalls, and leveraging the language the best you can, can make a huge difference. Sometimes without any major maintenance or dev time penalty. It just takes caring, and practice.

fulafel 6y ago

The linked manifesto doesn't seem to be especially against garbage collection. And on their web site the latest news item is a "Lisp Jam"... The only reference to GC is in this sentencs: "The deadline is approaching or the rent is due or we have taxes to fill out and a manager on our back and someone asking us why we always spend so much time at the office, and we just have to stick the library or virtual machine or garbage collector in there to cover up the places we can't think through right now. " The situation is kind of choosing-shame-but-ending-up-in-war outcome[1] and is not saying that the referenced techniques (incl gc) would be generally bad. [1] https://richardlangworth.com/war-shame https://richardlangworth.com/war-shame

peacefulhat 6y ago

So bizarre to claim Messenger is secure because it was written in Javascript.

Olreich 6y ago

Doesn’t the ImGUI UI library have pretty good accessibility now without sacrificing on memory consumption and performance? JavaScript is difficult to program in a safe way, so I’m going to assume the Messenger app is written in something safer too.