Hacker News Reader

Comment by vid | Hacker News Reader

I am probably going to lose some precious poinnnttts for this, but I sure wish they could instead target browsers instead, whether by using the canvas, WebGL, three.js, A-Frame, or something else. This would have the immediate benefit of making the software work on the Web or as a local webapp any device that supports a browser, and they would have a much larger pool to hire from. They could also come up with with great libraries.

It is not quite in the same league, but we already have SVGEdit[1] as an example. as well as diagrams.net, but taking a 2023 approach would be much more performant and open ended.

1. https://svgedit.netlify.app/editor/index.html

View on HN

They could, but there are also many people that just prefer native applications. I'll take Inkscape on Linux or Affinity Designer on macOS any day over a web application. They have native widgets, standard shortcuts, I can easily script them with Automator or Shortcuts, they work with the native OS accessibility options, can have integration (like drawing with Apple Pencil on an iPad on a Mac), they are more performant (can directly use native Vulkan/Metal APIs), are generally more privacy-friendly, don't consume huge amounts of memory/CPU, etc.

There is a place/market for both.

Figma works pretty well to be honest.

https://penpot.app/

Figma also went to great lengths to make it perform as well as it does. Doing something similar for Inkscape seems unlikely but who knows.

https://www.figma.com/blog/building-a-professional-design-to....

Hmm, I don't think Inkscape on Mac supports Automator &c. And you can run it as a local server to mitigate privacy concerns. There are ways to support stylus features in browsers, though it's an area that could use more support.

That was about Affinity Designer. The main point is that with by using native APIs you get deep platform integration. I just gave Mac App examples because I am more familiar with that platform.

Inkscape on macOS feels like the furthest thing from native.

Graphical design can be fairly complex. Some vector might contain dozens or even hundreds of control points, and a vectorgraph might contain many of layers of vectors/groups. Rendering the graphic itself and the software UI element might be a challenge for browser engines which is not made for this kind of task, especially on slow computers.

I worked for an ad publishing firm many years back, it was common for us to receive vector graphic files that are hundreds of megabyte large. We used Adobe Illustrator and CorelDRAW to handle those files on some fairly fine computers, and yet some graph files from our clients still managed to crash the computer due to RAM exhausting etc.

I image it makes sense for an industrial capable software to want to run as native as possible.

Another thing is color management. Most graphic software supports RGBA, but for publishers, CMYK is also required. I'm not really sure if browser engines supports these color system well enough (not just color conversion between the two, but also color profile for the monitor), because if something is mess up there, it can be expensive to fix (for the ad publisher).

Considering how sluggish web applications are, please no.

If you really want to, you can run Inkscape in the browser the same way Figma runs in the browser: compile it to WASM.

There's nothing that says a web app has to be sluggish. You don't need an entire chromium instance to run a single web app. Web views are usually more performant, but have the issues of compatibility (Chromium vs Firefox vs WebKit), but it still seems worth it to me.

There's nothing that says that of course, but my RAM says fooey to webapping a tool like Inkscape. I use it almost every day, I just finished using it to make a poster where I needed to print out a hi-res background with text that would be in juuuuust the right position for me to use my typewriter to type on it and have that text end up in exactly the right place, then scanned that at 1200dpi and used inkscape to crop and export the final piece.

I do not think my browser is ready for an 8000x8000 raster image with svg clipping etc. Not to mention the ungodly large bitmap traces, with hundreds of thousands of nodes...

A browser tool like Inkscape would be cool and useful. But no replacement.

Running a simple todo list app these days destroys my mac’s battery life because of the Chrome shit. Wen apps are like drugs: Just Say No!

I'm currently working on WebKit support in Boxy SVG (https://boxy-svg.com/ideas/95) and SVG rendering performance seems to be actually better than in Inkscape - especially when transforming many objects simultaneously and when manipulating objects with filters applied.

Igalia has made some massive improvements to the SVG engine in WebKit recently: https://wpewebkit.org/blog/05-new-svg-engine.html

You’re being downvoted but honestly Inkscape suffers a bit when put up against some nastier SVGs. Chrome handles them alright though

Granted I've not checked recently, I want to say this was pre-Blink, but Safari (iOS and OSX) struggled massively with SVGs that Firefox and Chrome handled with ease – maps in my case. If we're at the point where Safari is finally faster than Inkscape that's great news, although I still don't want a browser based utility.

The new SVG renderer in WebKit makes it the fastest of the 3. Not yet finished though.

Thank you for building Boxy SVG, it's a wonderful tool, very fast and easy to use.

Ironically, the ideas/95 URL doesn't work in Safari.

"Error - can't load the page (unsupported web browser)"

Web apps have largely had terrible performance compared to native even on my development machine. Everything moving to the browser is a regression in isolation, increase of complexity, and a poor use of resources given that the application works fine without. Dependency management and packaging complexity become an issue to the point where projects refuse to package such applications.

Web Assembly might be a way to provide web app support in addition to native but it should never replace native.

Also, energy efficiency is starting to play a greater role here in the EU where hopefully it encourages less use of energy hungry frameworks and more native applications given their better resource use.

Why does everything have to fit in a browser? This trend is really tiresome.

Inkscape is Inkscape to me because its native. If I want something on the web, there's Figma, which is closed source, and penpot.app, which has most of the basic features of Figma but is FOSS.

Yes, why don't these silly devs just rewrite an entire app in a bloated environment which will make it run 3x slower and consume 10x more memory? :)

Also, posts that open with "I know I'm gonna get downvoted for this but [...]" are an automatic down arrow for me.

gtk has an HTML backend. https://docs.gtk.org/gtk3/broadway.html

It isn’t useful for what people want.

I wouldn't downvote it if this was written in 2015 when this was the zeitgeist but most of us have moved on from that (harmful imo) trend

Didn't know about svgedit! Looks interesting.

I started doing my svg editing by hand last year after becoming frustrated with the nonsense one gets when exporting from most graphic editors.

Yes, it's a little cumbersome but quite straightforward, and one would be surprised how far it's possible to go simply by combining elementary shapes.

Porting gtk3 to gtk4 is relatively easy... And can be even automated in some parts. Not to mention that all the algorithmic part is preserved as it is.

Writing something web from scratch is another world, and performances won't ever be close.

Reply on news.ycombinator.com