Hacker News new | past | comments | ask | show | jobs | submit login

Cue the downvotes, but at least if you use Electron and build a custom UI you don't need to worry about it being unsupported or poorly supported in the future on certain platforms. It's just HTML + CSS which is going to be around a lot longer than the current iteration of UI frameworks.

(Ok yes, you could still face issues with the underlying runtime being unsupported, but I have a feeling that and JavaScript are going to stick around for a while)




>Cue the downvotes, but at least if you use Electron and build a custom UI you don't need to worry about it being unsupported or poorly supported in the future on certain platforms.

Yes, you'll don't have to worry: you'll be certain that it is poorly supported today and in the future on all platforms as far as the topics we discuss are concerned (native UI likeness).


I'll take a non-native looking app that works (every Electron app I've tried on macOS) over XQuartz-based garbage that hangs forever at startup, as the current "stable" Inkscape release does for me.


Maybe, but not for a graphics editor.

Slack hogs RAM and burns battery like crazy, and it's a bloody chat app -- as simple as it gets.

Now imagine an Electron version of Inscape with complex vector editing, gradients and co on screen...


It's not even very hard to imagine. Just go to any web-based diagram drawing service (there's plenty of that), and look how sluggish and crappy it feels even when performing simplest and most basic tasks. Now multiply that crappiness 10x for the complexity of vector drawings (100x if you're doing vector art), and additional 10x for the complexity of the effects vector formats can handle - and you'll get a ballpark of how Inkscape would feel if it was an Electron app.


I've used https://app.moqups.com/ for diagramming/wireframing for a few years, and it doesn't feel sluggish to me at all. Feel pretty snappy, in fact.


We don't have to imagine. Someone has made a clone of Sketch for the web: https://app.designer.io/. There's an app to download as well.

It doesn't match the performance of a native equivalent, but doesn't seem unreasonably slow or bloated either.


There are also two other Electron-based vector graphics editors on the app store:

- Boxy SVG - https://itunes.apple.com/us/app/boxy-svg/id611658502

- Vectr - https://itunes.apple.com/us/app/vectr/id1204645754


Can we tell without feature parity? I were writing such a webapp, I'd skip features that were slow.


The OP suggested that no web/Electron based editor could have "complex vector editing, gradients and co on screen". This has nothing to do with achieving 100% feature parity, so yes, we can tell. Anything else is moving the goalposts.

100% feature parity is a meaningless test in any case. Sketch doesn't have 100% parity with Inkscape, which doesn't have 100% parity with Affinity Designer, which doesn't have 100% parity with Illustrator, etc.


Boxy SVG [1] is an Inkscape clone built with Electron and Xel widget toolkit [2]. I would say its UI is on pair with native macOS apps such as Pages or Keynote.

[1] https://itunes.apple.com/us/app/boxy-svg/id611658502

[2] https://xel-toolkit.org/


I think the downvotes are partly because of your "Cue the downvotes" at the beginning... beyond this, even as a big fan of Electron based applications, for a lot of things, it's not a great fit for a many things. I'm not sure a vector graphics program is a good fit or not, or where the edges in performance may be. I know that using it for heavy filters on raster art would be too slow comparatively for many.

Frankly, VS Code is probably the only moderately complex application that really shows off Electron. Many electron apps just aren't that well written, and not to besmirch any developers working in other toolkits, making good JS code in a larger codebase is a different kind of skill than most are used to, beyond this, the techniques and approaches for performance gains are also fairly different.

I don't think Chrome, JS, Node or Electron are going anywhere any time soon. There are some definite value wins in that space. That doesn't make it a great fit here, but I'm happy to be surprised.


My experience with many years of pushing Illustrator's limits is that the big performance hits are:

1. lots of transparency with the GPU acceleration on - it very quickly becomes an order of magnitude slower than the CPU renderer, especially if you do tricks to generate 3-4 translucent shapes from every path you draw by hand like I do nowadays 2. adding new objects to a complex file starts getting super slow (somewhere around 4-5000 paths, less if you're generating lots of virtual paths via various effects) - I'm not sure if this is due to running out of physical memory, or trying to insert new items. in the middle of a very large and complex list of items, or what 3. a few large bitmap effects at 300dpi can very quickly bring IllustratorI to its knees, I'm not sure if this is due to using up tons of memory, unoptimized image convolution routines, or simply having to grovel through a lot of data. 4. also you can do some really terrible things to Illustrator's performance very quickly by applying a distortion mesh to a shape with a pattern fill that contains a lot of copies of its pattern 5. in general there's a lot of ways to send performance over a cliff by making the program generate a hell of a lot of shapes from simple rules - scatter brushes deposit a lot of copies of a shape along the path you draw, art brushes distort a shape along your drawn path, you can generate multiple paths with various programmatic effects applied to them from a single path...

You could probably edit moderately complex files with a theoretical vector package working under the handicap of being interpreted JS running in a neutered web browser. I did nice stuff with Illustrator way back in 2000, on machines that ran slower than a modern box would after the additional overhead of running compiled JS in a neutered web browser. But I sure wouldn't consider it for high-end work.


I agree... I only meant that there are differences, and the style of programming it takes for high performance JS is sometimes counter intuitive to what one would do in another language. The browser is effectively a sandboxed operating system at this point... there's a LOT you can do there.

For that matter, I'm a pretty big fan of the chromebook model, so all the more happy to see web based apps working, even if google seems to be taking a couple steps back in that space. I'm simply unsure if the time/effort it would take, combined with the differing skills combined would yeild something better... more portable maybe, but not necessarily better.

Who knows though.


> if you use Electron and build a custom UI you don't need to worry about it being unsupported or poorly supported in the future on certain platforms. It's just HTML + CSS which is going to be around a lot longer than the current iteration of UI frameworks.

No, you just have to worry about JS frameworks that change every week, and HTML/CSS support which also tends not to be very stable over time. Forget about pixel-perfect UIs.

Also, the way people write those pseudo-desktop apps, their UI breaks in really funny ways when your Internet connection lags. This is not Electron issue per se, but the issue of culture around web tools.




Applications are open for YC Winter 2020

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

Search: