11–20 of 43 posts
The github repo is the website code only (https://quarkjs.io/FAQ/license.html).
Looks like lots of work has gone into the project, but so far it's a black box. Is the goal for this to be a commercial product?
Note for OP. Quark seems like an SEO deathblow to a project. Seems best to rename and give the project a chance?
- 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
- uncompressing to an in memory file system and using that as the app binary unnecessarily increases RAM/CPU footprint
- each "sketch" is likely to spawn it's own JavaScript node context, at the very least. Maybe even it's own chrome content context, for isolation and security purposes. How exactly does this take the same resource as a single electron app? The likely increase is comparable to [New Chrome Tab + Node context]. It's lower than a whole new electron app, but probably averages 60MB-ish in RAM, and the overhead of 2-3 new precesses
- sketches will have a dependency on the electron version used by Quark - 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 - uncompressing to an in memory file system and using tha…
> 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.
Note for OP. Quark seems like an SEO deathblow to a project. Seems best to rename and give the project a chance?
So was Kafka, but in the opposite direction. Results about Apache Kafka have seriously polluted the search results making it a lot harder to filter out pages not related to the novelist. Something is very wrong when the top result for "Kafka" is some software. Do you want to live in world where you kids google "Socrates" "Beethoven" and some software project shows up on top?
Not necessarily. If the software is more discussed on the net than the man it's named for, then perhaps that would be best?
> Do you want to live in world where you kids google "Socrates" "Beethoven" and some software project shows up on top?
You can bet your ass that if we had internet the way we do today in the early 90's that if you searched for Beethoven the first result would have been the dog movie.
Interestingly, I had an edutainment console called Socrates when I was young and it's very hard to find information on.
> Your sketches provide you with all the capabilities of full fledged electron apps. The only difference here is that they just weigh a few kilobytes instead of hundreds of megabytes. We achieve this functionality by using a shared JavaScript runtime for all your sketches. 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 stret…
I'm not sure what you mean by this comment. But I do think that that's a reasonable thing to say.?
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. It still doesn’t allow you to easily share your dashboard with other internal users (unless they have the same Quark environment), does it? Perhaps I’m wrong. Anyway, it’s nicely done.
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.
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. It still doesn’t allow you to easily share your dashboard with other internal users (unless they have the same Quark environment), does it? Perhaps I’m wrong. Anyway, it’s nicely done.
It's not for product development, AFAICT. It's a quick scripting / prototyping / scratch-your-itch environment. And for that purpose it looks quite good, resembling the most productive Lisp and Smalltalk environments, but with more easily separable single-file "projects". It also looks like a great environment to teach programming past toy-level environments like MIT Scratch.