Gravit – Open-source design tool | Hacker News Reader

Gravit – Open-source design tool

hub.gravit.io

437 pointsjarek-foksa73 comments

It's worth noting that Gravit.io is a JavaScript rewrite of Stagestack project [1] which was an attempt to create commercial clone of Macromedia FreeHand from scratch [2]. Stagestack project failed due to lack of funding from FreeHand community.

[1] http://www.stagestack.com/

[2] http://www.freehandforum.org/news.html

... but Joel Spolsky said you should never rewrite code ever ever ever...

Whereas what Joel said is debatable, this snark comment is wrong on so many leves it's funny...

1) Joel was talking on the context of a software business -- if you have working code it can be detrimental to business to do a rewrite from scratch, it will take you years, you will leave stuff off, piss off your customers, lose ground to the competition etc. It's not like Gravit.io has that kind of "business reasons" at this moment (this is their initial version offering), so his reasons do not apply to it.

2) Gravit.io is a port of a project to another language. This is not a rewrite -- much less a "rewrite from scratch". Again, Joel's reasons do not apply to the situation.

I think he was trying to be funny

Yeah, hence the "snark" moniker, but funny works better if it's also clever and/or coherent.

This may be the first time I try a web app that is as snappy as a desktop one. Congratulations!

What front-end frameworks/technologies did you use?

According to the bower file [1] they only use jquery

[1] https://github.com/quasado/gravit/blob/master/bower.json

A cursory glace at the editor code does not reveal any extensive jQuery use (in fact, I didn't notice any). I've never seen a jQuery-heavy app go quite this fast.

I found the opposite opening a random file: https://github.com/quasado/gravit/blob/master/src/gravit/com...

+1 on making it iPad-compatible and making the demo without subscription. And snappy webapps in the iPad are rare.

Also from the bower file, the magic that turns it from a web app into a standalone app is node-webkit [1]. This kind of tool is really becoming one of the best options for creating desktop applications, especially considering how powerful the browsers' devtools have become. It's having like a GUI designer and a debugger rolled up into one.

[1]: https://github.com/rogerwang/node-webkit

Iirc, lighttable is written using node-webkit as well (in addition to clojurescript).

>> "What front-end frameworks/technologies did you use?"

Why is that everyone's first question? I get this constantly when I demo my stuff at meetups and hackathons. None. The answer is none. And they look at me like I just admitted to being a person who prefers to breath water. Vanilla JS is not that hard. It's a sight easier to know one language than to have to relearn the darling framework of the year all the time.

It's only been a year or two since major software is written in JavaScript. Why did you relearn the darling language of the year?

Perhaps you have been sleeping under a rock for the last 10+ years. Unless most multi-billion web services, from Gmail to Facebook are not "major software".

Plus, from his cv: "I've been doing JavaScript since it was invented.".

Vanilla js is not that hard when you have thing like document.queryselect or you're building trivial web apps. Sadly when you're building enterprise grade software and you have to support things like Internet Explorer 7 it makes a lot more sense to use a framework like angular than vanilla js.

Having been involved in lots of different types of projects over the years, "enterprise" software is not different from other types of software in any way.

Sorry but when I'm writing my hobby projects I don't have to worry about supporting a 13 year old browser.

The occurrence of this in enterprise is grossly overstated.

>Why is that everyone's first question? I get this constantly when I demo my stuff at meetups and hackathons. None. The answer is none.

Are you the creator of Gravit.io? If not, then your response is useless, because nobody asked YOU that.

The point is, as someone who has been in this position of being asked this question on several occasions for a number of different projects, it's extremely frustrating to be asked this question rather than anything actually pertinent to the project. So if you don't get any sort of answer from the Gravit.io team, this is why you should probably not be surprised. It's an insulting question. We're much more than just glue coders between this-and-that-frameworks.

Give your custom code a random framework name :) Someone could make a framework out of it.

Actually. I don't see it as an insulting question at all. If you've demoed something cool and someone asks you what technologies you used it's usually because they're wondering if they can use them themselves. It's not them hoping to jump you for using the unpopular framework.

if i see someone build something awesome and would like the ability to build something awesome in the same sphere I ask them how they did it, so that I can emulate those strategies in my own work. Part of "how they did it" is what tools they used. Are they using something I'm unaware of? Are they using something I'm aware of but may have dismissed and should reconsider? Are they using something that they now regret and can warn me away from?

Yes, we are more than glue-coders. Carpenters are way more than people who wield power tools, but it doesn't mean they don't discuss tools with each other. If they see someone else who's constructed something they're not sure how to do with their current toolset you know they're going to ask what the other guy used to build it.

Yeah, I'll ask you what you used, but I'll do it because you've accomplished something cool and I want to compare and contrast strategies from someone who's (in my mind) succeeded at something.

No, usually people who ask this sort of question aren't looking for suggestions. They're looking for validation for their own choices. Because the question is almost always followed by a statement, "oh, you should use (Angular|React|Whatever), that's what I use."

Most people, even on boards like this that select for technology-interested people, don't make things. Even people who think of themselves as "makers" (ugh, I hate that word) don't make things.

I don't mind people making suggestions (though something that would fundamentally require a complete rewrite seems more like trolling than being a mere suggestion). But when they then act like I'm insane because I don't use a 3rd party framework, then I start finding trouble keeping my opinion to myself.

Do you ever reuse code from previous projects?

I just tried it for a few simple operations on a 1.3GHz laptop from 2006 (which is running and IDE that's indexing in the background), and this app was still instantly responsive. Very nice work indeed.

It's usually AJAX + lots of DOM manipulation that makes web apps crawl. Everything here is static.

Random thoughts; (1) A classic drawing tool made slick, beautiful. (2) Flash is not needed for this type of work at all, thanks to HTML5 (3) It's fast enough (4) View source shows nothing, which means all the UI view generation functionality has moved inside JS.

(2) Maybe it was faster for him to build that way, due to experience, etc.. (3) strawman argument, perhaps he chose his technologies for other reasons besides premature optimization. You're essentially accusing him of making a design mistake IMO. (4) The fact that right click is disabled doesn't tell us anything about the software architecture, your statement reads as if its a critique.

I didn't think he was criticising anything.

I was indeed praising him. 2) he used html/js, and i'm glad flash isn't needed to make such a tool 3) i was happy it's fast enough. 4)no u misunderstood; i pressed ctrl+u and have seen the source code, indeed. it's an empty body with few JS files. I find it remarkable as HTML's document centric approach with viewable document structure disappeared from view and moved into the JS files.

What does right click have to do with anything? The HTML source code for the page is 25 lines long and contains no markup at all. Which is not a critique, of course :)

Wow, everything he said was actually praise or just neutral comments. You are trying to argue about something that doesn't exist.

Source code: https://github.com/quasado/gravit

You might consider overriding the delete/backspace button. I tried to delete a spline and ended up back on hacker news :-)

It's definitely one of those web apps where I'd be totally fine with a `window.onbeforeunload` popup asking me whether I really want to leave.

Has anyone here manage to figure out the secrets behind this apps blazing fast performance ?

https://github.com/quasado/gravit

Load performance is mostly due to the few number of files that are being included, though minification also helps.

Application performance is typical of modern, hand-coded JS. Or rather, I should say, the only reason I can see for why people tolerate bloated frameworks is because they've just come to expect JS to be slow. There is a reason some of us insist on sticking to vanilla JS. It's not because we're crotchety, old, greybeards. We wouldn't be touching JS at all if that were the case.

It appears they might also be using layered canvases to render different parts of the workspace that update at different rates. So that prevents them from having to redraw the checkered background every time you move the drawing. And it prevents them from having to redraw the existing drawing every time you add a new element and are still adjusting it.

Pretty standard techniques for anyone with experience working with Canvas, actually.

JS is very fast in modern browsers. It blows things like Python and PHP out of the water, it competes with Go, and with asm.js (or sometimes without) it can be like merely 2x slower than C.

The main reason most web apps don't also feel very fast is not "DOM manipulation" or things that happen inside the page, is that they also do AJAX network calls and that adds huge latencies.

This app, judging the functionality, does everything inside the VM (no need to do AJAX calls for a drawing app), so can offer the full speed JS can do.

Congrats on the great job. Nobody would raise an eyebrow for this work if it were not browser-based. Does this say something about the state of web apps?

For offline usage, has anyone used both Gravit and Inkscape for any significant period of time, and can comment on pros/cons?

This might be a dumb question if they don't really occupy the same space. But naively it seems to me like they overlap somewhat, and maybe I should move some of what I currently do in Inkscape to Gravit? (I'm not all that proficient in Inkscape, and at first usage Gravit seems simpler.)

This is awesome!! Played around with it for awhile. Very snappy, great UI. Very functional! Well done.

I couldn't click on the Save item in the File menu.

It's a demo...

I'm impressed with the responsiveness on the iPad, it feels like a native app!

Same on n7. Developer should phonegap this thing and drum up some revenue on the app stores, OSS or not.

Nice interface. I'm trying to get better at very quickly implementing UI's from the ground up (also moving past bootstrap/foundation). What was your approach to making this interface? Did you use a pre-processor? Did you modify an existing framework or generate css output from a photoshop mockup? Thanks.

This is very good. I think it's designed to be an Adobe Fireworks replacement. Great stuff!

Nice work! It might be cool to allow people to share designs. So if I was creating a web page, I could browse through web pages other people have created and import one, then use that as a foundation for my own design. At any rate, this is pretty cool.

This is kinda cool, and might help out the web crowd which is working with Chrome OS at the moment.(I'm writing this comment on a Chromebook right now)

Why anyone would use this rather than inkscape on either Linux or Windows, however, is beyond me.

I was looking for something similar frantically the other day when I couldn't use pixlr (it needs flash and my laptop was very old).

But, how do I insert an image from my computer as the layer?

Has a nice UI (albeit cloned from Photoshop).

Save/Export doesn't seem to work on my machine (Chrome 37, Mac OSX).

Would be nice to see some kind of SVG export instead of raster formats.

There's an intro to the app on their blog. Sounds like they were going for Freehand/Fireworks rather than Photoshop :)

All saving also disabled for me, guessing the back end isn't quite there yet.

That loaded much faster than expected. I'd very much like a peek at the code (could not find a link to Github or Google Code).

https://github.com/quasado/gravit

Found on http://gravit.io/, upper right corner.

Fantastic...have a similar initiative though of a little different flavor. Will share soon.

All the best

This is great. I could see it replacing much of my Illustrator work.

Just wondering, why is the title of this submission allowed to remain as "Gravit - Open-source design tool"? Under HN's dogmatic rules, shouldn't it be renamed to just "Gravit"?

While this was once a problem, your information is like 6 months out of date. The mods have been pretty good at balancing "informative" and "close to the original submission". pg even said that the way the rules were being interpreted weren't the way they were originally intended.

Trash buttons don't work.

This is not open source! this is free software

GPL

https://github.com/quasado/gravit/blob/master/LICENSE

I think he means free software as defined by the FSF, which has different definitions for free-of-cost, open source and free/libre software.

I came expecting a free alternative to something like AutoCAD. Instead I got a blank page, and after reloading with JS enabled, a core dump from a browser that ran out of memory.

For a snappy drawing program, native code remains the way to go.

I disagree, this is really fast and totally rivals a native app. What are you computer specs and what browser are you using?

Do you disagree with the core dump on my hard drive? Firefox 31 ESR, Atom N450, 1G of RAM. Gimp for instance runs pretty smooth (although there are much faster still options if you don't need all the features); I use it a lot.

I disagree with your statement that native code is the way to go for snappy drawing apps, maybe for low end hardware like what you're using but for more powerful hardware there is no downside.

>Do you disagree with the core dump on my hard drive?

No, he and I disagree that your experience is typical for everybody. Most people in this thread (including me) praised this for its quick loading, snapiness and speed.

Perhaps "Atom" and "1GB of RAM" doesn't cuts it for this kind of in-browser app, despite GIMP (a native app) running "pretty smooth). It makes sense if this has a minimum memory use requirement -- below which you can't run it at all because you don't have enough space that it needs to load, and after which you're OK and it's fast.

That said, people have run it on their iPads, and it's extremely snappy there too.

I'm also not sure the core dump was because of "out of memory". How about some glitch with your graphics card driver and the canvas renderer (which is not uncommon)?

> I'm also not sure the core dump was because of "out of memory".

  out of memory: 0x0000000000020000 bytes requested
  Segmentation fault (core dumped) 
  [..]
  #0  0x0000097c6124c82a in kill () at <stdin>:2
  #1  0x0000097c74ed6fd4 in XRE_FreeAppData ()
     from /usr/local/lib/firefox-esr-31.0/libxul.so.1.0
  #2  <signal handler called>
  #3  0x0000097cd08b6957 in mozalloc_abort ()
     from /usr/local/lib/firefox-esr-31.0/libmozalloc.so.1.0
  #4  0x0000097cd08b6a07 in mozalloc_handle_oom ()
     from /usr/local/lib/firefox-esr-31.0/libmozalloc.so.1.0
  #5  0x0000097cd08b6707 in moz_xmalloc ()
     from /usr/local/lib/firefox-esr-31.0/libmozalloc.so.1.0
  #6  0x0000097c73667172 in NS_CycleCollectorSuspect3 ()
     from /usr/local/lib/firefox-esr-31.0/libxul.so.1.0
  #7  0x0000097c736624d0 in NS_DebugBreak ()
     from /usr/local/lib/firefox-esr-31.0/libxul.so.1.0
  #8  0x0000097c73660702 in NS_DebugBreak ()
     from /usr/local/lib/firefox-esr-31.0/libxul.so.1.0
  #9  0x0000097c75548bf9 in js::IterateGrayObjects ()
     from /usr/local/lib/firefox-esr-31.0/libxul.so.1.0
  #10 0x0000097c7554f8a5 in js::IterateGrayObjects ()
     from /usr/local/lib/firefox-esr-31.0/libxul.so.1.0
  #11 0x0000097c7555242c in js::IterateGrayObjects ()
     from /usr/local/lib/firefox-esr-31.0/libxul.so.1.0
  #12 0x0000097c7365e71f in NS_DebugBreak ()
  ---Type <return> to continue, or q <return> to quit---
     from /usr/local/lib/firefox-esr-31.0/libxul.so.1.0
  #13 0x0000097c7365e644 in NS_DebugBreak ()
     from /usr/local/lib/firefox-esr-31.0/libxul.so.1.0
  #14 0x0000097c73661e9c in NS_DebugBreak ()
     from /usr/local/lib/firefox-esr-31.0/libxul.so.1.0
  #15 0x0000097c736634ed in NS_DebugBreak ()
     from /usr/local/lib/firefox-esr-31.0/libxul.so.1.0
  #16 0x0000097c73664d0d in NS_DebugBreak ()
     from /usr/local/lib/firefox-esr-31.0/libxul.so.1.0
  #17 0x0000097c73665d7f in NS_CycleCollectorSuspect3 ()
     from /usr/local/lib/firefox-esr-31.0/libxul.so.1.0
  #18 0x0000097c74474d6a in DumpCompleteHeap ()
     from /usr/local/lib/firefox-esr-31.0/libxul.so.1.0
  #19 0x0000097c74475cdc in DumpCompleteHeap ()
     from /usr/local/lib/firefox-esr-31.0/libxul.so.1.0
  #20 0x0000097c736b2fcb in XRE_AddJarManifestLocation ()
     from /usr/local/lib/firefox-esr-31.0/libxul.so.1.0
  #21 0x0000097c736b3135 in XRE_AddJarManifestLocation ()
     from /usr/local/lib/firefox-esr-31.0/libxul.so.1.0
  #22 0x0000097c736b006d in XRE_AddJarManifestLocation ()
     from /usr/local/lib/firefox-esr-31.0/libxul.so.1.0
  #23 0x0000097c73648291 in ?? ()
     from /usr/local/lib/firefox-esr-31.0/libxul.so.1.0
  ---Type <return> to continue, or q <return> to quit---
  #24 0x0000097c738b8006 in std::vector<std::pair<int, int>, std::allocator<std::pair<int, int> > >::_M_insert_aux ()
     from /usr/local/lib/firefox-esr-31.0/libxul.so.1.0
  #25 0x0000097c73888ec9 in std::_Rb_tree<int, std::pair<int const, std::string>, std::_Select1st<std::pair<int const, std::string> >, std::less<int>, std::allocator<std::pair<int const, std::string> > >::_M_erase ()
     from /usr/local/lib/firefox-esr-31.0/libxul.so.1.0
  #26 0x0000097c7431f7fe in js::BaseProxyHandler::finalizeInBackground ()
     from /usr/local/lib/firefox-esr-31.0/libxul.so.1.0
  #27 0x0000097c74f0bf93 in XRE_StartupTimelineRecord ()
     from /usr/local/lib/firefox-esr-31.0/libxul.so.1.0
  #28 0x0000097c74ecd2ea in XRE_InitCommandLine ()
     from /usr/local/lib/firefox-esr-31.0/libxul.so.1.0
  #29 0x0000097c74ecd4d1 in XRE_InitCommandLine ()
     from /usr/local/lib/firefox-esr-31.0/libxul.so.1.0
  #30 0x0000097c74ecd8b6 in XRE_main ()
     from /usr/local/lib/firefox-esr-31.0/libxul.so.1.0
  #31 0x0000097a4a703f87 in atexit () from /usr/local/bin/firefox-esr
  #32 0x0000097a4a7038b1 in _start () from /usr/local/bin/firefox-esr
  #33 0x0000000000000000 in ?? ()

Fair enough!

Try loading it in Safari - it works very nicely for me.

I'm running Opera on NetBSD 6.1 and it's faster than some native X11 apps. what's your point?

Reply on news.ycombinator.com