nishkalkashyap

Great job explaining that. I couldn't have said that well myself. :P. That's exactly what it is.

It's not an electron IDE like VSCOde or Atom. But an IDE and a JavaScript runtime that helps you build and run electron applications.

~100Kb*

Only as much as is the actual application logic and bundled dependencies. Which for most cases is usually a few kilobytes or a megabyte. You can checkout the Quark appstore (https://dash.quarkjs.io/). None of the apps is above 2MB.

I would recommend distributing binaries from a dedicated release server combined with a CDN. Possibly digital ocean spaces. It really increases download speeds for end user as compared to gitHub releases.

For my project (quarkjs.io), I went for https://comodosslstore.com . They have the cheapest certificates I could find (at ~75USD), also they are the only ones issuing certificates for individual developers.

No. Code signing is very different. Checksum would only work for developers on linux. Without code signing certificate, MacOS would straight refuse to run the app and windows will show an 'Unverified publisher' warning. Also things like auto-updates do not work on either platform unless you code sign your binaries.

I've submitted a response on GitHub.

I would recommend code-signing the build before distributing.

Yes. You are right here. It does takes away from version control systems. But the thing is that this functionality is not forced upon you. You can still choose to code in your real file system, and use Quark only as a runtime.

Nope. I believe they claim to do almost the same thing. But this project never took off.

If their software product feels threatened by something that a developer came out of his basement. Perhaps it's time for them to rethink their entire strategy.

I would disagree. What Quark offers is much more. You don't have to learn a new language. You have access to this massive javascript ecosystem. And it has out of the box support for React.js, Vue.js, Typescript and toolings like webpack that developers love.

Well the first difference here is that Quark is a free software, Adobe Air is not.

I din't know enough about adobe Air to comment on technical differences, but one thing that strikes me is that electron(as hence Quark) appears to be more popular than Adobe Air.

I had that initially on my road-map and that surely could be done. I have a few ideas on how to implement a "no runtime found" situation, but that is not happening in near future.

Thanks. :)

While all of that is true, it is also incredibly powerful, giving you access to all of the Node.js and electron's API. Plus very flexible with the tools of your choice as we use webpack behind the scenes to build your projects.

> It looks great, and I understand the use-case. But the downside I see is that while Quark is lightweight it still has a ton of dependencies.

We have a ton of dependencies so that you can get out of the box support for most of your projects. With React, Vue , Webpack(+ common loaders), Babel(+common plugins) e.t.c and Quark's internal dependencies, the package still weighs uncompressed ~300mb. Now compare that with an average node_modules folder on your machine. You get the picture. If you still can't justify the dependencies, open a pull request on the git repo and we can debate which dependencies are allowed to stay. :P

> It still doesn’t allow you to easily share your dashboard with other internal users (unless they have the same Quark environment), does it?

You are right there, you cannot share projects built with Quark unless they have Quark installed on your machine. Just the case you have with Node.js or python or any other runtime.

> Why is this being promoted as a feature? Of course you wouldn't want to make a copy of GUI framework for each user's project. That's quite a stretch for a per-project config files advertisement.

I'm not sure what you mean by this comment. But I do think that that's a reasonable thing to say.?

Well that's a very thoughtful question and I'm glad you made it. I literally woke up from sleep to answer it. Let me take them one by one.

> sketches are effectively extensions installed over quark, much like VS-Code extensions. They come with the same advantages, and drawbacks of being tied down to what the "platform" offers, the platform being Quark. If quark makes opinionated decisions on architecture, you're limited by it

I can see the concern there, but electron's API has been quite stable, at least since the past year. Also, Quark proxys electron's most common API's like creating dialog, notifications e.t.c So maintaining backward compatibility with electron's API is our headache.

> uncompressing to an in memory file system and using that as the app binary unnecessarily increases RAM/CPU footprint

Since Quark is designed for personal/prototyping projects, we are hardly talking in a few files here. Which would hardy take a few kilobytes. I would argue it is as efficient as other online IDE's.

> each "sketch" is likely to spawn it's own JavaScript node context.......

Yes you can compare it to a "new chrome tab". It only takes one process(by default, although you can spawn more) and memory mainly depending upon your DOM code.

As far as "same resource as a single electron app" comment goes. I made that in the context on having multiple electron apps installed on your machine. Even 2 electron apps on your machine could weigh about 600mb. On the other side, Quark with a 100 other sketches on your machine would weigh about 400mb (assuming 1 sketch=~1mb). Given the fact that these sketches have full functionality as of an electron app, I believe this was a reasonable statement to make. Now, I'm not talking about running all those sketches, all at once because that would be a whole different thing.