> ...felt a need for a software tool that would help me do things like — plot charts, app prototyping, create dashboards/GUI’s for my personal projects etc. I just needed “some place” to write my code, build small projects or test new ideas. To much of my own surprise, I could not find an easy way to do so.
to the author: Congrats on building and delivering on what's a pretty significant undertaking.
That being said, Smalltalk has had the capabilities you were looking for, for ages, and the tools are incredibly polished because they've been around for so long. On a related note Glamorous Toolkit https://gtoolkit.com/ takes those capabilities and points them at development itself allowing you to use them to help figure out what your code and data are / are doing.
This is an interesting project, but it's just the beginning of recreating what already exists in Pharo smalltalk. https://pharo.org/
That would involve starting from scratch learning a new language and framework, and projects could no longer graduate to be web apps, or benefit from the much larger Javascript/web ecosystem.
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.
- 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 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
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.
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?
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?
> 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.
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.
> files you create inside the IDE are virtual files with no foot print on your real file system. This is done to make sharing a project as easy as sharing a single file.
This sounds like it would prevent the proper use of version control systems like git, which seems like a terrible idea. Is my interpretation correct?
It seems like it would be better to develop with normal files (and the decades of powerful tools that can operate on them), and then bundle into one file for distribution.
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.
Congratulations on your release! With Adobe Air you could make executables with html/css/js (or flash). End users had to have the Adobe Air runtime installed to run the apps. Can you help understand if the concept you have here is much different than, or much the same as the Adobe Air concept?
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.
Sounds amazing. How do I distribute my Quark application? Is there a way to bundle a sketch as an executable that will look for a suitable Quark runtime and if not found, run an installer?
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.
„Quark comes built in with a powerful code-editor. The same code editor that powers the VS Code (monaco-editor). This means you get out of the box support for Intellisense, code completion, “Go to Definition”, reference search and Quick navigation (Cmd+P).”
> 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 stretch for a per-project config files advertisement.
I would suggest adding "Show HN" tag, and "JS" somewhere in
the title.
> 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.?
[+] [-] masukomi|6 years ago|reply
to the author: Congrats on building and delivering on what's a pretty significant undertaking.
That being said, Smalltalk has had the capabilities you were looking for, for ages, and the tools are incredibly polished because they've been around for so long. On a related note Glamorous Toolkit https://gtoolkit.com/ takes those capabilities and points them at development itself allowing you to use them to help figure out what your code and data are / are doing.
This is an interesting project, but it's just the beginning of recreating what already exists in Pharo smalltalk. https://pharo.org/
[+] [-] mkl|6 years ago|reply
[+] [-] nishkalkashyap|6 years ago|reply
[+] [-] writepub|6 years ago|reply
- 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
[+] [-] nishkalkashyap|6 years ago|reply
> 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.
[+] [-] CameronBanga|6 years ago|reply
[+] [-] cschmidt|6 years ago|reply
http://www.quark.com/About_Quark/Legal/
[+] [-] benjaminbrodie|6 years ago|reply
[+] [-] floki999|6 years ago|reply
Perhaps I’m wrong. Anyway, it’s nicely done.
[+] [-] nishkalkashyap|6 years ago|reply
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.
[+] [-] nine_k|6 years ago|reply
It also looks like a great environment to teach programming past toy-level environments like MIT Scratch.
[+] [-] mkl|6 years ago|reply
This sounds like it would prevent the proper use of version control systems like git, which seems like a terrible idea. Is my interpretation correct?
It seems like it would be better to develop with normal files (and the decades of powerful tools that can operate on them), and then bundle into one file for distribution.
[+] [-] nishkalkashyap|6 years ago|reply
[+] [-] jdnier|6 years ago|reply
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?
[+] [-] tones411|6 years ago|reply
[+] [-] nishkalkashyap|6 years ago|reply
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.
[+] [-] ilaksh|6 years ago|reply
[+] [-] nishkalkashyap|6 years ago|reply
[+] [-] insomniacity|6 years ago|reply
[+] [-] rad_gruchalski|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] knubie|6 years ago|reply
[+] [-] nishkalkashyap|6 years ago|reply
[+] [-] PhantomBKB|6 years ago|reply
[+] [-] nishkalkashyap|6 years ago|reply
[+] [-] n4bz0r|6 years ago|reply
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 would suggest adding "Show HN" tag, and "JS" somewhere in the title.
[+] [-] nishkalkashyap|6 years ago|reply
I'm not sure what you mean by this comment. But I do think that that's a reasonable thing to say.?