4 ms·

Instead of HTML, can’t JavaScript just be used to paint the browser canvas? You can create your text boxes, your drop downs, buttons, etc., everything that mak

Instead of HTML, can’t JavaScript just be used to paint the browser canvas? You can create your text boxes, your drop downs, buttons, etc., everything that makes it a GUI application. Then you fetch your data, per the page you display, via JSON, and fill in the fields. The initial JavaScript download is heavy, but the normal usage of the web application should be quicker, as you’re only fetching the relevant data to fill each of the required widgets. This does sound resource intensive, for computers back in the 1990s, but today’s iPad, iPhone, and modern laptop computers should be powerful enough to handle it. Or did I just describe some already popular JavaScript framework?

anonytrary 6y ago
I think you just described the browser. While there are some efforts to do canvas-only rendering in JS, they aren't mature and are meant for specific use-cases like game boards and stock charts. For a typical website, this approach would likely have negative implications for your site's accessibility and usability; the site would also be harder to index.
- blackrock 6y ago
  That’s correct. I was thinking more along the lines of video games and interactive stock charts. But as an easier way to develop GUI applications via JavaScript. Perhaps where the widget definitions are described via an easier, LISP like syntax, and rendered by the Framework. Kind of like Emacs Lisp. Actually, it might have been amazing if the original Netscape browser shipped with a Emacs Lisp like scripting tool to begin with. But instead, we got JavaScript.
gear54rus 6y ago
You described an SPA. Fetch relevant data and render to controls. Not sure why we need canvas for that.
- blackrock 6y ago
  You are correct. I just inadvertently re-invented React.
  - winrid 6y ago
    React is a view engine and isn't using the canvas. React pretty much is just a fast way to determine what to re-render on a page as a result of a state change.
triceratops 6y ago
> You can create your text boxes, your drop downs, buttons, etc., everything that makes it a GUI application. The browser gives you all that for free, just by writing some HTML. And allows your website to be accessible and indexable. It seems like a lot of work to re-implement that, for little benefit. It doesn't seem worth the hassle, but maybe there's something I've overlooked. > normal usage of the web application should be quicker, as you’re only fetching the relevant data to fill each of the required widgets...Or did I just describe some already popular JavaScript framework? Every popular JS framework already does all of this.
hutzlibu 6y ago
"The initial JavaScript download is heavy" Is 64 kb heavy? There is a graphic libary, that (partly) tries to accomplish this. (but did not really take off) lib.ivank.net/ Basically the idea was to replace the DOM with a canvas and then create elements in it, like you did in flash. If it would have matured, you probably could have then used Flex, which is a flash libary, similar to the DOM, but much cleaner. (but flex is heavy, though) But apparently, no one thought it is worth it. Because, it would mean quite some work, to reimplement the DOM in a faster way ...
searchableguy 6y ago
> Instead of HTML, can’t JavaScript just be used to paint the browser canvas? Flutter does this for web support.
lawl 6y ago
> Instead of HTML, can’t JavaScript just be used to paint the browser canvas? Yes it can. Qt when compiled to web-assembly does this. It just uses a canvas as a framebuffer basically. [0] Going off on a tangent here. This is something I've been thinking about a lot lately. I wanted to build a cross platform app that also works in the browser. Especially as single developer maintaining multiple codebases just sucks. So the only real option seems to be to write it as a webapp. So I started, but personally, I just really can't stand the JS ecosystem. I basically see two ways here this could go. Either the we go the use-canvas-as-framebuffer route. Or we'll need small embeddable html/css engines so you can write your code once in your preferred language, where for native apps you access the engines DOM directly, and when compiled to WASM it 'syscall's it out to JS see e.g. go [1] Basically something like sciter[2]. [0] https://www.qt.io/web-assembly-example-slate https://www.qt.io/web-assembly-example-slate [1] https://www.godoc.org/syscall/js https://www.godoc.org/syscall/js [2] https://sciter.com/ https://sciter.com/
- blackrock 6y ago
  Interesting, this is more in line with what I was thinking of. But, JavaScript is such a poor language, that it’s a poor choice for rigorous software development. However, it is a good candidate for transpiling code to. I was thinking of bolting on an Lisp type of scripting language, which can transpile down to a rigorous subset of JavaScript, which then controls how the widgets behave in the browser. This way, the Lisp script can be used to control how the widgets are organized in the browser screen. How each widget gets its data, and how it interacts with other widgets on the screen. Basically, it becomes its own little GUI development environment. Then over time, a public library of Lisp functions can be made available, and easily integrated into your code, with recommendations on commonly accepted techniques to do something. But if you don’t like that, then you’re still free to reinvent your own new technique. Then over time, the superior nature of this system, becomes popular enough that the major browser vendors begin integrating the Lisp scripting engine as a first class library. And to improve efficiency, it can cut out JavaScript entirely, and just interact directly with the browser. So the Lisp engine should have the ability to both, transpile down to JavaScript for backwards compatibility, as well as to compile down to bytecodes that can be executed by the browser. This way, all the variant JavaScript ecosystems gets neutralized, since this new system, just sidesteps JavaScript completely. (Wait, I think I just described WebAssembly.) And then, a new variant of web-Lisp takes over the world. Excellent..

anonytrary 6y ago

I think you just described the browser. While there are some efforts to do canvas-only rendering in JS, they aren't mature and are meant for specific use-cases like game boards and stock charts. For a typical website, this approach would likely have negative implications for your site's accessibility and usability; the site would also be harder to index.

blackrock 6y ago
That’s correct. I was thinking more along the lines of video games and interactive stock charts. But as an easier way to develop GUI applications via JavaScript. Perhaps where the widget definitions are described via an easier, LISP like syntax, and rendered by the Framework. Kind of like Emacs Lisp. Actually, it might have been amazing if the original Netscape browser shipped with a Emacs Lisp like scripting tool to begin with. But instead, we got JavaScript.

gear54rus 6y ago

You described an SPA. Fetch relevant data and render to controls. Not sure why we need canvas for that.

blackrock 6y ago
You are correct. I just inadvertently re-invented React.
- winrid 6y ago
  React is a view engine and isn't using the canvas. React pretty much is just a fast way to determine what to re-render on a page as a result of a state change.

triceratops 6y ago

> You can create your text boxes, your drop downs, buttons, etc., everything that makes it a GUI application. The browser gives you all that for free, just by writing some HTML. And allows your website to be accessible and indexable. It seems like a lot of work to re-implement that, for little benefit. It doesn't seem worth the hassle, but maybe there's something I've overlooked. > normal usage of the web application should be quicker, as you’re only fetching the relevant data to fill each of the required widgets...Or did I just describe some already popular JavaScript framework? Every popular JS framework already does all of this.

hutzlibu 6y ago

"The initial JavaScript download is heavy" Is 64 kb heavy? There is a graphic libary, that (partly) tries to accomplish this. (but did not really take off) lib.ivank.net/ Basically the idea was to replace the DOM with a canvas and then create elements in it, like you did in flash. If it would have matured, you probably could have then used Flex, which is a flash libary, similar to the DOM, but much cleaner. (but flex is heavy, though) But apparently, no one thought it is worth it. Because, it would mean quite some work, to reimplement the DOM in a faster way ...

searchableguy 6y ago

> Instead of HTML, can’t JavaScript just be used to paint the browser canvas? Flutter does this for web support.

lawl 6y ago

> Instead of HTML, can’t JavaScript just be used to paint the browser canvas? Yes it can. Qt when compiled to web-assembly does this. It just uses a canvas as a framebuffer basically. [0] Going off on a tangent here. This is something I've been thinking about a lot lately. I wanted to build a cross platform app that also works in the browser. Especially as single developer maintaining multiple codebases just sucks. So the only real option seems to be to write it as a webapp. So I started, but personally, I just really can't stand the JS ecosystem. I basically see two ways here this could go. Either the we go the use-canvas-as-framebuffer route. Or we'll need small embeddable html/css engines so you can write your code once in your preferred language, where for native apps you access the engines DOM directly, and when compiled to WASM it 'syscall's it out to JS see e.g. go [1] Basically something like sciter[2]. [0] https://www.qt.io/web-assembly-example-slate https://www.qt.io/web-assembly-example-slate [1] https://www.godoc.org/syscall/js https://www.godoc.org/syscall/js [2] https://sciter.com/ https://sciter.com/

blackrock 6y ago
Interesting, this is more in line with what I was thinking of. But, JavaScript is such a poor language, that it’s a poor choice for rigorous software development. However, it is a good candidate for transpiling code to. I was thinking of bolting on an Lisp type of scripting language, which can transpile down to a rigorous subset of JavaScript, which then controls how the widgets behave in the browser. This way, the Lisp script can be used to control how the widgets are organized in the browser screen. How each widget gets its data, and how it interacts with other widgets on the screen. Basically, it becomes its own little GUI development environment. Then over time, a public library of Lisp functions can be made available, and easily integrated into your code, with recommendations on commonly accepted techniques to do something. But if you don’t like that, then you’re still free to reinvent your own new technique. Then over time, the superior nature of this system, becomes popular enough that the major browser vendors begin integrating the Lisp scripting engine as a first class library. And to improve efficiency, it can cut out JavaScript entirely, and just interact directly with the browser. So the Lisp engine should have the ability to both, transpile down to JavaScript for backwards compatibility, as well as to compile down to bytecodes that can be executed by the browser. This way, all the variant JavaScript ecosystems gets neutralized, since this new system, just sidesteps JavaScript completely. (Wait, I think I just described WebAssembly.) And then, a new variant of web-Lisp takes over the world. Excellent..