6 ms·

This is insanely cool! Looks really slick too, even in a mobile screen. jQuery?? I cannot imagine how difficult it is to not break this when you make the sligh

by mavili 3y ago

This is insanely cool! Looks really slick too, even in a mobile screen. jQuery?? I cannot imagine how difficult it is to not break this when you make the slightest change, hats off for managing with vanilla Javascript and jQuery! The best thing about React for me is to not have to worry about breaking the DOM or messing up with event handlers because some jQuery line, somewhere obscure is probably doing something funky that is really difficult to track down!

Intralexical 3y ago
Oh, wow. When this came up before, I don't know if I looked at the DOM, because I assumed you would do this type of thing by drawing pixels on a Canvas. It's actually made of HTML elements? That's impressive.
- Aaronmacaron 3y ago
  I too think it's very impressive but wouldn't it be even more impressive if it was made using canvas? It would mean that you would need to implement your own rendering loop and layout engine. You'd need to reimplement a lot of elements such as input fields or buttons. You get all of this for free when building on top of HTML/CSS.
  - noduerme 3y ago
    You do get a lot of UI elements for free, but styling them consistently and getting them to layout properly becomes a lot more difficult.
  - Intralexical 3y ago
    I think it would likely be more technically involved and complicated if it were made with `canvas`. But large blobs drawing to `canvas` aren't anything new at this point. The part that impressed me is doing it the simple way, using what the browser already provides, and getting it to work this well.
    - msephton 3y ago
      Synology DSM (the web interface for a Synology NAS) also constructs a desktop UI the HTML way.
  - onetom 3y ago
    It's hard to make that performant. As a reference, here is a browser-adapted version of the https://cuis.st/ https://cuis.st/ Smalltalk environment, which does its own rendering onto a canvas: https://github.com/nmingotti/The-Cuis-CookBook/wiki/Run-Cuis-in-the-Web-Browser.-%28SqueakJS%29 https://github.com/nmingotti/The-Cuis-CookBook/wiki/Run-Cuis...
    - MatthiasPortzel 3y ago
      It’s not performant if you’re using JavaScript APIs. But it’s also possible to write to a canvas with WebGL, which is hardware accelerated and is much faster than jQuery. I believe (although I can’t find a source for it now), that xterm.js used this strategy.
  - mrBurger 3y ago
    I dunno, once you write the renderer, you essentially have no limits to worry about. Working within the confines of HTML is way more impressive to me.
  - moffkalast 3y ago
    That would be pretty slow, but with WebGL it could work.
notso411 3y ago
[dead]
tambourine_man 3y ago
You can easily shoot yourself in the foot with jQuery (or direct DOM manipulation for that matter), but it's not that hard not to. It just requires some discipline, like most things. React is also far from foolproof and not worth the added complexity in most cases, IMO.
- smaudet 3y ago
  Convention over Configuration. That and types. The only framework that's useful to JS is a better static type check system (and none of this lets-make-the-whole-damn-runtime-slow to support X feature, looking at you TypeScript).
  - solumunus 3y ago
    Curious which TS features you’re referring to?
    - horacemorace 3y ago
      The level of easy facilitated in part by ts on synchronous is too damn high, for one.
  - Dylan16807 3y ago
    > and none of this lets-make-the-whole-damn-runtime-slow to support X feature, looking at you TypeScript TypeScript runtime? I don't think the deprecated code that sets up enum objects affects anything else...
    - smaudet 3y ago
      Not enums. But you don't need a runtime or function mutation for that... Particularly egregious was (is?) async/await. Upgrade your browser/runtime/don't use it you say? Sure, but first two weren't always possible, and the third isn't possible unless you thoroughly vet your dependencies (easier said than done). "Compiling to javascript" is all well and good if you actually just compile to normal javascript, as soon as you have any code that simulates other features (classes/objects/what-have-you) you are no longer "compiling to javascript". I mean yeah sure as a sort of intermediary assembly language you are but the performance is not the same. You have a new language with a runtime overhead, that now requires you modify the "core" language to bring in new features, which results in the underlying execution engines (browsers/cpus) becoming more complicated, power hungry, etc.... Anyways, type caching is not all bad. While the TS overhead is likely responsible for the performance wins for javascript in the following chart: https://programming-language-benchmarks.vercel.app/typescript-vs-javascript https://programming-language-benchmarks.vercel.app/typescrip... The performance wins for typescript likely source from the ability of the runtime to pre-allocate and avoid type checking. Providing the type checks without using any non-JS features (and possibly providing the runtime some heads up regarding checks to safely drop) is the ideal.

by mavili 3y ago

Intralexical 3y ago

Oh, wow. When this came up before, I don't know if I looked at the DOM, because I assumed you would do this type of thing by drawing pixels on a Canvas. It's actually made of HTML elements? That's impressive.

Aaronmacaron 3y ago
I too think it's very impressive but wouldn't it be even more impressive if it was made using canvas? It would mean that you would need to implement your own rendering loop and layout engine. You'd need to reimplement a lot of elements such as input fields or buttons. You get all of this for free when building on top of HTML/CSS.
- noduerme 3y ago
  You do get a lot of UI elements for free, but styling them consistently and getting them to layout properly becomes a lot more difficult.
- Intralexical 3y ago
  I think it would likely be more technically involved and complicated if it were made with `canvas`. But large blobs drawing to `canvas` aren't anything new at this point. The part that impressed me is doing it the simple way, using what the browser already provides, and getting it to work this well.
  - msephton 3y ago
    Synology DSM (the web interface for a Synology NAS) also constructs a desktop UI the HTML way.
- onetom 3y ago
  It's hard to make that performant. As a reference, here is a browser-adapted version of the https://cuis.st/ https://cuis.st/ Smalltalk environment, which does its own rendering onto a canvas: https://github.com/nmingotti/The-Cuis-CookBook/wiki/Run-Cuis-in-the-Web-Browser.-%28SqueakJS%29 https://github.com/nmingotti/The-Cuis-CookBook/wiki/Run-Cuis...
  - MatthiasPortzel 3y ago
    It’s not performant if you’re using JavaScript APIs. But it’s also possible to write to a canvas with WebGL, which is hardware accelerated and is much faster than jQuery. I believe (although I can’t find a source for it now), that xterm.js used this strategy.
- mrBurger 3y ago
  I dunno, once you write the renderer, you essentially have no limits to worry about. Working within the confines of HTML is way more impressive to me.
- moffkalast 3y ago
  That would be pretty slow, but with WebGL it could work.

notso411 3y ago

[dead]

tambourine_man 3y ago

You can easily shoot yourself in the foot with jQuery (or direct DOM manipulation for that matter), but it's not that hard not to. It just requires some discipline, like most things. React is also far from foolproof and not worth the added complexity in most cases, IMO.

smaudet 3y ago
Convention over Configuration. That and types. The only framework that's useful to JS is a better static type check system (and none of this lets-make-the-whole-damn-runtime-slow to support X feature, looking at you TypeScript).
- solumunus 3y ago
  Curious which TS features you’re referring to?
  - horacemorace 3y ago
    The level of easy facilitated in part by ts on synchronous is too damn high, for one.
- Dylan16807 3y ago
  > and none of this lets-make-the-whole-damn-runtime-slow to support X feature, looking at you TypeScript TypeScript runtime? I don't think the deprecated code that sets up enum objects affects anything else...
  - smaudet 3y ago
    Not enums. But you don't need a runtime or function mutation for that... Particularly egregious was (is?) async/await. Upgrade your browser/runtime/don't use it you say? Sure, but first two weren't always possible, and the third isn't possible unless you thoroughly vet your dependencies (easier said than done). "Compiling to javascript" is all well and good if you actually just compile to normal javascript, as soon as you have any code that simulates other features (classes/objects/what-have-you) you are no longer "compiling to javascript". I mean yeah sure as a sort of intermediary assembly language you are but the performance is not the same. You have a new language with a runtime overhead, that now requires you modify the "core" language to bring in new features, which results in the underlying execution engines (browsers/cpus) becoming more complicated, power hungry, etc.... Anyways, type caching is not all bad. While the TS overhead is likely responsible for the performance wins for javascript in the following chart: https://programming-language-benchmarks.vercel.app/typescript-vs-javascript https://programming-language-benchmarks.vercel.app/typescrip... The performance wins for typescript likely source from the ability of the runtime to pre-allocate and avoid type checking. Providing the type checks without using any non-JS features (and possibly providing the runtime some heads up regarding checks to safely drop) is the ideal.