Hacker News new | comments | ask | show | jobs | submit login
Introducing Electron Fiddle (medium.com)
165 points by rmason 6 months ago | hide | past | web | favorite | 67 comments

I downloaded this and it looks very interesting. But I'm unable to use it because of the dark theme.

I'm sorry, it's my fault, at the age of 66 I have visual limitations that make dark themes very uncomfortable. I just wish developers would not assume that everyone prefers or is able to use a dark theme. Not all of us can.

To really get comfortable with it, I would also want to be able to select a proportional font and tabs instead of two-space indents. But that can wait; a light theme option would be a good start.

> I'm sorry, it's my fault

I assume you're being sarcastic here. Accessibility issues like this are clearly the fault of an industry that hires mostly twenty-somethings with perfect vision, then doesn't train them in this important area.

And really, why does every app need its own theme or color scheme anyway? Sure, each company likes having its own brand. But do the users like this? I think that every app using the OS-supplied theme is good not just for accessibility, but for a consistent, distraction-free user experience. But then, I'm visually impaired myself, so that skews my perception, and I probably don't understand what the sighted masses like.

As I think about it, I think part of the problem is that so many young developers with no industry experience rush to start startups. How can they not keep repeating the same mistakes, including no regard for accessibility? They think they're doing a good thing by avoiding all the bureaucratic bullshit and moving fast. And indeed, accessibility often falls under "compliance" at big companies, which gives it that boring, bureaucratic feel. But it matters. People can lose their jobs, or at least be severely hampered in their productivity, when it's ignored.

Maybe we need to encourage young developers to spend some time at a mature software company before starting their own.

Edit: I made the same mistake myself. While I was still in college, I became sole developer for a tiny company that developed software for blind people. So I was obviously hyper-aware of accessibility for that user base. But I was ignorant of other important considerations, like internationalization, security, corporate manageability (working well with Windows Group Policy and the like), and even accessibility for other disabilities.

I don't think that's a reasonable comment. Any business first needs to address a marketplace that's enough to sustain itself and assure it's future existence. Beer chased men because more men drank, then when more woman started to drink it they started advertising to it.

While that's perhaps a different example due to one group not being actually excluded from something it shows how business behaves. Then you consider the risk of staying a startup to your future, your retirement, the funders cash/investment and honestly I'd you spent a dime on accessibility at this stage it would be reckless behavior.

Now having said that, once a product mix and the positive trajectory path has been established, then I don't think it's reasonable to delay, not even to say 'wait until we are profitable', because at that point you need to start addressing access to everyone equally as part of your business and if your business cannot sustain itself being inclusive then it's best to establish that earlier than later IMO.

Ps. I'm in no way poo pooing your point about the needing to be more training around accessibility, because ultimately that's part of the meat and potatoes of bring a dev. Like knowing SQL, JS, etc. All part of the basic skills we all need to survive most days at work. And accessibility is in the group. I'm only saying that a startup needs to first determine demand for it's product with the largest addressable group in it's core target audience, then branching out should immediately include accessibility IMO.

You actually have to pay money to subscribe to Unity3D Pro to get the dark color scheme -- it's disabled in the free version.

And people actually seem to care passionately about it, on both sides of the issue, for many different reasons!



I care passionately that my personal preferences about light/dark shouldn’t be forced on other people with different preferences.

And other people act like pixels are a zero sum game, so when one pixel lightens, another darkens. And then you have the extremely low contrast people who want to redistribute all the brightness.

I was doing a lot of Unity VR work a few years ago and was amused a few times when people saw that I was using their light theme and asked, "I thought you had Unity Pro?"

The funny thing about Unity's dark theme is that it is not only a dark theme, but it has much lower text vs. background contrast than their light theme. And the light theme is rather low contrast already.

Combined with their failure to support high-DPI displays, this led to a rather unpleasant experience. The only thing that made it palatable was that most of the time I was writing code in Visual Studio and not in the Unity Editor.

Thousands of users love dark themes. I’m eagerly awaiting the MacOS dark theme, I’ve hacked Slack to be dark and I run a Firefox extension that turns light colors dark grey and black text white (though I’d prefer an off-white with some red hue).

However, like the grandpa comment says- it’s an accessibility issue. There ought to be both or have option to customize the primary, secondary, accent, background, and text colors.

> Thousands of users love dark themes.

Definitely. I wonder if the whole problem here is that macOS took so long to get one, so developers have taken it upon themselves to do their own, and then some assumed that everybody wants a dark theme.

I would like to know why dark themed apps have become so popular? I'm 30 and use black on white themes whenever possible, only exception being when there are no other light sources, like reading from bed.

I don't want a single photon of light that isn't carrying information to reach my eyes.

That's like saying "I am only interested in the one bits. They carry information, unlike the zero bits which signify nothing."

There is no fundamental difference between one bits and zero bits. This should be self-evident to any programmer. After all, you can apply a "not" function to any binary string to turn it into another string with all the bits reversed.

Light pixels and dark pixels each convey the same amount of information. Light themes vs. dark themes is not a question of which one lets photons carry more information, it's the same information either way.

The real difference is how our far-from-perfect human eyes perceive them.

You're telling me there's no difference between light and the absent of light barring our perception of them as though light isn't a physical phenomenon with measurable effects.

For an inverted color scheme (light information on a black background) on a display where black pixels don't emit light-- the only emissions your eyes have to take in are information.

Your digital logic analogy is sanitized. If the high logic level is at 10kV your equipment is going to have a hard time.

We're talking about staring into a light source, there's a difference in total energy your eyes have to absorb.

Maybe your argument is self-evident to any theorist, but it completely ignores the physical world.

I'd also add that when reading with reflected light (such as reading on paper), your eyes are going to be taking in the same amount of light regardless of where they look in your environment because you're just reading ambient light. Completely different than staring into a light source.

Try programming while looking through an LCD directly at the sun and have it display characters by darkening pixels of direct sunlight aimed at your retinae then tell me there's no difference between a lit pixel and a dark pixel.

Hey, there's no difference between a one bit and a zero bit, here's a great computer interface idea: Transmit binary data to the user with gamma rays. The only difference is in how their far from perfect human body experiences them.

Then you must hate typical dark themes.

There are two kinds of dark themes: low-contrast, washed-out dark themes that use various shades of greys, and high-contrast, white-on-black dark themes that are good for people with poor eyesight or poor quality hardware, and for use in an actually dark environment.

Naturally there are things in between the two, but by and large there’s a pretty clear division between the two and which is provided, and the latter are pretty rare.

I actually do, especially on my OLED laptop screen and phone. The backgrounds are often these dark but not black grays that just lower the contrast of the content for no reason. Chrome and Firefox have these reader modes that don't give a true black background, it's just so wasteful.

I still prefer those themes to black-on-light but I do not love them.

VSCode, Sublime, Atom, many editors and IDE comes by default with a dark theme a enabled, or at least available.

They’re supposed to reduce eye strain, but personally I’ve never experienced eye strain from any colour scheme, and suspect it has more to do with the eyesight of the user than the colours involved.

Staring into a bright screen in a poorly lit room is eye strain. The pupil is dilated because the room is almost dark so more of the light from the bright screen will hit the retina.

Blacking out the screen in those conditions reduces that strain. But you still have to maintain a good brightness and contrast between the elements otherwise you trade one issue for another.

There's no one size fits all unfortunately. Which is why it's great when developers allow for customization.

> Staring into a bright screen in a poorly lit room is eye strain.

That's a really good point.

If I have to use a computer or phone under poor lighting, I turn down the display brightness to match.

Otherwise, I prefer to be in a space where I can read something written on paper. And then I adjust the brightness to match that - not cranked up too bright like I see sometimes.

Personally I can work 16 hours with white theme but even 1-2 hours with strictly dark theme is borderline unbearable. I tried it multiple times due to posts advertising it's lower eye strain. I'm 30 and myopic, -4 in both eyes, using PCs for decades.

Opening a white window is like a full headlight in my eyes. Many scientific studies said that blue led (and then white RGB pixels) deteriorate the sight over time, by destructing photosensors in the eyes and they never recover. I would encourage black themes in all apps.

Apparently my direct experience gets downvotes. I literally use light themed apps in low light conditions every day and have never experienced any discomfort that could be called eye strain. For at least some set of people it simply does not exist. I therefore put the variance down to the individual’s vision.

Does dark theme also consume less energy and extend battery life?

I think it would largely depend on the display technology. I know for some technologies a black pixel uses nearly no energy, but for others, all pixels are equally 'lit' by the same backlight.

For OLED displays, black uses (almost?) no energy. For LCD displays, black uses more energy, since the pixel has to be energized to block out the backlight. The difference is negligible, though, since the backlight uses far more.

Outdoors at night, it makes you less of a target for moths, mosquitos and Predator drones.

I don’t think there is any reason to apologise, those of us without visual impairments can easily overlook accessibility. I’m glad you pointed it out, hopefully developers of dark theme only products take this on board.

I feel your pain, from the other side. I find non-dark themed apps very hard to use due to my astigmatism and the resulting chromatic aberration (especially for blues) from the glasses. The onset of presbyopia of course doesn't help.

Having dark and light themes, and high contrast ones at that, are a huge help for me. I am using the "MiniHack" app on an iPad now in its dark theme, but it is dark gray instead of a solid black background.

The ability to change colors also helps. I removed all pure blues from my IDEs/editors, for example. (JetBrains, VIM and Emacs are fortunately all highly configurable.)

Hey! Author here. I got to admit, that’s an angle I did not fully consider - but adding theming should be fairly easy, given that our editor already has built-in themes.

I’ll put that on my personal to-do list (unless someone sends us a Pr first)!

>I'm sorry, it's my fault, at the age of 66 I have visual limitations that make dark themes very uncomfortable.

I have been wondering why I longed for Dark Theme when I was young, and now twenty to thirty years later when Dark Theme in general finally arrived. I hate it.

I think the age and eyes strain explains a lot. I used to do font 8 or font 9 with all interface, code or web page. Everything is too large and it is like waste of space. Now I just wish everything has a 120% DPI scaling.

Far from ideal, but if you really want to give it a try you can use the accessibility features on your OS. If you're using a Mac you can go to preferences, accessibility, display, and tick invert colors. Grayscale is also good.

I recently used this feature in a flight for the opposite situation. I was trying to learn go in the go playground but their editor only offers a light theme. After a couple of hours my eyes got tired and I was able to continue thanks to this accessibility feature.

That's a very legit concern that doesn't just affect the old. Many of us who are relatively young with certain level of astigmatism have halation / fuzzing when using dark schemes.

I understand why some users prefer the dark theme, but I never knew that some users can't use them.

Can you elaborate on what you experience, and why a lighter theme is necessary for it to be comfortable?

Sure thing, I should have explained in my first comment.

I have two problems with dark themes. One is that much of what I do on my computer will have light themes - websites, GIS software, Word and Excel, PDF documents, etc. It's hard on my eyes to switch back and forth between these and a dark themed editor - like walking in and out of a dark theater on a sunny day, over and over again.

The other problem has to do with eye focus. The irises in your eyes stop down or open up to adjust for light or dark. Just like a camera lens, stopping down (reducing the aperture) can help with focus. A perfect lens can focus sharply at any aperture; a less perfect lens will focus better if you stop it down.

Here are some interesting discussions on the topic:


Dark themes are indeed harder on my eyes, in any environment - daylight, evening, or complete darkness. I have myopia, -4 and astigmatism.

With dark theme it feels like I have to constantly strain to discern letters while with white theme there is no such feeling. It's like several additional dioptres added to your vision.

I use shells/terminals with dark theme but I change them from gray/green/yellow on black to 255 bright white on black and increase fonts by 2-3 points compared to regular text, then it kinda works and OS overall has white theme on other monitors at the same time.

Thanks for saying this. I'll keep this in mind during my future project (both personal and work). :)

Interesting. But what I think makes; jsFiddle, Glitch and CodePen so popular, is that you can go to any computer with a browser and run the code, without installing an environment.

To run this on any machine you would need to download the Electron Fiddle environment and compile the Electron app binary every time... Very similar to normal development.

So maybe electron just isn't as convenient for developing, compared to the browser technologies that the article compares it to...

I tend to disagree here. I think a few major things Electron Fiddle will bring to the table are:

  - the ability to easily get Electron help on StackOverflow, etc. by sharing the exact code you're running
  - one click (or close to it) examples of every single Electron API (I often find examples jsfiddles to be a much faster way to learn how to use a new API than digging through documentation)
  - possibly making it easier for people who are new to coding to get their feet wet in programming a desktop app without having to open a terminal. This is especially true if they can start with a working app and just tweak small things and see their tweaks reflected in the running app. 
All people are different, of course, but my biggest use cases of jsfiddle are using examples to learn how to use new frameworks. I’m excited to see the same thing for Electron apps!

Readable version of your bullet points:

- the ability to easily get Electron help on StackOverflow, etc. by sharing the exact code you're running

- one click (or close to it) examples of every single Electron API (I often find examples jsfiddles to be a much faster way to learn how to use a new API than digging through documentation)

- possibly making it easier for people who are new to coding to get their feet wet in programming a desktop app without having to open a terminal. This is especially true if they can start with a working app and just tweak small things and see their tweaks reflected in the running app.

(Don't use two space indents to force code style except for code samples.)

Thanks for pasting it as normal text. Code style for textual content is especially bad on mobile.

Yes those are some good points. I guess my main problem is that it claims to be similar to JS Fiddle, when really it's closer to an IDE.

For example take the IntelliJ IDE;

- It's cross platform

- Can run apps straight from stackoverflow

- Present configurations, so people can focus on coding rather than tweaking.

Electron Fiddle is basically the same thing, to me it would be more appropriate to call this Electron IDE. I'm still impressed and believe it will be a useful tool, though.

Electron is a lot more convenient than a browser as soon as you want to access resources on the computer. Browsers are really good keeping you locked into a sand box.

Where "resources" includes APIs and native code libraries, not just files and hardware and stuff!

> Over the past four years, I have introduced thousands of developers to Electron.

Then stop it!

I see that Electron v3.0.0-beta.4 is available.

What's new in Electron version 3, and how stable is it? Is there a good higher level summary than the release notes, and could somebody please describe what are the significant differences between version 2 and version 3, and how far along and mature is version 3?

Took me a few seconds longer to find it than I expected:


Several hundred megabytes for not-even-an-IDE is certainly not the world's tiniest open-source violin.

It does so thanks to electron-forge, allowing you to package your Fiddle as an app for Windows, macOS, or Linux.

How useful is this feature? I mostly do webdevelopment though.

Great, another way to create huge, slow, bloated "native" apps.

It confuses me that slack, with their hundreds of developers, cannot build a native piece of software that doesn't require 10+ seconds to init.

The project, minus the blogspam: https://github.com/electron/fiddle

How is that “blog spam” if it’s the original source? Blog spam is if someone writes an article about another source to get traffic instead of the original source imo.

The content isn't the spam. The decoration around it is (aka the medium platform).

I don't particularly like Medium either, but deciding that articles should be ignored because of the author's choice of hosting platform is silly, as long as it's not behind a paywall or login wall (e.g. Facebook). If the content can stand on it's own, who cares how it's hosted?

Yeah, but Medium is bringing the login wall to my face and asking me, in an (IMO) obnoxious way, to pass to the other side of the wall, again and again.

No biggie, I guess, but it adds up.

Everything on Medium is the epitome of blog spam. They're worse than Blogspot these days. The GitHub link is the true original source. The (PARDON THE INTERRUPTION!) Medium blurb is (PARDON THE INTERRUPTION!) just for (PARDON THE INTERRUPTION!) marketing and link juice, a.k.a spam.

May the gods save us from the day when the creators get the ability to market their products.

I'm sorry, what?

> Electron Fiddle is entirely open source and developed by a group of volunteers.

And even if it was paid product, what does bloat have to do with marketing?

What does marketing have to do with if it’s a free or paid product? Or if it’s from a company or two volunteers in a basement?

If you want people to adopt your open source code you have to do some marketing of some sorts. Otherwise it’s just another dead project on Github.

The problem is that the only reason to post on Medium today is for the clicks. As a blogging platform it has gone down the toilet, which is a shame because it started out with a rather promising reading experience.

That seems like a bold generalization. Just because there are blogs that do that doesn’t mean the whole platform should be disregarded. I really don’t like Medium but for a lot of people it’s simply a way to publish something without worrying about setting up something more advanced.

A lot of things submitted to HN are also for the clicks, doesn’t mean it’s a bad thing.

> for a lot of people it’s simply a way to publish something without worrying about setting up something more advanced.

I would appreciate this point if it wasn't for the fact that a lot of actual developers use this platform. It doesn't make sense for people knowledgeable about tech to not spend 10 minutes searching for a better blogging tool.

I've begun to subconsciously avoid any links to a medium post regardless of the content. I don't know if there are other people who do this, but it definitely is indicative of how bad the website has become.

Just because you’re a developer doesn’t mean you want to dick around with everything much less blogging. The stereotype is obnoxious.

Developers use Medium for the same reasons other people do.

I only suggested that developers should be more cognizant of web tools than the average internet user. The "stereotype" of tech people being more familiar with tech is true irregardless of how obnoxious you may find it.

Can you give me a legitimate reason why someone creating developer software finds medium easier than say something like github pages?

Apparently it wasn't terribly hard to publish the README on GitHub because he pushed that two days before this article. This article is just duplicate/spun content based on that. It exists for no reason other than to link to the GitHub page, which I did above for the benefit of anyone else who dislikes Medium as much as I do.

> Developers use Medium for the same reasons other people do.

Such as blogspam.

The platform should be disregarded because it's a rotten platform.

This particular article can further be disregarded because the GitHub project README is practically the same content without all the stuff that Medium does to be annoying.

There is a grammar error in the first sentence of the README...

> Electron Fiddle let's you create and play with small Electron experiments.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact