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.
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.
Are you the creator of Gravit.io? If not, then your response is useless, because nobody asked YOU that.
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.
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.
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.
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.
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.)
Why anyone would use this rather than inkscape on either Linux or Windows, however, is beyond me.
But, how do I insert an image from my computer as the layer?
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.
All saving also disabled for me, guessing the back end isn't quite there yet.
Found on http://gravit.io/, upper right corner.
All the best
For a snappy drawing program, native code remains the way to go.
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)?
out of memory: 0x0000000000020000 bytes requested
Segmentation fault (core dumped)
#0 0x0000097c6124c82a in kill () at <stdin>:2
#1 0x0000097c74ed6fd4 in XRE_FreeAppData ()
#2 <signal handler called>
#3 0x0000097cd08b6957 in mozalloc_abort ()
#4 0x0000097cd08b6a07 in mozalloc_handle_oom ()
#5 0x0000097cd08b6707 in moz_xmalloc ()
#6 0x0000097c73667172 in NS_CycleCollectorSuspect3 ()
#7 0x0000097c736624d0 in NS_DebugBreak ()
#8 0x0000097c73660702 in NS_DebugBreak ()
#9 0x0000097c75548bf9 in js::IterateGrayObjects ()
#10 0x0000097c7554f8a5 in js::IterateGrayObjects ()
#11 0x0000097c7555242c in js::IterateGrayObjects ()
#12 0x0000097c7365e71f in NS_DebugBreak ()
---Type <return> to continue, or q <return> to quit---
#13 0x0000097c7365e644 in NS_DebugBreak ()
#14 0x0000097c73661e9c in NS_DebugBreak ()
#15 0x0000097c736634ed in NS_DebugBreak ()
#16 0x0000097c73664d0d in NS_DebugBreak ()
#17 0x0000097c73665d7f in NS_CycleCollectorSuspect3 ()
#18 0x0000097c74474d6a in DumpCompleteHeap ()
#19 0x0000097c74475cdc in DumpCompleteHeap ()
#20 0x0000097c736b2fcb in XRE_AddJarManifestLocation ()
#21 0x0000097c736b3135 in XRE_AddJarManifestLocation ()
#22 0x0000097c736b006d in XRE_AddJarManifestLocation ()
#23 0x0000097c73648291 in ?? ()
---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 ()
#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 ()
#26 0x0000097c7431f7fe in js::BaseProxyHandler::finalizeInBackground ()
#27 0x0000097c74f0bf93 in XRE_StartupTimelineRecord ()
#28 0x0000097c74ecd2ea in XRE_InitCommandLine ()
#29 0x0000097c74ecd4d1 in XRE_InitCommandLine ()
#30 0x0000097c74ecd8b6 in XRE_main ()
#31 0x0000097a4a703f87 in atexit () from /usr/local/bin/firefox-esr
#32 0x0000097a4a7038b1 in _start () from /usr/local/bin/firefox-esr
#33 0x0000000000000000 in ?? ()