It (flash) democratized access to publishing creative works and designing media-rich websites on the internet. How is that a bad thing?

Did it? Could you use the tools to create these “flash sites” for free? Or did you need to pirate them? I honestly don’t remember if you had to pay for these tools.

I spent a lot of time on Newgrounds when I was younger creating and consuming content. Without Flash, sites like Newgrounds couldn’t have existed.

Well, flash is/was apparently great for art projects, nothing wrong with that! The problem with flash was that it was used in many places which forced you to install it to do “important” things where the use of flash was neither needed, nor appropriate.

Did it? Could you use the tools to create these “flash sites” for free? Or did you need to pirate them? I honestly don’t remember if you had to pay for these tools.

Macromedia Flash, Shockwave, and Dreamweaver cost money. I think it was hundreds of dollars in total. Everyone pirated them. (Checks statute of limitations.) I grabbed all three, too, with Dreamweaver a great tool for websites. I’m sure some paid for them but the piracy rate was so high I’d really love to know the paid-vs-pirate ratio of all that content author refers to.

Note: I also had Formula Graphics Multimedia. Very powerful tool. Flash was simpler, though, with a web plugin, too. That’s why it won over powerful competitors. Well, memory is hazy on whether other one had web plugin. It did have a ton of functionality, though.

“The problem with flash was that it was used in many places which forced you to install it to do “important” things where the use of flash was neither needed, nor appropriate.”

That is indeed the problem. I even encountered it recently on sites of major companies I use. It’s always trying to load or crash in the background. They at least have a redirect that lets me keep NoScript on. :)

I see where you’re going but can only half agree. You basically just described Frontpage tool that laypeople learned in school left and right. Dreamweaver took more investment due to higher complexity. I did use it since I was still learning web sites. However, the templating and WYSIWYG editor saved me plenty of time vs hand-coding things. And I still got the HTML in one click to add my stuff from dynamicdrive.com.

For stuff appealing to programmers, Allaire ColdFusion comes to mind given it combined HTML style with integrated app and DB functionality. It was interesting. I extended my homebrew 4GL to synthesize basic forms like LISP web does. Overall, I was doing client-server native without enough interest to invest in Web. I didnt do much more than using Dreamweaver for some web sites with CGI and Perl.

I think TFA means that it “democratized” in the sense of reducing the amount of technology knowledge that people had to invest in order to make things happen. “Things I need to learn before I can get started” can be as much of a barrier to entry as “money I need to pay before I can get started”.

Yeah, npm isn’t so good, that’s why Facebook came up with Yarn, which seems to solve a lot of the shortcomings of npm. We’re transitioning to it at my company and its working great. With npm, we intermittently saw builds fail because of non-deterministic package resolution, which yarn solved.

It’s hard to argue with you. You’re right, but I feel there’s maybe a bit of nuance here.

In the case of Air, one vuln definitely takes out all of the Air apps on the system. A vuln in Chrome / Electron, is likely targetting one specific version, or a small range of them. In the event all Electron apps have a slightly different version, you might actually get lucky from time to time!

A vuln in Chrome / Electron, is likely targetting one specific version, or a small range of them. In the event all Electron apps have a slightly different version, you might actually get lucky from time to time!

Unfortunately life shows it’s the other way around.

Take the recent Linux remote UDP vulnerability as a perfect depiction of what usually happens.

You have a ton of systems, devices shipping a different version of the Linux kernel

The situation you are depicting would only work if every security flaw was contained to a single version of the bundled runtime - in reality it’s more likely that it will impact a range of versions and bundled software is less likely to receive security updates.

The only thing that changes is having to patch each and every copy of the runtime in case of a security issue instead of patching the single system wide shared runtime.

Between the time the patch is identified, fixed, and release there is a window of non-zero time. An active maintainer can reduce this time, but in many cases, the user isn’t forced to update, nor is this time 0. Even worse is if the vuln is actively exploited before being disclosed.

It’s bad anyway you look at it. Maybe the Electron model is worse because the number of different versions possible for the runtime increases the likelihood of one being vulnerable. But maybe, just maybe, the track record of Adobe is so bad that the chances of Air having vulnerabilities far exceeds the likelihood of Chrome having vulnerabilities, even when many different versions are installed on the system?

So, if you judge the apps in terms of the native Apple ecosystem, sure, I’m with you. But at least for me there is a sense of Good Enough and spotify for me personally at least is Good Enough. I can play my music, I can browse music my friends are listening to, I can enjoy the myriad playlists Spotify and my friends create. It Is Good Enough.

Totally agree. However this is a case where in an ideal world, everyone would develop native clients for every platform and life would be grand.

But, in the real world, every development man hour has to be justified to the bean counters, and for my needs, I would much MUCH rather have a Good Enough client that runs on my Mac, my Linux desktop, my phone, my FireTV, etc etc etc than a deliciously smooth native client that’s Windows only and to heck with everyone else :)

Well yeah, but for someone huge like Spotify, Slack, Github and so on, I don’t think it’s justified at all. And I’d rather use something else. Only problem is that apples native music player is even worse in this particular case :p

I feel like there’s a huge difference between technologies like that being used for mostly games and art of which I usually view one at a time, or whether they’re used for “productive” software that I sometimes have to run as daemon in the background.

In contrast to Electron, Flash was rarely used to render full GUIs of desktop apps, and whenever it happened it was a similar disaster as Electron is now.

My comparison between Flash/Electron was meant to capture both technologies in a positive light by taking a more holistic view. We can all agree that both platforms have many issues. My opinion is that, while Electron has it’s problems, it’s still pushing the industry forward as a whole. Will the existence of Electron spur the creation of newer cross-platform frameworks that are less resource intensive while remaining extremely easy to use and get started with?

I don’t think Electron is perfect, but I do think it’s still a good (and necessary) step in the evolution of cross-platform software development.

I argue that these imperfect stages are actually needed for the evolution in this area as a whole. And for that reason, I believe Electron is a great thing (just as flash was).

Will the existence of Electron spur the creation of newer cross-platform frameworks

One of the problems is that these cross-platform frameworks do not benefit me as a user of a fairly mainstream platform on the desktop (macOS). Most software vendors care about macOS, so they will provide a version for macOS. However, where they used to write a Carbon and later Cocoa application, they now write an electron application to tick off that platform. For me, as a macOS user, it is a terrible regression. Even if we do not take the problems of Electron into account (memory use and CPU use), these applications do not integrate in the native look & feel. They look out of place, but even worse, there is virtually no platform integration (keyboard shortcuts, macOS services, integration with other Mac applications, AppleScript support, etc.). I stopped installing applications that use Electron, just because their experience frustrates me (besides eating a lot of memory and killing my battery).

The argument of the Electron crowd is that eventually cross-platform frameworks will integrate better. Unfortunately, history has shown that it will never get that far. Even with the gold standard of cross-platform frameworks (Qt), you typically notice that you are not using a native application (on macOS and Windows). Usually cross-platform frameworks will end up at the lowest common denominator of the platforms that they support.

Another question is why Electron is reinventing the wheel? Qt et al. are miles ahead as a cross-platform framework and does not require a fully embedded browser (though you can do so). Are some people so allergic to anything that is not Javascript + DOM that they’d forgo having somewhat reasonable resource use and better (but not perfect) platform integration?

(Edit: I do understand that there are (perceived) economic incentives using Electron above native apps.)

Correct. The crux of the matter is the fact that the statement, “native apps are hard!” seems to go completely unchallenged, especially in JS land.

The reason it bugs me is that it’s used to justify all manner of things that challenge and broaden one’s horizons, including FP, static typing, testing, etc. I’m sick of hearing “it’s hard!” from seemingly the same crowd that loves to write on Medium about how launching a startup is so hard but they have learned so much on their incredible journey.

Bring back the intellectualism in programming. If you don’t know something, then accept that in humility and put it on the to-do list of things to learn. I’m not asking for people to buy into any of that aforementioned stuff wholesale, just stop being so proud of not knowing it, okay?

Edit: it’s amusing that “RTFM” is considered profane, but the culture it reflected felt like one where putting the time in to study mattered, and that such study was expected of you. What we have now is…quite different.

The crux of the matter is the fact that the statement, “native apps are hard!” seems to go completely unchallenged, especially in JS land.

Native apps may require you to develop environment-specific code, but the code you develop is far simpler than equivalent JS/DOM-driven UIs. Anybody who says, “Web UI is easy,” is a lunatic, or knows nothing but web development.

Even if we do not take the problems of Electron into account (memory use and CPU use), these applications do not integrate in the native look & feel. They look out of place, but even worse, there is virtually no platform integration (keyboard shortcuts, macOS services, integration with other Mac applications, AppleScript support, etc.).

I agree it’s even worse for Electron apps (though the ones I use do at least have the common macOS keyboard shortcuts). But I think companies, including Apple, care less and less about a particularly coherent UI these days in general. Even native macOS apps don’t strongly conform to any one coherent UI convention, as mac apps used to in the days of ye olde Human Interface Guidelines. Photoshop, for example, looks nothing like a macOS app, even though it’s native. Even Apple first-party apps, though not diverging as extremely as Photoshop, are no longer all that consistent: Pages, XCode, Safari, and iTunes are kind of all over the map in their UI design.

I don’t know that electron is pushing the industry forward. What’s your evidence there? That there are more desktop applications now than there previously were? Is that an advantage when they’re just a web browser frame around a web app?

Does it lower development time for someone who already has a web app and wants to say “look, we have a desktop app too”, absolutely. But I don’t think on the whole that’s been a push forward for software development. If electron were something that could do that with native toolkits and native performance, I’d absolutely say that, but given that it’s essentially a web browser, minus the chrome. I don’t think that counts.

“Are you fucking kidding me?” is not an argument. A couple of the most creative people I know got their start on Newgrounds and are now making great art, in a way that maybe wouldn’t’ve happened without Flash.

I find myself agreeing with the author mostly. Electron and Javascript may have problems, but who else is working on current-generation technology for cross-platform desktop applications? Has there been anything else new on that front in the last decade? It may be fun to rant about how much of a memory hog it is, but please let us know when there’s something better for making a desktop app that works reliably on Mac, Windows, and Linux. This especially applies if you primarily have a web app and want to make a desktop app that broadly does the same thing. Would you rather tweak your Javascript codebase a bit and have an app for every platform, or build a new app and UI from scratch for Windows/C#, MacOS in Cocoa, plus Linux in C++ probably, and maintain all of those codebases in different languages and frameworks for the life of your business?

The only solution I’ve found for writing cross-platform native-feeling desktop apps is Racket. It has excellent tooling, compiles to a very small distributable, and has very low memory requirements. However, it’s been around a lot longer than a decade, so I guess the answer is technically no.

The main issue here is that you cannot share the business logic of your application between a web application and a “native” app.

I think a good approach to create a cross platform application, instead of thinking rewriting a whole application in a new cross platform technology, is to create a shared library handling your pure business code (ie. no IO stuff) shared across multiple applications handling all the IO fuzz. This way, each application can truly integrate within the target ecosystem without duplicating your application’s core codebase.

Web apps/javascript platforms are something relatively new (in regard of computer history) and have not been created with interoperability in mind. As it is today, you cannot easily import a library directly from your javascript code.

You still can hack around these limitations by transpiling your code, but let’s face it, this is a hack.

I am quite hopeful that something like web assembly will solve this problem.

With Electron, we’re seeing a similar explosion of new desktop software. The lower barrier to entry into creating cross platform desktop software far outweighs the detriment of computer resource usage.

But, pray tell, why are lower barriers to entry automatically a good thing? Do we need more software, or better software?