Inkscape 1.0 Beta 1 - <AUTHOR> https://inkscape.org/news/2019/09/08/inkscape-10-beta1-available-testing/ <comment><USER2> Inkscape is my go-to example of why FLOSS is great:

* Learn how to use it once

      * Keep using it for a life time

      * Not completely changing interface every major release

* Keeps getting better (some commercial software seems to bloat beyond repair)

* Available on many platforms

* All of the above for FREE

Now I dont need to do vector graphics every week, not even every month. But for those couple of times a year it's good to have a tool in your box. Inkscape is there for me, no need to buy a (subscription) license. No need to boot into another OS. No need to relearn it. More than complete feature set for my needs.

Congrats to the team!

<comment><USER3> Unfortunately, this 'not completely changing interface' has a side effect: it fails to evolve and become better.

I am a long-time user of Inkscape (since 2007 at least), and it is sad how poor it looks now next to Sketch/Figma. Their vector tools are better, their layer tools are better. It's a million little things that make drawing a similar shape in Sketch 50x faster than in Inkscape.

<comment><USER4> It doesn't need to be any better to satisfy this user. I also pull it out 2-4 times a year and am happy that everything has more or less stayed the same for 8+ years.

<comment><USER2> That was my point. Sure it could be better, but at a cost (design+dev'p, and alienation of users). It seems big/commercial softwares love to take that cost.

<comment><USER5> Because they have paying and active customers who want improvements even if it means that one has to relearn some things here and there.

Not enhancing UX because some users might have already gotten used to the current setup is rather shortsighted (relevant XKCD: [https://xkcd.com/1172/](https://xkcd.com/1172/) ). What about all the people you don't get on board because the UX is terrible compared to all the other tools?

<comment><USER6> > they have paying and active customers who want improvements

My experience is that when software reaches a certain level of maturity, major 'improvements' to the UI are driven very much not by the users.

> Not enhancing UX because some users might have already gotten used to the > current setup is rather shortsighted

Perhaps. It depends proportion of 'some'. 1%..99%, it depends doesn't it. You're pushing for change with no quantification of the value of it. If it ain't broke, don't fix it, so first find out if it's broke.

</comment></comment></comment></comment></comment></comment><comment><USER7> Inkscape is my go to image editor. The UI is reminiscent of the old Macromedia Fireworks, with a paradigm that feels much nicer (to me) than Photoshop et al.

I downloaded the beta pessimistically thinking that they still wouldn't have native OSX Menu support (I've been using the non-updated 0.91+devel+osmenu fork/branch forever), but was pleasantly surprised to see full OSX integration in this beta. Great job guys!

<comment><USER8> I'm used to Affinity Designer, unfortunately Inkscape is very slow for even just ~10 layers of medium complexity shapes on MacOS :-/

While on Affinity, I can have hundred layers without noticeable performance issues.

<comment><USER9> I'm not on MacOS but find Inkscape pretty snappy in general, even with big projects.

Perhaps it's not the Layers but the effects? Blur in particular is pretty slow. Have you tried reducing the displayed filter quality? This doesn't effect the image itself, only the display in Inkscape. It's in the render tab in Inkscape preferences.

At View -> Display Mode you can also toggle between full display, display without filters and only outlines. If Inkscape is significantly faster without displayed filters, setting down the display quality will definitely help.

<comment><USER10> The very first item on Affinity Designer's feature list [1] is "Pan and zoom at 60fps". You don't generally accomplish this by accident. They apparently wrote the engine from scratch to use hardware acceleration, and be usable on an iPad with a very small amount of available RAM [2].

There's no reason blur, in particular, must necessarily be slow. Everybody (and their phone) has a GPU that's more than fast enough to do that in real- time. I wonder if the (cross-platform) interfaces that Inkscape are using on macOS aren't hardware accelerated. Or if it's using some syscall which is cheap on some platforms and expensive on others.

I haven't done any testing but I agree that Inkscape feels much slower than Affinity Designer.

[1]: [https://affinity.serif.com/en-us/designer/full-feature- list/](https://affinity.serif.com/en-us/designer/full-feature-list/) [2]: [https://forum.affinity.serif.com/index.php?/topic/18079-what...](https://forum.affinity.serif.com/index.php?/topic/18079-what- vector-rendering-engine-does-designer-use/)

<comment><USER11> I use Affinity Designer and Photo and they are very fast even at huge sizes (I do art). But they don't listen to user feedback or suggestions much if at all. AD/P can use OpenGL Vulcan or Metal (I use Metal) and it's amazingly fast for most operations. I also use Artrage 5 and it's abysmally slow probably not optimized for any platform either, probably not much different from Inkscape (though mostly bitmap drawing).

</comment></comment></comment></comment></comment><comment><USER12> In our startup we do all our website and web app mock up in inkscape. Even artwork for our physical banner and posters we do using inkscape, krita [1] and then use scribus [2] to generate print quality pdf's.

We are overall very pleased with it.

We were eagerly waiting for 1.0 to have a HiDPI support and native Mac application. They both are there besides a lot of other features.

Kudos to team to keep it alive and continuously improve it. Even though Adobe XD,sketch and figma are preferred tools for UI and UX design, we build our assets using inkscape. We got this inspiration from Taiga [3] project which has an open source design repository in svg and a completed single page app using angularjs based on those designs. It gave our team confidence we can do it.

The added advantage is the artwork developed using inkscape can directly be used as svg images in website and single page app and are responsive by default.

Once again thanks to inkscape team to keep it alive and improve continuously.

[1] [https://krita.org/en/](https://krita.org/en/)

[2] [https://www.scribus.net/](https://www.scribus.net/)

[3] [https://github.com/taigaio/taiga- design](https://github.com/taigaio/taiga-design)

<comment><USER13> > The added advantage is the artwork developed using inkscape can directly be > used as svg images in website and single page app

We had a lot of success cleaning Inkscape's svg output.

See here for solutions: [https://news.ycombinator.com/item?id=20680559](https://news.ycombinator.com/item?id=20680559)

I'm pretty happy with svgcleaner ([https://github.com/RazrFalcon/svgcleaner](https://github.com/RazrFalcon/svgcleaner))

</comment></comment><comment><USER14> Oh wow it's finally no longer using XQuartz! This is great!

<comment><USER15> I'm overly excited for this fact!! I've been an avid user of Inkscape for some time, but abandoned it because the UI was unbearable. So so so happy

<comment><USER16> link to the beta download page:

[https://inkscape.org/release/inkscape-1.0/?latest=1](https://inkscape.org/release/inkscape-1.0/?latest=1)

</comment></comment></comment><comment><USER17> My go-to graphics packages are still Gimp for raster / Inkscape for vector graphics.

Started using Inkscape in 2007 to illustrate a math paper, and been using it ever since whenever I needed to TeX something up.

<comment><USER18> Me too. I only recently came across TikZ which is an even more epic way to TeX up fancy diagrams (you "program" them). Still use inkscape for most stuff though.

<comment><USER19> You and GP wrote "[to] TeX up", is this a common idiom?

<comment><USER20> Yes? At least in some mathy/sciencey circles.

</comment></comment></comment></comment><comment><USER21> Slight aside, I don't see anything in the release notes about OCAL (Open ClipArt Library): is it still integrated?

Reason I'm asking is because there are links between the projects and OCAL has been offline since April [1].

OCAL doesn't seem to be coming back, their official line is they are handling a DDoS ... if it's no longer included I'd conclude that OCAL probably expired.

There was a death, of an associated dev, I believe.

1 - [https://alicious.com/openclipart-ddos- offline/](https://alicious.com/openclipart-ddos-offline/) my blog post on the issue.

<comment> jarek-foksa It looks like there is currently only one person in charge of OCAL and he works on it for free, which would explain why it takes so long to bring it back.

It's also sad to see that Pixabay has basically copied all assets from OpenClipart and republished them under a more restrictive license rather than try to cooperate and support them.

<comment><USER21> Which would be no problem if that was publicly given as a reason. There have been 2 promises for "we're just about done" to my recollection too. Moreover the people running it aren't responding to requests to put up the torrent files of the current library.

It's extremely bad public relations at best.

</comment></comment></comment><comment><USER22> I am looking forward to having one less Python 2 dependency. Inkscape 1.0 only uses Python 3.

Next up will be GIMP 3 as that will mean I no longer need GTK2 a dependency of unmaintained PyGTK.

PyGTK also depends on python2-cairo and python2-gobject2 so I will finally be rid of Python 2 once and for all.

</comment><comment><USER23> Inkscape is just totally awesome and very much needed. Without it the only serious option left for vector graphics is the overly expensive Illustrator, entering Adobe's sucking subscription model where you can only edit your own files when a subscription is paid.

Inkscape is another great example of why we should try to support open source if we can.

</comment><comment><USER24> Why does Inkscape's UI feel so... sloppy? I mean, Blender is a cross-platform, open-source design tool, and it manages to have a tight, professional looking UI. So how does Inkscape's UI still contrive to look like the first Java AWT application I wrote in the 90s?

I know it's just a surface thing, and there's a lot of great functionality there. But it's still not exactly a sight that helps inspire you to create beautiful content using it.

<comment><USER25> > Blender is a cross-platform, open-source design tool, and it manages to have > a tight, professional looking UI

Well let's remember that there was HEAVY criticism of Blender's UI up until the 2.5/2.6 releases, with some people even criticizing it now that 2.8 is released. There was an extreme amount of work done since 2.5 to clean up the UI.

It also has a lot more functionality than Inkscape, and so I think there is incentive as more people start using it to make sure that all those functions are filed away neatly and accessible without cluttering the interface too much.

Also, just going on users subscribed to their respective subreddits, Inkscape has around 6000 and Blender 151,000. So the size of the user base might have a direct impact.

Personally I don't find the Inkscape UI to be all that bad, although I agree it could do with some tightening up. I still prefer to use Adobe Illustrator if I have it to hand, but Inkscape will always work in a pinch.

Being able to use it to create SVG that can be directly imported into Blender as curves is something I've used it a lot for, for that kind of task they complement each other very well.

</comment></comment><comment><USER26> > Better HiDPI screen support

Oh finally! Haven't used it for the last two years simply because the interface was too tiny on my laptop.

<comment><USER27> huh, what OS are you on ? I have hidpi screens since 2014 and inscape has always honored Xft.dpi

<comment><USER28> Are you using Xorg or Wayland? When I looked into it last there were issues in Wayland when you set the Xft.dpi clashing with things like GDK_SCALE.

Like the GP I've hardly been using Inkscape recently as it's such a pain with the small icons.

<comment><USER27> I use X11, wayland has way too many issues for me at the moment (and I test sway, plasma and GNOME every other month)

</comment></comment></comment></comment><comment><USER29> Glad to read this. Never used inkscape beyond the CLI tools. I hope they continue to keep this chunk of their software mature and growing, too.

Here's my all-time favorite thing to do... transform font types to paths inside svgs (so one doesn't need to hold that font asset in CDN, ...) :

inkscape -T -A tmp-hack.pdf orig-w-custom-fonts.svg

inkscape -l final.svg tmp-hack.pdf

</comment><comment><USER30> So excited to try out the native mac os support, I use inkscape for everything but I often have to unplug my second monitor to get it to show up thanks to XQuartz!

</comment><comment><USER31> > Pinch-to-zoom

> On supported hardware (trackpad, touchpad, multi-touch screen), the canvas > can be zoomed with the two-finger pinch gesture.

Thank god! As a macOS user, this is really one of my pet peeves because I'm so used to pinch-to-zoom that I almost forget it exists until I use a program that _doesn 't_ support it.

</comment><comment><USER32> Inkscape is fantastic. I used it to convert a taster image to vector art and it exceeded my expectations.

</comment><comment><USER33> I hope a minor annoyance in the UI which has been nagging me has been fixed in the recent versions:

To draw lines with arrows, one needs to draw a line then select the arrow style, where as a the natural flow would be to set the style before drawing the line. Imagine if you have 20 lines of the same style, it is painful to draw 20 standard lines and then go back to change each of their appearance individually. It would be better if one could define a style of line, then create lines of that style as many number of times as required.

Having such stylesheets will for example change the width of all lines of the given style easily later.

</comment><comment><USER34> This is great news. Really a gem of an open-source/ free SVG editor that can produce high quality images.

Do they have "flatten-layers" and export as a single file (similar to Illustrator) functionality yet?

I checked the release notes, but could not find anything around it.

This can sometimes be an issue, in the way the image is rendered especially by different browsers. You end up with some unintended image output than you developed in the tool because of the interaction between different layers and opacities. Even a .png export did not help in one instance.

</comment><comment><USER35> One thing I still miss in inkscape is calligraphic strokes, which is very useful for creating a professional looking cartoon style.

EDIT: Calligraphy is available but only hand-drawn. What I meant is calligraphy applied to a path, and the ability to transform the resulting stroke back into a path. These are powerful operations that are available in commercial offerings but not yet in inkscape, afaik.

<comment><USER36> Are they patented?

</comment></comment><comment><USER37> That's a looong journey to reach 1.0 beta. Congrats to the team.

</comment><comment><USER38> I... love... inkscape... to those who work on it, thank you.

</comment><comment><USER39> Free is not free when said product results in reduction of productivity.

I've tried to make Inkscape work, after ending my Adobe subscription. Conclusion - Inkscape is not worth it.

Just pony up $50 for Affinity Designer. Great app. Facilitates tremendous productivity

<comment><USER40> Huh. My experience differs. I have both Illustrator and Inkscape, and for certain tasks (e.g. stuff I want to be native SVG or making icons), I always go back to Inkscape because I find it faster/easier.

</comment></comment><comment><USER41> As a Mac user looking to avoid Illustrator, this is a gift from the gods. XQuartz has issues with mouse movement, making it difficult to keep the drawing on the screen. Now it looks and acts like you'd expect.

</comment><comment><USER42> Inkscape is great. I don't want to be a dick but I miss Xara XL

</comment><comment><USER43> I don't know if they'll be able to get GTK 3 into 1.0, but that would be awesome. The fact that the new builds don't need a X server kind of make it awesome already!

</comment><comment><USER44> Inkscape is that one Open Source app where the UI isn't utter nonsense. Could be better but it's alright. Great to see it reaching 1.0.

</comment><comment><USER45> I wish it would have better color profile support, so that it can be used to send graphics straight to a printer. This seems like a basic thing but I could never get it to work. So now I have to use Scribus which has its own problems.

</comment><comment><USER46> Non-destructive boolean operations! This it so much easier to reuse shapes. Great for obscured features, surface details, shadows, reflections... Too bad they are hidden away in live effects; I will still (ab)use them to no end.

<comment><USER47> Yay! Always missing these since my main tool is parametric CAD background (FreeCAD). Using Inkscape is nice when output is more visual in nature.

</comment></comment><comment><USER48> Inkscape is still in beta? Yes, I _know_ it is, but I can't quite wrap my mind around it. Have been using this awe-inspiring tool for more than a quarter of my life. And I was born before the first human spaceflight.

</comment><comment><USER49> This is great news! Will check if they fixed the issues loading files with autoconnectors, which was the only thing preventing me to use it for engineering diagrams.

I just wish that Krita had the same text editing capabilities as Inkscape.

</comment><comment><USER50> I use Affinity Designer for vector work. However, Designer doesn't support tracing, so for that I'll fire up Inkscape. I'll do the trace, save it, then import into Designer and continue working.

</comment><comment><USER51> I can't stress enough how happy I'm because Inkscape is finally getting proper macOS support, I've been using the ~suv osxmenu build for years wondering which OS update would render it unusable

</comment><comment><USER52> `Ctrl + 4` to center view on page!

Pressure sensitive pencil for the PowerStroke Live Path Effect (LPE) "if a pressure sensitive device is available"!

</comment><comment><USER53> The performance is _really_ bad for me. It runs at like 2fps with an empty document.

I'm on a fairly powerful 5K iMac with High Sierra...

</comment><comment><USER54> What other free software is good for vector graphics? Is there only Inkscape?

</comment><comment><USER55> What is that list of changes relative to? I'm using 0.92.4 myself.

</comment><comment><USER56> Fantastic program.

</comment><comment><USER57> Please please please make an IOS version!

</comment><comment> jarek-foksa Just in case you are looking for a commercial alternative to Inkscape with a more modern UI and Chromium-based rendering engine, check out my project Boxy SVG: [https://boxy-svg.com](https://boxy-svg.com)

The next version (to be released in 2-3 weeks) is going to introduce full support for filters and color swatches. In the upcoming 12 months I expect to reach full feature parity with Inkscape.

<comment><USER58> I'm sad to say that I judged it purely on the fact that it wasn't open source.

Then I went ahead and tried it out... mind blown. It's that good. Feels like a native app in it's UI quality and speed. And $9/month is a very good price point, especially for those that regularly create vector art.

I'm amazed at the quality of your app. It'll be especially incredible once you're at Inkscape parity. How large is the team you got working full time?

<comment><USER59> Only $1080 over the next decade compared to zero for inkscape! You would probably be better off writing a check for $100 to fund improvements to same and put the other grand in your pocket.

Everyone on earth wants to turn a sale into a recurring revenue stream for a reason. Trivial individual costs add up substantially over time.

<comment> jarek-foksa Boxy SVG desktop app does not and will not require recurring payments. You pay for it once and after that you will be receiving updates for free as long as I'm in charge of the project (i.e. I won't get hit by a bus or something along those lines).

<comment><USER60> hey, you might wanna change your website a little bit then. it's not obvious right now.

i clicked on the link of your site, and the first box i saw said "9$/month". that's enough to click away (for me).

only after i did some more clicking and followed an external(!) link to the store it was obvious you can do a one-time purchase.

in a normal situation i would never have gotten to that point and would have clicked away immediately after seeing 9/month for a new product that still has to prove itself and doesn't have a big name behind it.

<comment><USER61> Yes, it's not at all clear. If you switch away from "Web app" by clicking on an OS, you don't get that (or any) pricing info. Going to the stores themselves, Windows and Mac seem to have a one-time payment, and Chrome and Snap don't seem to have a price.

</comment></comment></comment></comment></comment></comment><comment> marble-drink One thing I love about Inkscape is its keyboard interface and specifically how it lets you scroll up and down, left and right and in and out. This should be standard in all two-dimensional editing applications but I find it sadly is not. When it comes to editing speed, the keyboard is absolutely essential and shouldn't be an afterthought.</comment>


Ask HN: Which pdf form filler do you use? - <AUTHOR> When I search for "pdf form filler", I see many websites. I don't have time to audit their code. Some might be selling our data.<p>So, which pdf form filler should we use if we do not want our filled data to be leaked or sold. <comment><USER2> Do you mean as user filling the forms or as a developer writing software to fill the forms?

As a user, just use Acrobat or Preview.

As a developer, there are lots of options. Check out python pdf libraries. There is also a lot of work going into JS PDF libraries if you want to keep everything on the client.

Actually, this is one area where I'm excited about web assembly. There are so many native tools for working with pdf. Compiling those to wasm and running them on the client opens some really interesting posssibilities.

</comment><comment><USER3> OSX preview is the best pdf filler I have adobe acrobat too but prefer apple preview, way easier to use and less issues with created pdf files.

acrobat is nice occasionally for more complex stuff, but if I can do it in preview I use that.

</comment><comment><USER4> Yeah, if its programmatic PDF filling, it depends on your language/platform of choice (make a comment with that to get more relevant responses). For PHP I'd recommend TCPDF with FPDi.

</comment><comment><USER5> How about [https://pdfbox.apache.org/](https://pdfbox.apache.org/)</comment>


Bullet train contractors botched a bridge project - <AUTHOR> https://www.latimes.com/california/story/2020-08-10/california-bullet-train-bridge-snafu <comment><AUTHOR> A series of errors by contractors and consultants on the California bullet train venture caused support cables to fail on a massive bridge, triggering an order to stop work that further delayed a project already years behind schedule, the Los Angeles Times has learned</comment>


Show HN: Navigable Music Graph - <AUTHOR> https://theshfl.com/ <comment><AUTHOR> I posted this maybe 6 months ago, but it has changed a ton since then, and I'd really like some feedback, so I'm trying again.

I've built a large graph of album recommendations (mostly from music critics, but also from musicians and interesting lists I've found on the web) and made it navigable as a website. It's ultimately a big random sampler, but structured as a graph that can be explored in a lot of different ways. You can just sample from a particular music critic, for example, or from a music critic's jazz recommendations, or blues music from the 30's, new wave music from the 80's, just albums on the Warp label, just death metal, etc. I've basically tried to connect the albums in every way they could be connected (recorded year, people who recommended it, genre, label) and make it easy to just browse and explore. Most are linked to a streaming location, Spotify/Apple Music/Bandcamp etc so you can just try something out quickly. I built it in the first place just because I wanted something like it, but it really works better than I had anticipated and I think other people could get into it so I hope a few of you try it out. Any kind of feedback would be highly appreciated.</comment>


Ask HN: What daily-life design patterns do you use that could be productized? - <AUTHOR> <comment><USER2> Pomodoro, aka time-blocking, could be example

Inbox zero, aka clearing to neutral, is another

Daily checklists/standard operating procedures...

</comment><comment><AUTHOR> Daily-life design pattern, meaning a general idea or plan that can be applied across many things in life, thus simplifying a routine or otherwise enabling improvements.

An example might be, improving the parallization in the way a kitchen works can save a restaurant money or enable them to add new menu items.

Or an anti-pattern of checking HN while a build is going, could maybe be turned into a mini-focused-learning-or-relax-time by an app/service.

What else is there, where the main blocker is recognizing the generalizabily of a solution to multiple problems, that could be made to be sold?</comment>


In Defense of Electron - <AUTHOR> https://dev.to/bitario/in-defense-of-electron <comment><USER2> I read the business case section and... I got the rationale right up to the point where it says "You can just pass the cost down to your customers" and compared it to my feelings regarding delivering quality solutions.

Electron is a crutch. A crutch that people resort to because it's effectively impossible to write quick and dirty cross-platform desktop apps in anything else, but, worse still, a _debilitating_ crutch that, unless you know what you are doing (and I daresay that is something people should be looking into) delivers overly bloated, resource-guzzling apps that wreck usability, battery life and (most visibly) RAM in _any_ OS.

I don't have 16GB of RAM everywhere. Statistically, NOBODY does, in the sense that the average user (who is not, usually, a developer or a power user) is probably using a Windows PC with 4GB of RAM where a _single_ Electron app can take up over half of system resources.

And I find the initial premises laughable. Whenever I ran Slack on my 16GB MacBook Pro, battery life took a nosedive - visibly so. JavaFX apps like Nightcode are far more efficient (but I digress and am probably summoning a few trolls).

So no, I don't think Electron is defensible. It is _marginally_ defensible if you want to get an MVP out, or if your real desktop app is still in the works. Excusing it by saying it will cost you more to hire someone who knows how to do cross-platform development in something like Qt or Xamarin and deliver a more efficient, higher quality product is not an excuse, it's a cop-out.

<comment><USER3> So what's your answer to Visual Studio Code then?

I see Electron as opening up desktop development to developers who previously wouldn't have the been able to do it. Should we gatekeep just because developers don't have the resources to do a proper native app?

<comment><USER4> > So what's your answer to Visual Studio Code then?

Sublime Text, Kate, Notepad++ if you're looking for the same low learning curve or Vim/Emacs if you have experience or are willing to learn either.

Two days ago I finally snapped when I was refactoring a codebase that required me to have 4 VS Code windows open.

Together with my regular browser I was eating 12 GB of RAM and I had no VMs open as I often do. The system ran slow as dirt despite having an FX-8320 (not a new chip, but it's no slouch and it's still an 8-core), an SSD and 4 more GB of RAM to spare.

That's just downright unacceptable.

> I see Electron as opening up desktop development to developers who > previously wouldn't have the been able to do it. Should we gatekeep just > because developers don't have the resources to do a proper native app?

Excuse my french, but come the fuck on. I was 11 years old when I grabbed a copy of Visual Basic 6 because "I wanted to be a 1337 haxxor" and was able to drag and drop buttons and text inputs into an empty dotted window, bang them together a bit, copy paste some code from forums and have them working to some extent with no programming knowledge.

You're treating JavaScript programmers as if they're mentally deficient just because many of them are new to the industry and don't know tools that aren't fashionable. If they grabbed Qt Creator and QML docs they would be producing lightweight apps in no time.

<comment><USER5> And yet… they don't.

You could continue arguing against the mounting evidence that Qt apps simply don't perform as well in the marketplace as Electron apps seem to be doing, or you could accept that perhaps one of your assumptions is wrong.

Having used a few Electron apps on macOS, I'll offer a (mostly poorly- informed) opinion: Electron is the first cross-platform toolkit I've seen that has resulted in apps that don't _feel_ out-of-place like their other cross- platform brethren, the software version of the uncanny valley. Even VS Code, the first editor I've actually liked since the original TextMate, somehow doesn't feel out of place (despite being themed uniquely).

There was a list posted earlier of popular cross-platform Qt apps, and most of them (VLC, Google Earth, VirtualBox) share a common theme: they're effectively a thin UI around mostly non-Qt content. I'd be surprised if more than 5% of VLC's use isn't double-clicking a video, watching it, and closing the window (perhaps with some scrubbing around the content). Most of a user's interaction with VirtualBox is with the operating system inside of it. And Google Earth (isn't that dead?) has little toolkit-based UI inside of it, with most of the space reserved for flying around the planet's surface.

Don't you think it's telling that the most popular cross-platform Qt apps are the ones with the least amount of Qt UI?

On the other hand, popular Electron apps like VS Code and Slack are _almost entirely_ about interacting with the UI itself. In the brief window of time Electron has been out, it's resulted in more popular cross-platform apps of this vein than Qt has in the 25+ years of its existence.

"Are I out of touch? No, it's the other developers who are wrong!"

<comment><USER4> >You could continue arguing against the mounting evidence that Qt apps...

Let me stop you right there since from then on you're thinking with an incorrect assumption. I'm not talking about Qt Widgets; I'm talking about QML.

And I've already hinted at why we aren't seeing an explosion of QML apps: Electron is front-end development with desktop APIs. This is something JS developers already do. On top of that, it's currently _fashionable_. QML isn't.

It's easy to see why: QML has existed for a while, took some time to mature and it's not as good for making native _looking_ apps as other traditional toolkits, therefore it never enjoyed widespread popularity among desktop developers outside of KDE and embedded development (an area where you need performance but don't have an an established HIG to follow).

Therefore, it's normal for webdevs to not have even heard of QML or to confuse it with regular Qt widgets.

> "Are I out of touch? No, it's the other developers who are wrong!"

So before this post you didn't even know what QML is but already took the moral high ground to disregard me as grumpy grandpa.

> I'll offer a (mostly poorly-informed) opinion: Electron is the first cross- > platform toolkit I've seen that has resulted in apps that don't feel out-of- > place like their other cross-platform brethren

I hope you can see why I believe misinformation is the problem behind this epidemic. QML offers the exact same approach to theming, giving you simple primitives to create widgets of your own design without the need for an unholy mess of HTML, CSS and a JavaScript framework; just a tiny bit of QML in a file and you have your own component rendered on a 3D accelerated scene graph with the _option_ to add JavaScript for complex logic.

And I actually happen to have an example to back my words up.

Here: [https://github.com/grigio/borderless- camera](https://github.com/grigio/borderless-camera) is an Electron app the author posted on a programming subreddit a while ago. Take a look at the source code, build toolchain and so on; the usual.

I made this as a response to the criticism he got about the high resource consumption for a seemingly trivial app: [https://gitlab.com/mixedCase/qml- borderless-camera](https://gitlab.com/mixedCase/qml-borderless-camera) I invite you to take a look at the app.qml file. That is the entire source code.

<comment><USER5> > QML... is not as good for making native looking apps as other traditional > toolkits.

In disagreeing with me, somehow you've essentially re-argued my own thesis.

It's not just about looking as good (although that's certainly a component), it's also about acting like native apps. Electron apps for whatever reason, in my experience, don't have this problem. Slack _feels_ like a native app. VS Code _feels_ like a native app.

> So before this post you didn't even know what QML is but already took the > moral high ground to disregard me as grumpy grandpa.

I spoke to Qt, and QML is literally the "Qt Modeling Language". It renders elements using Qt Quick. I'm not entirely sure how switching the mechanism for defining your Qt interface from code to a markup language invalidates my point.

> And I actually happen to have an example to back my words up.

It's unbelievable to me that you responded to my post about how the most popular Qt apps are the one with the least Qt interface, with an example of a Qt app you wrote (using QML) that literally has no interface.

Qt apps haven't taken off because, while they may be easier for developers to build, they are _worse for users to use_ (by a metric I'm leaving poorly- defined for the simple reason that I lack a good definition). Easier to develop but worse for users is not a good selling proposition.

<comment><USER4> > it's also about acting like native apps. Slack feels like a native app. VS > Code feels like a native app.

I'm not sure if you're arguing as if this is powered by some sort of black box powered magic no one could understand?

Electron is just a website, the Node APIs and a couple of facilities from Gtk, like menus. You have access to these things or equivalents in QML. You would know this if you had bothered to learn what it actually is.

> I spoke to Qt, and QML is literally the "Qt Modeling Language". It renders > elements using Qt Quick. I'm not entirely sure how switching the mechanism > for defining your Qt interface from code to a markup language invalidates my > point.

You're literally searching for a couple of terms in Google half-guessing what some of the words mean and thinking you now understand Qt.

Qt is a big _set of libraries_.

 __Qt widgets __is a traditional widget toolkit that powers things like VLC, Google Earth and VirtualBox. It 's software-rendered and exclusively programmed through C++. It's a _subset_ of Qt.

 __QtQuick __is a _different_ subset, that is powered by a 3D-accelerated scenegraph, can be programmed from QML, JavaScript and C++ and has primitives both for native-like widgets (QtQuick Controls 1) and simpler, more performant primitives (QtQuick Controls 2) that allow you to do everything you can do in a website with the DOM and CSS.

You can mix and match subsets, which is part of the beauty of Qt, but each of those have completely different purposes.

> It's unbelievable to me that you responded to my post about how the most > popular Qt apps are the one with the least Qt interface, with an example of > a Qt app you wrote (using QML) that literally has no interface.

Fine. Have a VS Code prototype just for you, made in under an hour:

[https://i.imgur.com/RPr6VMS.png](https://i.imgur.com/RPr6VMS.png)

Some of it is functional, like tabs and menu. Sidebar and file tree is mere decoration waiting to be connected to logic. But there's your magical "native feel" interface in QML.

Ah, and if you were to actually complete the prototype, you could probably rip off the rich text editing component from the Kate text editor (written in Qt _widgets_ ) and still be able to use it from _QtQuick_. Meaning you get syntax coloring, auto complete and many other things for free, if you wanted to.

Here's the code: [https://gitlab.com/mixedCase/poc-qml- vscode](https://gitlab.com/mixedCase/poc-qml-vscode)

If you have the dependencies installed, you build it with qmake -o Makefile qml-vscode.pro && make

Enjoy.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> I think we too easily conflate Electron and apps based on Electron. If you take the Electron demo app, you won't notice it. It has no impact on your machine whatsoever. Plenty of Electron based apps though have abysmal performance and a negative impact on battery life etc. I've also come across a few that behave like proper citizens. A lot of what makes people frustrated with Electron based apps isn't actually caused by Electron, but what people have layered on top of it.

I think it was with Slack recently that someone noticed they actually ship the dev build of their JS code. Which would explain a thing or two about its performance and resource usage.

<comment><USER7> This. Atom kills my CPU fan, but VSCode is pretty quiet.

I also noticed that Slack was significantly more performant when I went from being on 5 different Slack teams to just one. Which suggests that there might be something related to how Slack handles background chat updates.

<comment><USER8> I never understood why to run Slack as desktop app if Slack can be run in a browser with the same GUI and features. Am I missing something?

</comment></comment></comment><comment><USER9> > Electron's dream world would be one where every computer user had a > luxurious amount of ram. But I think this world is fast approaching. Do we > wait till then to begin taking advantage of a plentiful world, or do we > start planning now?

While it's great to imagine this future world where everyone is running supercomputers, you ignore the overwhelming majority of potential users who aren't running "a 2016 MacBook with 16GB ram". For those not at the cutting edge, many Electron apps are painful to use.

To put it differently, not everyone replaces their computer every year. It may take a long time before everyone "catches up"

<comment><USER10> Yes, and they might be running "a 2011 MacBook with 4GM ram", like me :) I haven't had a compelling reason to upgrade, but apps like slack and atom are really trying to force it. Fortunately there are still apps that care about memory and performance (thank you, Sublime).

</comment></comment><comment><USER11> The entire defense/post boils down to this line:

"... I ought to be more concerned with where the trend in memory is going rather than where it has been."

The problem with this line of argument is that it never ends. Developers who accept this line of argument are always aiming five years down the road, and thus always delivering a poor or substandard experience to their current users.

Your future users are not real, and if you're always targeting future users you're never targeting real people.

<comment><USER12> It's kind of like "You go to war with the army you have"\- I mean, your code runs on computers people have, not the ones you wish they had.

<comment><USER13> But "the army you have" could also be the dev team you have..

<comment><USER14> It's usually easier to employ someone than to give each of your costumers a new computer though.

<comment><USER13> Sure, but my point is that if you just don't have the resources to develop natively, Electron may allow you to "go to war" when you otherwise couldn't.

</comment></comment></comment></comment></comment><comment><USER15> Ahhhhh yes. When people post claims about it's terrible performance they're concerned about how the computer _feels_.

/s

No. When it comes down to it. Electron hogs and drains a user's laptop battery, which in turn affects their user experience. How hard is that to understand?

Not everyone has a Macbook with decent battery life. Some people don't like Macs, don't like Apple, or simply can't afford one.

If you program with a concern for perform and battery life, it'll run well on a Mac as well as an old computer.

If you code lazily with Electron, some people will notice: a drop in battery life, and a slowing down of their computer's responsiveness.

It's pretty simple really. Code for the lowest common denominator of your target audience.

<comment><USER16> > If you code lazily with Electron [...] It's pretty simple really.

It has nothing to do with 'laziness'. You ignored the entire 'The Business Case' section of the article.

<comment><USER17> I think OP was implying that you could code in a non-lazy way while using electron. For example, a lazily coded app would use too many frameworks (e.g. jQuery + jQuery UI + angular 1, 3 http clients, 3 underscore forks) and bad coding practices (many memory leaks and unnecessary duplication, no optimization attempts, team never learned the language, shipping dev builds with extra debug tools to production). Maybe electron isn't as bad as the bad apples draw it down to be. Personally, I'm still interested in something like react native for desktop.

<comment><USER18>
       react native for desktop

We're all waiting for that silver bullet

<comment><USER19> There is this: [https://github.com/ptmt/react-native- macos](https://github.com/ptmt/react-native-macos)

<comment><USER20> And also this (cross-plat React Native for Windows/iOS/Android): [https://github.com/Microsoft/reactxp](https://github.com/Microsoft/reactxp)

</comment></comment></comment></comment></comment></comment><comment><USER21> The casual dismissal of the complaints from their customers really rubs me the wrong way. For sure, technical people know what Electron is and many have a bias against it. But the bias isn't irrational, it's driven by very real needs.

The author is right in that a non-technical person won't know what Electron is and when their computer becomes slow and hot or runs out of battery more quickly, they will not know where to lay the blame. They might think, as many members of my family love to tell me, that their computer battery is just "way too old" and "never lasts long", or that Windows "is so slow, is Linux any faster?"

I can run a couple of Electron applications and I do often. My office uses Slack, so I run that all the time. There are a couple others I need here and there and when they are all running at the same time, my laptop gets warm, the fan switches into high gear and soon I'm reaching for a power adapter. If I'm at an airport or traveling I can decide that I'm not running these applications and lengthen my battery life.

Electron is a compromise and I understand that. What I wouldn't be keen on is a situation where everything I do is an Electron app. Someone had a nice resource monitor that looked really neat, but it was an Electron application. I liked the look but I can't afford to add that application to my power/memory/CPU budget just 'cause it looks cool.

My point is this: I don't think it's a good idea to simply sweep away a segment of customer complaints because those customers happen to know what Electron is and notice the effects on their machines. As more Electron apps come to market, literally fewer will be able to share a customer's laptop or workstation. Atom and VS Code have already staked out some critical ground, their customers simply will not give them up. That leaves that much less room for other Electron apps and given the speed with which these apps are appearing, that space is going to be crowded and contentious.

</comment><comment><USER22>
      This would mean hiring a total of six experienced
      developers. Let's ignore the madenning tediousness of
      having to make every minor change six times on six
      different platforms, and focus instead on the costs.
      With an average salary of $150k (probably more for the
      hard to find like Mac developers), and ignoring the
      massive cost of finding and hiring these developers,
      that's a total of $900,000 in development costs every
      year.

Focusing on the first part: Why would you be making the same changes 6 times? Is your code so tightly coupled between logic and display that you haven't reduced the common features to, essentially, libraries at this point? Separation of concerns is not a novel concept.

And Mac developers _hard_ to find? From what I keep reading here, MacBook Pros are _the_ development machine to have. I can't imagine that it's so hard to find a Mac developer as this post suggests.

      As a one-person team deploying on all these platforms,
      even the most minor change will take at minimum three
      development days, one for each codebase.

If you're one, solitary, person, you aren't a team. Just like there's no army of one, despite the pervasive recruiting posters and videos years ago.

I'm glad Electron is letting you produce yet another note taking app. We need more of those. I hope it goes well. But please, please, please: I'm tired of my battery dying before I finish one cup of coffee at the coffee shop because of these inefficient apps.

Will someone, please, make Positron, the anti-Electron. It needs to be as portable as Electron (ideally), but based on a better runtime and language. Hell, Elixir is popular, let's go with that. You'll get _great_ concurrency from the start, and hot code loading, and a decent language

<comment><USER23> > Is your code so tightly coupled between logic and display that you haven't > reduced the common features to, essentially, libraries at this point? > Separation of concerns is not a novel concept.

No, I don't think many development companies have reduced the common features of codebases in 3 different languages to libraries yet.

<comment><USER22> Different _platforms_ , not languages, per the posted article.

Of course it's hard to combine multiple languages into a single library set, but if you're dealing with multiple languages you're often already dealing with multiple applications anyways and not combining them into one singular application. Or you've figured out FFI and can deal with the multiple language issue that way, in which case, wait, you have libraries in other languages!

<comment><USER23> > Different platforms, not languages

The article mentions iOS development in Swift, Android development in Kotlin, and web development in Javascript.

> Or you've figured out FFI and can deal with the multiple language issue that > way, in which case, wait, you have libraries in other languages!

As I said, not many development studios do that.

</comment></comment></comment></comment><comment><USER24> My question would be what's the alternative? Cross platform native apps rarely look as good, and would require entirely new code bases and different sets of developers. Sure electron sucks for users, but what's the business incentive to ship native apps other than to satisfy the minority of users who are even aware electron saps so many resources?

I think that for whomever is developing using electron in most cases the desktop versions of the apps wouldn't even exist if electron wasn't a thing. Also, just as a side note, electron apps are so _easy_ to develop. I don't know if any other platforms that target desktop are as simple, but I might just be out of the loop.

<comment><USER21> I'm a dreamer, I know it, but I still would like some kind of easy-to-use, developer friendly cross-platform UI toolkit. I used to do Swing development and, eventually, I learned to appreciate it. I understand why more people aren't jumping on the Swing train at this point but I have to say, the UI provided by Swing was less restrictive than the one provided by Electron.

Something in between would gain traction, I think, as Electron developer's run up against the hard edge of the kinds of UI Electron apps will allow.

<comment><USER25> > the UI provided by Swing was less restrictive than the one provided by > Electron.

I really want to know the use cases you're talking about, because, to me, nothing could be further from the opposite.

<comment><USER21> Warning: this video is old, lengthy, poorly paced and rather dull so feel free to click ahead. Still, it demonstrates a reasonably complicated Swing application that looks somewhat like a native Mac OS X application. The video was put together around 2003 so the look and feel is pretty dated. But the interface is fairly complicated and it does get feedback to the customer as soon as they get data out of range, etc.

[https://youtu.be/r_lTGoTscos](https://youtu.be/r_lTGoTscos)

</comment></comment></comment></comment><comment><USER26> > _Even more, anti-Electron posts are usually filled with charts and tables, > along with screenshots of Activity Monitor with memory and CPU usage, > outlining the evilness of the framework and why it must be stopped at all > costs._

Yeah, all those pesky actual metrics...

</comment><comment><USER27> One question that seems to go unacknlowedged around rapid development tools like Electron is: Does it trivialize work that others think are much harder?

A lot of devs have studied native app development before doing some amount of web development, or in this case mobile html app development.

By learning the technical natures of native app development perhaps a little too soon, devs can miss out on the incredibly deep lessons you can learn from rapidly iterating and solving customer problems, because most customers do not care what something is built in.

There's no question Electron (like anything) could be better in some ways, however, for it's strengths in ease and ability to test a solution with the market (and discover it's more than good enough), are toolsets like Electron really that bad?

There is a path to justify native apps in my mind, a path that when possible to go through tools like react, react-native, electron to build working solutions, is valid, and fine. The need to optimize the speed and performance, say in a native application.

</comment><comment><USER18> I don't mind writing the core of my software in platform specific C / C++ but I really like the idea of using web technologies for the UI + manipulating data in JSON for software IO (thus having a minimal JS engine). Does anyone know of a good middle ground ? I need CSS, VueJS and SVG. From what I read on the internet all I found is to link myself to the libchromiumcontent library

[http://www.chromium.org/developers/content- module](http://www.chromium.org/developers/content-module)

</comment><comment><USER25> Yes, Chrome is a memory hog, but that's nothing new. The thing is, Chrome still runs just fine on the laptops-of-old with 4 gigs of memory. I've always just assumed that Chrome likes to use whatever memory it can find (which, for people with a lot of memory who only browse the web, is probably what they want). Acting like these Electron apps are un-useable without supercomputers is silly.

<comment><USER2> Actually, each Electron app ships with its own version of Chromium, and if you have multiple apps running you will have multiple instances of _approximately_ the same runtime, but zero shared resources across apps - no shared executable segments, no shared RAM, nothing.

So the bloat is actually bigger than running multiple instances of Chrome.

<comment><USER25> Sounds like these apps are built with security and portability in mind ;). Seriously, though, this seems like an implementation issue that can/will improve over time. I can see the case where, yeah, if your users care about what your stack looks like and they refuse to use Electron apps, then sure, use something else (same goes if your users are laptop-heavy users with concerns about battery life). Some devs don't have those constraints and that's where Electron can fit in.

</comment></comment></comment><comment><USER28> What I find interesting is that in AAA game development performance is treated as a budget. You can write in a cross-platform engine but the tradeoff... is performance. It's always performance.

And yet we can port games to almost every platform conceivable when the code is appropriately architected.

Somehow this reality of programming eludes desktop and enterprise developers.

<comment><USER29> > when the code is appropriately architected

This has a substantial cost. Many games today make this tradeoff as soon as they can. Loading times is often the first victim, but in mobile you see it everywhere, even simple 2D puzzlers that can't hit 60 fps and still burn battery like crazy.

</comment></comment><comment><USER30> I really hope red-lang[1] or something like it takes off. We really need a quick (to develop), performant, aesthetically pleasing cross-platform GUI story. I hope Red accomplishes that.

[1] [http://www.red-lang.org/](http://www.red-lang.org/)

</comment><comment><USER31> In my view Electron is a total innovation killer. You can only use web controls, no custom controls. It's a nice way to start an app but you soon hit a wall because you can't do much performance tuning because you don't own most of the code.

I know there are no good multi platform UI kits but there but Electron seems a really bad direction from a technology point of view to me. Maybe we should give Java another go?

<comment><USER29> If I have a Java GUI app running on my system, Electron apps become the least of my bloat concerns.

<comment><USER32> Why?

Let's compare the electron-based Minecraft launcher with Minecraft itself.

The download is 400MB vs 11MB (+the 60MB JVM runtime)

The RAM usage is 300-600MB vs. 256MB

I mean, I don't see how electron comes out ahead in this (and it only runs the damn launcher, not the actual game).

Java definitely is the least of your worries. And with JavaFX you can even use the web APIs for UI.

</comment></comment></comment><comment><USER33> I saw a post called "Electron is flash for the desktop" a while back. I think that's basically true but the rationale is different.

Flash was a way to get true high performance dynamic content on the web before high performance JS, HTML5, and stuff like React. It was a way to be ahead of your time on the web.

Electron on the other hand is more of a fuck you revolt against the desktop.

It's 2017. Desktop computing paradigms are over 30 years old. Yet if I want to write a desktop app I _still_ have to write the f'ing UI at least three times: Windows, Mac, and Linux/BSD. It's not just different APIs either. It's totally alien paradigms: different languages, different ways of specifying a UI, and different API _paradigms_. This would be defensible if these desktop UIs were substantially different, but they are not. The difference does not justify the divergence under the hood at all.

Qt is the other big cross platform competitor to Electron, but it's also a complete re-implementation of the UI, is almost as heavy, and is in some ways less modern and feature rich. The web has such a huge user base that it's always up to date and always has the latest stuff, while Qt languishes with its own weird way of doing things.

WxWidgets was my favorite past attempt in some ways. Its APIs are ugly and horribly outdated but at least it tried to use native widgets everywhere and look and feel native.

React Native is a neat idea but you still have to drag in a complete JavaScript runtime so you are nearing Electron levels of bloat there.

Someone should do a modern WxWidgets type library using modern APIs and that works with modern C++ (C++11 at least), Go, and Rust.

<comment><USER34> This is absolutely correct. It may be _better_ in quantifiable end-user metrics to have different native desktop apps for every user. However, it is _far worse_ in developer cost to write those apps in native frameworks. The trade-off being made is not native vs electron, it's electron vs nothing at all.

<comment><USER35> No, it's not electron vs. nothing. It's one good single-platform application vs. one terrible cross-platform application. If you don't have resources for developing on multiple platforms, it is OK to choose one.

</comment></comment></comment><comment><USER36> > But advanced development machines of today are the entry level computers of > tomorrow.

I've been waiting for years for a cheap laptop with 4-8 GB RAM that's got a quad-core processor for development and light gaming. It seems those machines are always north of $600. If anybody has suggestions of what to do without going used I'd love to hear them.

<comment><USER37> I got a refurb Dell gaming laptop from Dell Outlet with 16GB of RAM, an i7 CPU, a 4k 15.6" touchscreen display, and an nVidia GT960M GPU for about $695; that was with a 20% or 25% off coupon, but those come up pretty regularly. It's a beast and plays games well. _Surely_ , you can find something reasonable for under $600, with spec requirements as modest as the ones you've listed.

My Dell isn't a _nice_ machine, by any means...it's a standard plastic job, but when I've bought higher end models in the past, they haven't lasted significantly longer than cheapo consumer models, so I just accept the cheap feel of the thing and save the $500+ that better builds cost.

It runs Linux very well today, though it didn't when I bought it, but that was due to video drivers, which would have been true of any device with a 4k display and the GT960M GPU.

And, on the subject of Electron, I started using Atom at the same time I got this new machine. It runs fine, alongside Firefox with a gazillion open tabs, Thunderbird with a hundred thousand emails in the inbox, and a Gnome terminal with a dozen or so tabs.

</comment></comment><comment><USER38> "The computer industry has been stuck on 8GB for what seems like far too long, but a 16GB standard reality is imminent, if not inevitable."

Uh... 4 GB is the prevailing standard for the average user PC.

</comment><comment><USER39> Having specialized in the web stack, it really pains me to see this fail. However, it is unreasonable and counterproductive to expect end user devices to continually increase in computing power and memory.

The future, for most users, is in smaller, cheaper, more deeply integrated devices, not in faster stronger devices. Just look at the smart watches of today, the AR kits of tomorrow, the joule-thief powered IoT devices that don't require a power connection. This is where we are headed, not towards epic gaming rigs for everyone.

I can only hope that in time, we will develop more efficient native implementations of the DOM, even if that means a major breaking change. IMO, the web layer is well suited to bridging the divide between vastly dissimilar hardware platforms, especially as the number of unique platforms explodes into a lush jungle of diversity and ubiquity.

<comment><USER25> We're declaring Electron dead now?

<comment><USER39> Failing is not dying, it is just a painful phase of growth and change. At least, that's how I choose to view my own failures.

</comment></comment></comment><comment><USER40> I don't use atom, but I don't understand why it needs to be defended or why people would attack it in the first place. If you don't like atom, like me, then don't use it. Is it deep down that you are really envying people using atom as their daily driver while you can't (do the same comfortably)?

After all, it is just a text editor, not like a hot technology that your boss will force down your throat, right?

<comment><USER41> I think atom is just a prevalent example of an election app. I for one dislike it and use sublime text instead, but not all electron based apps are as replaceable. Slack, another electron based app, is an example. It _is_ something that bosses force down everyone's throats.

The issue is not with atom, it is with the inefficiency that electron based apps bring.

<comment><USER40> That makes sense. It was not obvious from reading the article and comments. Thanks.

</comment></comment></comment><comment><USER42> How practical is react native for writing desktop / mobile apps from the same javascript codebase? I know the mainline has android / ios ux outputs and there are forks that have osx & windows outputs.

How does it compare to electron? From what I understand, react native is just a javascript vm + native UX libs.

I've also heard that react native isn't as much of a priority anymore at facebook.

</comment><comment><USER43> I feel like there is an economics PhD thesis on Electron apps and the tragedy of the commons (battery life and ram) waiting to be written.

</comment><comment><USER41> The main issue I have with the article is that it invalidates all attempts at efficiency because the author's computer can run the apps, and future computers can run the apps. That excludes a vast percentage of the consumer market, while excusing bad developer behavior that barely keeps up with the pace of technological development.

</comment><comment><USER44> But, Atom hangs up like crazy when opening big projects or big files, that doesn't happen on Sublime for example.

<comment><USER43> This is usually an issue with syntax highlighting. Turn off syntax highlighting and VS Code, for instance, can load pretty large files. Why most Electron based editors don't implement better syntax highlighting engines is beyond me...

</comment></comment><comment> harisvs-code I have been experimenting with a hybrid desktop app building technique for past few days.

Doesn't hog memory and you can build business logic in javascript.

this is a shameless self-plug! :-)

[https://github.com/harisvsulaiman/agenda- realtime](https://github.com/harisvsulaiman/agenda-realtime)

</comment><comment><USER45> TL;DR: One man's "this is fine" is another's raging house fire.

I use the same spec'd computer as the author, but I regularly quit Slack when I notice my fans spin up or my other apps swapping. Usually the culprit is a GIF in Slack burning 100% of a core or my entire organization's thousands of channels bloating my working set. Either way, a restart is in order.

I think the fixed-size 100mb RAM cost of a typical Electon app is lamentable, but a non-issue with 16gb RAM + virtual memory + SSD.

If I ever need to write a desktop app, I'll still use Electron — I'm not going to learn QT or Tk, or force my team to do the same.

<comment><USER46> What is your product so that I know in advance to completely avoid it?

</comment></comment><comment><USER47> As someone who produces an Electron-based app, I was curious what my energy use was as reported by Activity Monitor.

Avg Energy Impact:

\- 14.08 Google Chrome

\- 3.01 Docker (for Mac)

\- 2.55 Sublime Text

\- 2.04 Slack

\- 2.03 Terminal

\- 0.28 Mail

\- 0.20 My Electron app (which hasn't been open all day, so this number is definitely wrong)

Some of those surprise me.

Those who complain about Electron being a hog are right. But it's not like there's nothing that can be done about it. I'm sure there are optimizations that could be made to reduce resource usage. Firefox recently improved memory usage. With enough demand, I'm sure Chrome could, too.

</comment><comment><USER48> Why is Electron still such a memory hog? Wasn't the Chromium Content module supposed to dramatically reduce footprint by only providing the bare minimum to render a web page?

</comment><comment><USER49> Even if computers are getting better, faster, and coming with more memory, battery technology isn't improving by leaps and bounds.

Apps that are a battery hog aren't an option.

</comment><comment><USER50> How can the author think that it's normal for regular people to have 16GB of RAM?

The case of not being important to use GBs of RAM can be made if the app is Atom and it's a tool for developers, but regular people still have 2GB of RAM, not 16 or even 8.

</comment><comment><USER51> We should start treating this like a cultural issue. The PC existed for a generation before there was a real Internet, and at that point all apps were desktop apps -- CLI, GUI or otherwise. Then the web came along and it sucked. Then Gmail came along and showed it didn't have to suck, and further that you could build real applications on the web using JavaScript. Then a truly insane number of people learned JavaScript and JavaScript only, and since JavaScript only ran on the web they only built web apps with it.

The vast, vast majority of new, young programmers only know JavaScript, or maybe they know JavaScript and a "backend" language like Ruby, Python, or PHP, but that's less likely now post-node.

The vast, vast majority of cool, new tech needs to be built by programmers, and because of cultural reasons (young people are cool!) and business reasons (young people are cheap and otherwise exploitable!), those programmers are new, young programmers.

And so if your app now needs to be a desktop app, and you have a bunch of new, young programmers who are only really conversant with JavaScript, which UI framework will you use:

\- Qt. Sure you can use Qt Quick, but it doesn't really run on the web and your engineers have almost certainly never used it.

\- Electron. Sure it's objectively bad, but it runs everywhere you care about and your engineers can start today.

Or, if it's easier, look at it from the perspective of a young JS dev. They know JS; they're good at building SPAs; they have an app idea; .......they're probably building it in JS.

The arguments against Electron all boil down to "the web is a shitty application platform and JS is a shit language". You can't expect JS devs to cop to that, especially with the web as successful as it is.

I'm -- if you can't tell by my vaguely grouchy tone -- not an Electron fan. But my side fucked up. We let a gross blob of inefficient, JavaScript-running C++ code (that we charitably refer to as "the browser") become the platform of the future. We designed it in the worst ways, either in 10 days or by committee, and we didn't take it seriously ever. And it's only now that our jobs force us to use web apps that we suddenly give a shit, and for some reason we feel like none of this is our fault.

All I can really say is grousing about it just feels like deflection. Let's just try and not mess the next one of these up.

</comment><comment><USER26> Imagine if Mitch Kapor haven't siphoned tons of money into a BS open source calendaring app that was doomed from the start, but into a useful open source cross platform UI toolkit (and that's not Qt).

</comment><comment><USER52> With xulrunner we had something very similare to Electron, albeit much smaller, less hoggish. Too bad, Mozilla never ever took XUL further, despite many people (many in Intranets) asking for an IDE.

</comment><comment><USER53> I think it absolutely makes sense in business, making low quality product is fine especially when users are nontechnical, they just don't know which app is slow. Though as a developer, I cannot be proud of myself for making low quality electron apps, there is no craftsmanship to be proud of.

Moreover, if the argument of "it is slower but it costs less to make so it's ok" makes sense, then will people start mining bitcoin with client's computation power because it's "cheaper"?

</comment><comment><USER54> Running Atom on my machine seems to use maybe 600MB with a project open, am I missing something?

</comment><comment><USER55> Crazy that the people posting here would have a computer from 2010 with 4GB of RAM.

<comment><USER56> I have such a machine. It's a netbook. It does a great job running Arch Linux. It dual-boots Windows 7, but Windows 7 long since became unbearably slow and I've stopped using it. Sway and urxvt are very snappy, however. Kakoune never lags -- I see my keystrokes right away, even with syntax highlighting turned on. It also starts instantly. Even emacs runs pretty fast, although it feels a little heavier. But Atom? Forget it. It starts five electron processes and pegs the CPU. pacman -Rsc atom.

The thinking espoused by the article is rooted firmly in the last decade: "Moore's law will allow us to invest no effort in writing efficient software."

<comment><USER41> It's off topic, but how is sway? I have an old netbook with an Intel i3 processor, which I'm setting up with arch (because it's the only thing that the computer can support, thanks to the blatant neglect of efficiency from the ideas of this article). Think it's worth a shot?

<comment><USER56> Sway is good, and constantly improving! I'm mostly to the point where I forget I'm not running i3. There are a couple of things that might keep you on i3, however:

* Nvidia. I have not had the best of luck running sway on nvidia systems, even using nouveau. This situation is evolving, so things may have gotten better. I've had no problems with amd or intel graphics.

* Your display manager. I boot to the console and type "sway" if I want a graphical session. I've seen display managers get a bit confused by sway -- the display manager's cursor hangs around for the duration of the sway session, or the display manager crashes when sway exits. I haven't tried all of the options, but I've had issues with both gdm and sddm. Hard to blame sway for this, but at the same time it means you have to take your pick between sway and your display manager.

<comment><USER41> Huh, a shame about the display manager issues, and thanks for the gdm & sddm warning, I was about to go use them since they apparently recognized sway ([https://wiki.archlinux.org/index.php/Sway#Using_a_display_ma...](https://wiki.archlinux.org/index.php/Sway#Using_a_display_manager)), but I'll keep looking. As for Nvidia, no worries with the little old netbook, it's integrated Intel graphics.

<comment><USER56> I wouldn't totally dismiss gdm and sddm -- my issues could be peculiar to my hardware, the versions available at the time, and so on. As long as you've got a fast internet connection, it's only 10-15 minutes to try each one. YMMV, as they say! Just be ready to hold down the power switch if things go badly. (For reference, I'm using sway on a netbook with one of AMD's integrated offerings, maybe Llano? I haven't tried a DM on that machine.)

</comment></comment></comment></comment></comment></comment><comment><USER57> If the critics of Electron keep rising, like JS, I'm also planning to invest more on it. JavaScript has been paying great dividends to me despite all the bashing.</comment>


Ask HN: Rate my startup: IvyLees - <AUTHOR> http://ivylees.com

<comment><USER3> It seems like a well-designed application to me. While I am not intimately familiar with the need for such a social network, I will trust that you and others can make that assessment.

A couple notes on the design:

\- Focus borders on the username and password fields are different.

\- I like the clean look overall, but the contrast is a bit too low in some places: Large buttons, Registration form header.

\- I think a little more top and bottom padding on the search bar would be nice.

<comment><AUTHOR> Thank you. You have a very good eye for detail-- I'll add these to the to-do list.

</comment></comment><comment><USER4> Playing around with it now and so far:

1\. Love the design. Simple, clean, effective.

2\. The "tools" sections need to be much more apparent. This is in theory the main purpose of the site.

3\. 140 characters is hot as Hansel right now, but there's no way someone can pitch me effectively in 140. I think that needs to be upped significantly.

4\. I'd like the homepage to be more of a personal dashboard. History of direct contact, recommendations of new releases that fall in line with my "public collections" (I don't like that terminology, 'groups' maybe?), etc.

I focused on the negative because those are the areas I think need the most work, but overall I think you're off to an awesome start. I could see this becoming very usable for me - ie, button on my blog and a note that I will only consider pitches delivered via Ivylees. Man, that sure would help my inbox...

<comment><AUTHOR> Thanks, Zach. These are all areas we're concerned about right now, so your feedback is definitely appreciated (and focused on the right spots). When you say up the pitch character limit, are you thinking around 300? Or even more?

<comment><USER4> My pleasure, and feel free to hit me directly if you'd like feedback as revisions are implemented. As for the character limit, 300 is much more appropriate I think. It's a catch 22 in a way - journalists/bloggers theoretically want a lower limit with the hope that they will receive a succinct message. Businesses/flacks on the other hand, will be put off if they have to keep revising their thoughts over and over to fit them into such a small space.

Personally, I might start with a limit of 500 characters but I'm likely in the minority. For comparison sake, this message is 593 characters.

<comment><USER5> I would have said 500-1000. There's only so much you can convey in 3 sentences.

</comment></comment></comment></comment><comment><USER6> Would prefer to see some sort of demo that doesn't require signing up. Maybe a interactive demo, simple flash presentation or at least graphical use cases.

Nitpick: big buttons at the bottom don't seem clickable.

<comment><USER7> We've opened up parts of the site so that you don't have to be logged in to view it. Some links will need to be added to the front page, but maybe this will satisfy your curiosity for now. <http://ivylees.com/associations/IvyLees>

</comment></comment><comment><USER8> Irony is 68-point font telling you to "whisper, don't shout"

<comment><USER9> A lot of the time small fonts are a pain, though. I liked the look.

<comment><USER8> With a name like "helveticaman", I guess I'll take your word for it.

<comment><USER9> A helvetica man is actually the symbol on the men's room...but yeah, I like the font too.

</comment></comment></comment></comment><comment><USER10> Interesting niche.

One comment on the front page - I think it's great and clean, but I think it undersells what you're doing. The "highlights" that you have (linked form the pale buttons at the bottom) are very compelling arguments to try your startup ... but they're hidden one click in.

</comment><comment><USER11> The design is nice. Is this addressing a real need? I am very close to the "media outlet environment" and I'm not sure if we have a need for such a resource? What are the tool-based things you are talking about? Maybe I just need more convincing?

<comment><AUTHOR> Thanks, tyohn. I suppose it depends who ask if we're filling a real need. PR agencies pay hundreds of dollars a year to have access to media databases. Companies pay anywhere from 5-350 dollars to put out news releases to the big newswires. To us, it seemed like both of these needs could be served much cheaper with a tool-based social network.

<comment><USER11> Now that you've "opened up parts of the site" and I played around - I think it makes a lot more sense to me. If you can gain some critical mass it just might work. Good luck!

</comment></comment></comment><comment><USER12> Will certainly take a look at this in more detail when I'm on my laptop, as I'm on BlackBerry now, but I find the concept interesting.

I work at a PR agency and a tool such as this to help "push" the advancement of new and relevant technology/services is really welcomed. This can cut into territory like Cision's for media database lists considering users of the site actively generate content.

A few questions/tips;

1.Can I cull some of my other SNS information and port it to your site? Maybe even just an OpenID or Clickpass account?

2.Have you done any self-marketing yet, perhaps even reaching out to the larger agencies for a live demo? May be a nice idea to generate interest at a target market.

I'd be happy to have you guys demo something in the future.

Oh, one other thing in terms of an idea: Set private networks based on agency email address.

So, as I said above, take my comments for what they are worth on a BB, but I'll check the site out in more detail. Just wanted to add here that this is a very good niche for something like this. Good luck!

</comment><comment><USER13> You have picked an interesting niche within a large market of professionals. I assume you have done your homework re: competition, present options for solving customer problems, and therefore demand for your product.

There are many market niches that are presently underserved by current businesses. Do you really think Craigslist, Ebay, and Facebook will still be the only solutions for their users in 20 years time? I highly doubt it. Smart entrepreneurs find a way to snag users from sites with proven appeal by creating a unique spin on what the market leaders do.

For example, a startup in France (not yet in the States, hint hint) operates an online marketplace for specific, high-demand categories of goods such as electronics (ie Iphones) and digital cameras. You can choose what you want to sell for, but the price must be 50% below retail, regardless of the condition of the item. So- specific goods at 50% or more below retail is a unique sping for an online marketplace that hasn't yet been done in the States. There- I have just released one of my startup ideas. Anyone want to have a go at that one?

</comment><comment><USER14> \- _Whisper. Don't Shout_ is cute, but it doesn't tell me anything. That's a lot of screen real estate for something that's just cute.

\- The term _social network_ is somewhat tired. Everything is social now. Building a social network was sexy three years ago. Now it's just a category of sites that hearkens to the passing bubble. Say what you do. People will expect it to be _social_ anyway, and besides, when was the last time you went looking for a "social network for $foo"?

\- Connected to those two, your two key points seem to be "Create and share news releases." and "Get new story ideas or pitch your own." Those are your message. That's the reason people will be landing on your site. Those are the ideas that you want to hit people over the head with in the first seconds that they land on your site. Bonus points if you can convey that graphically.

</comment><comment><USER15> The design is nice, the opened page is very facebook like I don't think it has to be, use your talent to stick to your originality.

I don't know much about journalism and PR work but I will suggest you find a way to source your content from other sources in other to attract users don't count much on user-defined content, I get this from watching a friend of mine struggle with his content driven social site.

I must give you guys an A for your design, I have not tested it usage (will do so when I have a minute) but I will strongly suggest to make some content visible without sign-on. Sign-on-before-you-see scenario can be a turnoff for most people.

</comment><comment><USER16> Interesting idea. How are you going to keep signal vs noise ratios worthwhile for Journalists?

If I'm launching a start-up and want to have to send out a press release, I need to either hire a PR agency or find a list of people I should email, which means I am at least minimally competent. If I understand correctly, on IvyLees, I could just sign-up and issue a press release into my industry. Assuming the site becomes popular, won't Journalists be more interested in the companies that are capable of reaching out to them 'the hard way' rather than issue a massive press release?

</comment><comment><USER17> Can I join and mercilessly spam the heck out of media outlets?

Also, what's the play here? Are the tools supposed to pull people in? Do you have any journo or PR cred behind the project?

</comment><comment><USER18> I can't use this and know if I'm really giving useful feedback, but: everything is pretty except for the Search bar up top. It takes up a lot of space and doesn't provide much, and I don't like the blue.

Also, you have something like three different effects when I focus on three different fields.

</comment><comment><USER19> interesting idea - clear target audiences. trick will be getting those audiences to use this. seems like a relatively good problem to have, especially for a communication network play, though by no means cake.

two design tweaks:

on my pretty good lcd, the 'sign up today', 'journalism' and 'business & pr' calls-to-action lack enough contrast for the white type to pop without me adjusting my screen settings.

looking at the press release template - your logo is huge. which is ok - <USER2> i realized that that's where the (my) companies logo would go. even then it's a little large. regardless of the size, though, i would think about changing your example press release to something other than your own company as understanding whose logo that is is a subtly you don't need to create.

</comment><comment><USER20> I think it's a cool idea for a product. The Journalism / PR space can use some innovation. The struggle, perhaps, will be getting people to start using it. I'd recommend getting to know people / users at places like OJR.org, MediaBistro, etc.

</comment><comment><USER21> my two comments would be 1) make the "tools based" either link to a page describing what that means, or find a better way to describe it. I think I know what you are getting at, but I'm not sure most people (non-tech) would.

2)the "Journalism" and "PR - Business" links at the bottom of the page that are somewhat greyed out. They look good in the sense that they don't draw too much attention, but I'd think that the least they should darken when I hover to make it apparent that they can be clicked. The way it looks right now, I'd think that they were greyed-out as in unusable.

</comment><comment><USER21> my two comments would be 1) make the "tools based" either link to a page describing what that means, or find a better way to describe it. I think I know what you are getting at, but I'm not sure most people (non-tech) would.

2)the "Journalism" and "PR - Business" links at the bottom of the page that are somewhat greyed out. They look good in the sense that they don't draw too much attention, but I'd think that the least they should darken when I hover to make it apparent that they can be clicked. The way it looks right now, I'd think that they were greyed-out as in unusable.

</comment><comment><USER22> This is a genuine nit-pick, but I don't like the light green ivy leaves on the blue background (top left)... Maybe I had "blue and green should never been seen" drummed into me too much...

</comment><comment><USER23> The name makes me think of "Ivy Leagues", which makes me think it is something for students. Also... white text on a light-coloured background is quite hard to read.

</comment><comment><USER24> I have to ask, what need are you addressing that already existing social networks don't provide?

<comment><AUTHOR> We're offering traditional public relations tools, including an online newsroom, a press release builder, and media list building.

</comment></comment><comment><USER25> To me it looks just like you implemented a few parts of FB, and copied their style guide.</comment>


Show HN: Mockups and wire-framing tool built using web components - <AUTHOR> https://github.com/wiredjs/designer <comment><AUTHOR> Few weeks ago, as a fun project, I built a set of web components that had a Balsamiq like hand-drawn sketchy look. Basic components like buttons, textboxes, sliders, etc. wired-elements: [https://www.webcomponents.org/collection/wiredjs/wired- eleme...](https://www.webcomponents.org/collection/wiredjs/wired-elements)

(Fun fact about these: Just like any hand drawn shape, no two renderings of the component will be exactly the same)

Last week I came across [https://github.com/PolymerLabs/wizzywid](https://github.com/PolymerLabs/wizzywid) a basic wyziwig editor for Polymer components.

For last weekend's fun project, I adapted the code to use wired-elements to create a simple Balsamiq like visual wire-frame editor.</comment>


The Best Punctuation Marks in Literature  - <AUTHOR> http://www.vulture.com/2014/01/best-punctuation-marks-literature-nabokov-eliot-dickens-levi.html <comment><USER2> Victor Hugo's one character telegram to his publisher, asking about the reception of _Les Miserables_ : ?

His publisher's response: !</comment>


AirBnB lost half of the traffic in 5 months - <AUTHOR> http://siteanalytics.compete.com/airbnb.com/

<comment><USER2> Two points: (1) this is U.S. traffic only --- more than half of our traffic is international (2) the slump corresponds with the seasonality of U.S. travelers; compare with vrbo.com for a similar example.

</comment><comment><USER3> It's about travelling and therefore going to be highly seasonal. You need to see data from a couple of years to really see a trend.

<comment><USER4> Yeah, people were booking for the holidays ahead of time during the summer. The holidays are peak time for Airbnb and other travel companies so I'm not sure what the original poster thinks this shows exactly. Certainly people weren't traveling less in December!

</comment></comment><comment><USER5> So did Kayak and every other travel site.

<http://siteanalytics.compete.com/kayak.com/> <http://siteanalytics.compete.com/expedia.com/>

It's seasonality and it happens every year.

</comment><comment><USER6> I can't see the graphs in the article (on the iPad in a cafe), but I wonder how closely the traffic slump correlates with the bad press they got late last year over the girl who's apartment was trashed?</comment>


Show HN: A practical guitar sight-reading trainer - <AUTHOR> https://dpapavas.github.io/fretboard-trainer/ <comment><USER2> This is cool! I think I'd prefer playing against this though - but at a quick glance that seems difficult.

As a "cheap" way to support playing, perhaps playing the note after 10s would allow you to ear-match the note to confirm whether you got it right or wrong? And just auto play?

Come to think of it, I'd love trainers like this that let me use my real guitars.

<comment><AUTHOR> Assuming by "playing against it" you mean actually playing the correct note on a guitar and having the application directly verify it via sound, I've considered it, but I have doubts it would be practical. Besides the need to actually have your guitar near a suitable microphone in a noise-free environment, you'd need some sort of functionality like in a typical tuner application, but given the tendency of such applications to jump frequently between the actually sounding note and others (harmonically related I assume), I'd expect a lot of false negatives (or even positives when you get lucky). Still, it might be workable and you can't tell before you try it, so I might give it a shot in the future.

As far as I can tell though, the basic advantages of using a guitar, would be that you actually train your muscle memory, by having to fret the note with the correct finger, instead of just visually identifying the correct fret and that you'd get audible feedback in the form of the note actually sounding. The former is, to some extent, possible with the application as it is. I've implemented various modes, but the only one I use any more, is the randomly picked position, which enables certain keybindings, which allow you to turn your keyboard around and hold it like a guitar (I have a split keyboard so I only have to hold up half of it; not sure how practical it is on a normal keyboard). You can then "fret" the keys with the correct finger, which should hopefully build muscle memory as well.

I haven't implemented sound yet, but I'm considering it, so, once that's in place, your suggested functionality would amount to implementing a timeout for each note. Feel free to open an issue request on GitHub.

</comment></comment><comment><USER3> I really need something like this!

I think a touch friendly version would be useful for people on tablets.

<comment><AUTHOR> Isn't it already touch-friendly? You can select the correct fret by tapping it. If it doesn't work for you, try opening an issue on GitHub[1].

(I did notice though, that on my tablet the notes aren't positioned correctly, so I'll need to look into that).

[1] [https://github.com/dpapavas/fretboard- trainer/issues](https://github.com/dpapavas/fretboard-trainer/issues)

<comment><USER3> Works fine, just a bit hard to hit those buttons on a 6" phone.

<comment><AUTHOR> Yes, it doesn't display correctly on smaller displays. I'll have to look into that.</comment></comment></comment></comment>


Bebo Founder creates a Private Social Club - <AUTHOR> http://www.sfgate.com/style/article/New-private-S-F-club-the-Battery-4869389.php

<comment><USER2> The Bohemian Club and Stanford University started out with similar egalitarian ideals. I wonder if it's possible to sustain this kind of endeavor long term without losing the egalitarianism...</comment>


Apple Watch doesn't excite people, says Fitbit exec - <AUTHOR> https://www.cnet.com/news/apple-watch-doesnt-excite-people-says-fitbit-cfo-bill-zerella/ <comment><USER2> Fitbits excite people just about as much as Apple Watches, and probably even less I'd say. The whole category is pretty boring if you ask me. Fitbits are basically feature rich pedometers, and look how many people still use those. At least an Apple Watch has a little bit of Apple "pizazz" to it. A fit bit is about as exciting as strapping a featureless IBM computer from the 90's to your wrist.

There will always be a subset of the population that wants a wearable. I just don't think they will be/are nearly as ubiquitous as te predications a few years ago.

<comment><USER3> I agree. Knowing how many steps i took today is so boring.

</comment></comment><comment><USER4> Take a look at Fitbit's website and see just how many product variations they sell... For their single category of product which is a fitness tracker.

Apple sells one watch and we know what it does.

The story of Job's and his four-quadrant diagram come to mind.

<comment><USER5> Now go look at Apple laptops... it will make you sad.

</comment></comment><comment><USER6> Pebble did excite people, but it went out of business and got bought by FitBit, who have done nothing with it.</comment>


It's fun reading people's mind with my digit game - <AUTHOR> https://itunes.apple.com/us/app/my-digit/id889875037?ls=1&mt=8

<comment><USER2> It's hard for me to get the feel of what is this game about by just reading the description. The screenshots look interesting and I'd be happy to try it if it was free or if I had more information about it.

<comment><AUTHOR> The game is very easy to understand. (Your Turn)You select a digit from the rack and your opponent try to guess the digit you've selected. (Opponent Turn)Your opponent selects a digit and you try reading your opponent's mind to guess the digit your opponent played. It's all about intellectual guessing. If your opponent make a wrong guess the digit is added to your score and vice versa You should check the game website and also watch the game trailer on the website. [http://mydigitgame.com](http://mydigitgame.com)</comment></comment>