NG icon indicating copy to clipboard operation
NG copied to clipboard

Less is more

Open mikeal opened this issue 9 years ago • 7 comments

I'm going to try and write out some of my most recent thinking about NG. What I first thought of as an opportunity to adopt new patterns I now see as an opportunity to reduce the surface area of the platform and more effectively enable higher order platforms and ecosystems.

First, you start with nothing. import does not return a single standard library module.

Now, rather than try to build up what node has today, we try to build up a new standard library that enables the community to build up what node stdlib has today. And, you build it to function in the browser.

Let's call this next-stdlib.

ng

Rather that try to write a promise based platform, or a callback platform, or some future pattern that might emerge, we create an ideal foundation for any such platform by not exposing a stdlib other than base primitives that can be built to the platform bindings (libuv) and the browser.

What about features that can't be supported in the browser?

We don't write them, at least not yet. We can work with standards groups to expand what is possible in the browser and write to that. Next Stdlib should be written to the latest standards and people can use polyfills if they want to support older browsers. Remember, not doing it in the stdlib doesn't mean that it won't be possible, it just means that it'll have to be done in the ecosystem and will probably not work in the client and the server.

It may also be worthwhile to break the libuv section in to libuv/libuv.js (thinnest possible JS binding to libuv). This would also give us the opportunity to do heavy performance optimizations at the libuv.js layer and tolerate slightly less ideal performance when faced with supporting an API on top of the browser's available APIs.

mikeal avatar May 23 '15 12:05 mikeal