Full-time web dev; JS lover since 2002; CSS fanatic. #CSSIsAwesome
I try to stay up with new web platform features. Web feature you don't understand? Tell me! I'll write an article!
He/him
One thing I find really interesting is the emphasis that the TC39 working group (that is, the folks that develop the ECMAScript spec that becomes JavaScript) often put on intentionally writing very low-level APIs, with the express intention that community members should layer more convenient libraries on top of them. This way everyone isn't stuck with a high-level API that a lot of people dislike. A good recent example of this kind of low-level API is the Shared Memory & Atomics proposal that adds some very important concurrency features to the language. Using these APIs directly would probably be horrible, but there are lots of ways for people with deep understanding of concurrency to layer very useable convenient concurrency libraries on top.
All that to say, I think you're right on the money about Canvas: it could really benefit from some higher level libraries layered on top of it to make it more usable. It's rather tedious to use by hand for anything more complicated than jSphere, but I think that's by design. We really need someone to come along and publish that perfect library that will make the canvas easier to use...
Software Engineer at InVision. Full-Stack JavaScript dev, with passion for front-end development.
Psytrance DJ on weekends, playing in local clubs (yeah, that means: Goa Parties!) :D
Low level APIs are the very common across recent Browser/Web APIs. Working directly with those low level APIs usually works out until you approach a certain degree of complexity. At some point you are required to build an abstraction layer on top of these low level apis, that serves your needs.
The Shared Memory and Atomics, you mentioned is one example. Another currently very emerging example are Web Component. Writing Web-Components with the browser APIs only is certainly not as verbose as fighting with concurrent memory management, but starts becoming verbose as soon as you want to sync more than two attributes with props of your web component.
Within the last year a lot of libraries for building web-components were released. Each with their own benefits and promises.
So you're absolutely right: low level APIs are a very common and necessary pattern (to serve everyones needs).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for the compliment! 😁
One thing I find really interesting is the emphasis that the TC39 working group (that is, the folks that develop the ECMAScript spec that becomes JavaScript) often put on intentionally writing very low-level APIs, with the express intention that community members should layer more convenient libraries on top of them. This way everyone isn't stuck with a high-level API that a lot of people dislike. A good recent example of this kind of low-level API is the Shared Memory & Atomics proposal that adds some very important concurrency features to the language. Using these APIs directly would probably be horrible, but there are lots of ways for people with deep understanding of concurrency to layer very useable convenient concurrency libraries on top.
All that to say, I think you're right on the money about Canvas: it could really benefit from some higher level libraries layered on top of it to make it more usable. It's rather tedious to use by hand for anything more complicated than jSphere, but I think that's by design. We really need someone to come along and publish that perfect library that will make the canvas easier to use...
Thanks for your answer! 😃
Low level APIs are the very common across recent Browser/Web APIs. Working directly with those low level APIs usually works out until you approach a certain degree of complexity. At some point you are required to build an abstraction layer on top of these low level apis, that serves your needs.
The Shared Memory and Atomics, you mentioned is one example. Another currently very emerging example are Web Component. Writing Web-Components with the browser APIs only is certainly not as verbose as fighting with concurrent memory management, but starts becoming verbose as soon as you want to sync more than two attributes with props of your web component.
Within the last year a lot of libraries for building web-components were released. Each with their own benefits and promises.
So you're absolutely right: low level APIs are a very common and necessary pattern (to serve everyones needs).