-
Hi everyone, |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 2 replies
-
I think the point is to have a compatible API so the the knowledge developers already have about browser APIs carries over. Examples include the Fetch API and the |
Beta Was this translation helpful? Give feedback.
-
Browser compatibility allows one to write the same code and use it in multiple places, e.g. on Firefox, Safari, Deno, etc, without (major) change to the source code. Most of the browser APIs are powerful, useful features that developers have wanted or needed, they also have very well defined algorithms and behavior, making (some of) them easy to port anywhere. But, there seems to be a misunderstanding here,
Performance and browser compatibility are completely unrelated. There is also more to performance than just "speed," ex: memory consumption. Take the const { body } = await fetch(...);
for await ( const array of body ) {
...
} using this stream of u8 arrays, you could do something like assigning the array to a global variable, preventing it from being garbage collection, forcing the runtime to allocate more memory, ultimately slowing the code down. If you do that, then it's partially your fault. But, let's say that Deno wanted to implement a way to send a request, and receive data, what if it read everything in sync, and only yielded once the entire response was read? In that case, you would complain that Deno's API isn't good, but now that situation won't occur at all, as they simply implement the standardized API. As a bonus, any bugs can quickly be spotted by those who are familiar with a browser implementation.
|
Beta Was this translation helpful? Give feedback.
I think the point is to have a compatible API so the the knowledge developers already have about browser APIs carries over. Examples include the Fetch API and the
console
methods.