Thanks! I could see why the name is a problem. Especially how N rotated 90 is Z. Unfortunate a bit late, given it was free on the package systems etc :/
Naming still remains the hardest programming problem ...
https://github.com/denoland/deno/issues/1739 just crossed 4 years. if they want people to do transpiling inside their own tool create an API so we can use our own tools rather than ones behind their black box.
Would be a much better use of their time than writing this nonsensical bs
Ezno a semi compatible TypeScript compiler does effect tracking. It’s possible but you do have to handle the way functions handle parameters which is why it’s type system is different to the way tsc handles things. And for functions outside of the user code you have to know what effects are internally run. Things like JSON.stringify look pure until you pass it an object who has a toJSON method that does something silly. A little complicated to show what stringify internally does but possible if you add additional metadata to the definition files.
Then rather than marking a function as pure you instead check it is pure by looking at what effects its function type has!
Not sure but I think startup time is impeded by the fact that tsc has to parse and synthesize around 20k+ lines of TS definition files. These require a parse for hoisting, require scanning lots of comments which are only used in LSP mode and are not a optimised format to parse.
On the other hand Ezno a semi compatible TypeScript compiler can use a more low level binary format which is only one pass and whose name references are already resolved https://twitter.com/kaleidawave/status/1596445852918325250?s... . This is only really possible because it is written in Rust so low level byte and memory management is relatively simple
It’s silly how the ‘async’ function modifier got a keyword before the function keyword and the generator modifier got a symbol ‘*’ after the function keyword…
It is true that a button's click event can fire before a client re-render. *However* if that event changes state it does have to do a initial VDOM render to make a first frame before a second one to work how to change the actual DOM and the UI. and although that click event does run it needs to be redirected to the actual event handler. That redirect needs to do downloading, parsing and hydration. So "immediately usable" and "super responsive" are a stretch here...
There is a service worker that will prefetch all of the event handlers currently in view. So when the person clicks on the button, the browser will fetch the JS, but the service work short circuits that request and returns the JS instantly. They have plans to make the prefetching even smarter by gathering information on which chunks are most used and prefetch those first.
Ah I didn't realise it did that? The homepage still makes several references to lazily downloading JS?
Eagerly downloading JS is something every framework does though and many only download for the current view through code splitting for the current page. It doesn't fix the later two problems..., struggling to find any benefits above existing techniques here :/
My bad, you’re right it seems they’re currently using a vdom; I suppose this is something they’re looking to get rid of before 1.0 since I’ve seen they’re implementing signals for reactive updates (like solid does)
Mind blowing that there might be a solar system out there with a collection of orbiting objects whose final object could have square orbit