4 ms·

Show HN: A simple cross-platform HTML to desktop-app builder using Chrome

4 points by graderjs 5y ago

graderjs 5y ago
This is a simple, "electron alternative" (non-compatible API) and missing many cool things like "binary icons", and code signing etc. Like electron it has "client code" that runs in the "render process" (the browser, in this case, already on the system), and "main" code (in this case a server). Basically a bootstrap process starts the server, and the browser in "app" mode (so it looks almost like a 'native' desktop app), and renders the server's page in the browser. So the app architecture is basically a locally hosted "client-server" app that is bundled up in a single binary. It's built and based on the simple premise that most everyone has a browser installed (and if you don't we download Chrome ~~ not great for some of you, I know), and so we use the browser with the `--app` command line flag to remove any normal browser UI chrome (omnibox etc), and just have a GUI window. I'm looking to extensively update it this year to support pkg [a NodeJS -> binary tool by Vercel] (which will introduce code-signing and possibly more including, icons, almost for free). I'd also like to alter the API a bit, and eventually plan on building out a "chrome extensions" type of API but that lives outside the "purview" of the Chrome webstore. So people can basically build augmented browser "extension-like" experiences, but package them as binaries. Of course, security nightmare, I know...but no different to other binary apps. I even want to have a "store", because I like the idea of adopting all the trouble that the Chrome webstore must face, with vetting, security audits etc...I say this only half jokingly. I think it would be a good challenge, but at the same time a massive and daunting one. My first approximation for a metric of inclusion is: your code must be open source on GitHub. Anyhow, the store is basically ancillary to the platform for devs idea, where they can use the tool to build and distribute their own apps. Then I want to port some of my "popular" (1000s of stars, hey it's OK) GitHub projects that involve the browser, to this graderjs "architecture" -- to really prove that non-trivial things can work there, and as a way of stretching out and improving the graderjs API. The thing that excites me most about this project is: - the potential (old idea, been done before) to use the already installed browser (not the system webview, using a browser has advantage of both a simpler integration and more cross-platform homogeneity), as the GUI render layer to enable HTML, JS (and anything really, with wasm) as the client language. Plus enabling you to run a NodeJS server, and all the APIs. - eventually I'd love to extend this to: support other browsers (Firefox, Edge, etc...) should be possible by waiting for them all to catch up with the [webdriver] spec, or by using Playwright or some other abstraction for that instrumentation layer in the graderjs tool; also to support other server side languages. Like there are tools that exist to build binaries for python, etc, etc, etc, and equivalents of the WebDriver abstraction (like Puppeteer, and Playwright) in those languages--so why can't we just swap out NodeJS on the local server for something else? I think we can. - also I would love to really build a rich "extensions"-like API that does even more than extensions can do, centers the browsers as a first-class target for running local app code, and runs by a combination of: WebDriver protocol (e.g. the Chrome Remote DevTools protocol being the current most powerful and elaborated implementation of a similar concept); and a local app running from a language of your choice (say, NodeJS, with all its access to filesystem APIs) to flesh out the limitations of what you can do with just WebDriver alone. So basically having the "GraderJS" project be an extensible "GraderX" project that makes it possible to write a desktop app using server-client arch that runs locally, HTML/JS/CSS as GUI and fully integrates with the OS...would I think radically simplify development. I'm not saying it's game-changing even if I can do that...but it will be game-changing for me. I really want this...and I'm not satisfied with other current options. It's a little annoying that it won't be able to run as a "mobile" app for now...but that's OK. I just want to try and see if this is possible. This is one plan I have, and hopefully I will get to it, or a lot of it, in 2022! [webdriver]: https://github.com/w3c/webdriver https://github.com/w3c/webdriver
- rasengan 5y ago
  I think you're on to something great here. Keep it up!
  - deleted 5y ago
    [deleted]
  - graderjs 5y ago
    Thank you! BTW - I added a Sponsor button to the repo just now inspired by your comment, if you cared to contribute!! :D

4 points by graderjs 5y ago

This is a simple, "electron alternative" (non-compatible API) and missing many cool things like "binary icons", and code signing etc. Like electron it has "client code" that runs in the "render process" (the browser, in this case, already on the system), and "main" code (in this case a server). Basically a bootstrap process starts the server, and the browser in "app" mode (so it looks almost like a 'native' desktop app), and renders the server's page in the browser. So the app architecture is basically a locally hosted "client-server" app that is bundled up in a single binary. It's built and based on the simple premise that most everyone has a browser installed (and if you don't we download Chrome ~~ not great for some of you, I know), and so we use the browser with the `--app` command line flag to remove any normal browser UI chrome (omnibox etc), and just have a GUI window. I'm looking to extensively update it this year to support pkg [a NodeJS -> binary tool by Vercel] (which will introduce code-signing and possibly more including, icons, almost for free). I'd also like to alter the API a bit, and eventually plan on building out a "chrome extensions" type of API but that lives outside the "purview" of the Chrome webstore. So people can basically build augmented browser "extension-like" experiences, but package them as binaries. Of course, security nightmare, I know...but no different to other binary apps. I even want to have a "store", because I like the idea of adopting all the trouble that the Chrome webstore must face, with vetting, security audits etc...I say this only half jokingly. I think it would be a good challenge, but at the same time a massive and daunting one. My first approximation for a metric of inclusion is: your code must be open source on GitHub. Anyhow, the store is basically ancillary to the platform for devs idea, where they can use the tool to build and distribute their own apps. Then I want to port some of my "popular" (1000s of stars, hey it's OK) GitHub projects that involve the browser, to this graderjs "architecture" -- to really prove that non-trivial things can work there, and as a way of stretching out and improving the graderjs API. The thing that excites me most about this project is: - the potential (old idea, been done before) to use the already installed browser (not the system webview, using a browser has advantage of both a simpler integration and more cross-platform homogeneity), as the GUI render layer to enable HTML, JS (and anything really, with wasm) as the client language. Plus enabling you to run a NodeJS server, and all the APIs. - eventually I'd love to extend this to: support other browsers (Firefox, Edge, etc...) should be possible by waiting for them all to catch up with the [webdriver] spec, or by using Playwright or some other abstraction for that instrumentation layer in the graderjs tool; also to support other server side languages. Like there are tools that exist to build binaries for python, etc, etc, etc, and equivalents of the WebDriver abstraction (like Puppeteer, and Playwright) in those languages--so why can't we just swap out NodeJS on the local server for something else? I think we can. - also I would love to really build a rich "extensions"-like API that does even more than extensions can do, centers the browsers as a first-class target for running local app code, and runs by a combination of: WebDriver protocol (e.g. the Chrome Remote DevTools protocol being the current most powerful and elaborated implementation of a similar concept); and a local app running from a language of your choice (say, NodeJS, with all its access to filesystem APIs) to flesh out the limitations of what you can do with just WebDriver alone. So basically having the "GraderJS" project be an extensible "GraderX" project that makes it possible to write a desktop app using server-client arch that runs locally, HTML/JS/CSS as GUI and fully integrates with the OS...would I think radically simplify development. I'm not saying it's game-changing even if I can do that...but it will be game-changing for me. I really want this...and I'm not satisfied with other current options. It's a little annoying that it won't be able to run as a "mobile" app for now...but that's OK. I just want to try and see if this is possible. This is one plan I have, and hopefully I will get to it, or a lot of it, in 2022! [webdriver]: https://github.com/w3c/webdriver https://github.com/w3c/webdriver

rasengan 5y ago
I think you're on to something great here. Keep it up!
- deleted 5y ago
  [deleted]
- graderjs 5y ago
  Thank you! BTW - I added a Sponsor button to the repo just now inspired by your comment, if you cared to contribute!! :D