> ...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.
Yep, Quark has been used for page layout and typesetting since the 80s. They do web layout now also, so this js project seems to have some overlap potential.
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.
IANAL, but from what I can gather (at least with the USPTO in the USA), a trademark can be weakened and even lost when not properly monitored and/or enforced. It would be unwise for any business to fail to protect their trademark(s).
I don't know what country you're in, but they're in the US, and their lawyers are legally obligated to defend their trademarks against all violations, or they risk losing the trademark. So they will. Trademark use is by category, so you might be able to start a business called Quark Cupcakes, but you're both doing software, so it is a clear violation.
It is really hard to find a good name, and obviously it is your choice to stick with Quark. However, I do expect you'll get a cease and desist letter unless you change the name.
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?
> Something is very wrong when the top result for "Kafka" is some software.
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.
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.
That’s the tricky bit - for anyone who is technical amongst a non-technical team, where you can’t expect or rely colleagues to deal with the environment. Same goes for Jupiter Noteboks and similar solutions. This is so why, in my opinion, Excel VBA has been successful, in that everyone has it by default and it is easy to distribute solutions or demo’s.
Anyway, what you’ve achieved is really cool. Thanks for sharing.
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.
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.
> 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.
I'm pretty sure Adobe Air is free. And Electron is only popular among developers, whereas Air is a runtime for end users. Not saying you should use Air, just that I think what you are building has been built before. I do applaud you for the work, though.
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.?
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/