kaleidawave

The "coding benchmarks" should be based heavily biased on what dependencies they use etc. Reduced characters etc.

Feeling glad I got a 2nd hand air M1 (16gb+512gb) for ~400 GBP last October, rather than waiting out for this.

No idea how the processors compare, but that RAM isn't a good sign

HTML?

Just seen this, was playing with complex Fourier series yesterday. Here < 100 LOC of python that calculates the coefficients and draws the circle animation https://gist.github.com/kaleidawave/bdaf8649e7917152b6cdd624...

Mind blowing that there might be a solar system out there with a collection of orbiting objects whose final object could have square orbit

Case of the “Vacuous truth”

Just one file at a time for this preview. Eventually want to decide some customisations/options inline with tsconfig.

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…

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 :/

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...

Qwik does use a virtual dom: https://github.com/BuilderIO/qwik/blob/3ac5665141208ccfac04f...

No defiantly not an intention to render anything obsolete. I think React will be around for a while.

Instead if you like stricter types, `.map`, and `.push` JSX and want to reduce the runtime abstraction by moving it to compile time then it offers a possible alternative to React. Haven't gone into too much yet but there is a probably a lot of React applications that are too complicated for the optimiser to work :( and there it won't be an alternative.

Lots of great alternatives to React these days as well which I also want to promote!

Thank you. Just checked out the Bagel post (https://www.brandons.me/blog/the-bagel-language) and it looks really cool. Identifying pure functions (whether that is by syntax annotation or from synthesis) is a really good idea, gives me some ideas for doing function inlining in Ezno. I like the "Misc niceties" section, a few of those may of may not be on Ezno's todo list :)

The automatic / inferred generic restrictions is quite cool. https://hegel.js.org/ got there before me! Basic restriction modification is quite simple e.g. `(x) => Math.sin(x)`, x wants to be a number so can add that restriction. It gets more difficult with higher poly types. `(someObj) => Math.sin(someObj.prop1.prop2)` requires modifying not just `someObj` but a property on a property on it. And `(x, y) => printString(x + y)` requires doing even more complex things. But its definitely possible!

Recommend the brilliant Johnny Harris video about this issue https://www.youtube.com/watch?v=NY8Rv6PaXVI

In short not only is a collision bad but it could create a chain reaction leading to billions of small objects flying around in the orbit forming a impenetrable barrier that bars further space travel and more importantly putting other (actually useful) satellites at risk

The post is well written but I don't see the point in this when you can achieve the same in 145 bytes of JS (vs 80kb of stimulus) and avoid a trip to the server:

  document.querySelector("input").addEventListener("input", e => { document.querySelector("p").innerHTML = `<strong>${e.target.value}</strong>` });

Reusing the logic could be done if the server was node or through compiling the formatter to wasm. I struggle to see how Hotwire makes things simpler and has comparable speed to a SPA?

Was looking for something like this the other day. Looks perfect! trying it out right now.

Little confused how it works out the page though. Looking at the given snippet it doesn't seem to include anything and the pathname I am hitting is showing up on the dashboard as "/". Maybe missing sending "window.location.pathname"? And a super tiny thing but "navigator.sendBeacon" maybe better over "fetch". Other that super work!

Awesome benchmarks. Would be interesting how much minification affects actual client and server performance?

And as understand all these tools use a lexing and ast parsing stage. It would be interesting if you could build a very simple minifier (at least a whitespace one) that could skip that step through just working on input buffer?

There is also the fact that more code means longer minification time. You can praise esbuild for building a CRA in 2 seconds but there are workflows/frameworks that compile sub second by using less runtime code.

Just node. As React server components are JS and the React server runtime is written for node

So far very impressed with Deno. Oak is cool too.

No Intl support and no http2 have been a drain this year but those seem to be coming soon as they are on the Q1 2021 roadmap.

The import/module system is great. Can all tooling convening on including extensions in imports (looking at you TypeScript)

Was initially sceptical to this but after skimming think this is actually a very good introduction. I do like the brevity of it compared to the walls of text in the official rust one. Although this does give an illusion that Rust is very simple/easy to learn but any beginner will find that anything more than "Hello World" or "2 + 4" is 10x more difficult than writing in a interpreted language. Not because Rust syntax is difficult but the constraints it introduce require more thought of the design of the program.

The article also skims over the single ownership model which is a big difference with Rust. And it does miss about creating macros, cells, threading & mutexes, heap allocated types, unsafe code, Rc, std::mem, and the whole crates and cargo ecosystem. Which is why I think this should have been titled "half-hour introduction to Rust syntax". Hopefully this does bring more people on the Rust train. I think 2021 will be a good year for Rust :)

Assuming that the counter state is on the client. A button with an event listener that runs x.innerHTML = state.counter++ makes a lot more sense than a round trip to the server.

Just looked and Turbo is 135kb. I rewrote this website (http://40.115.126.159/) with my own JS framework and it comes at 15kb, that's 9x smaller Turbo...

Cool thanks for clarifying. I appreciate the work being done to utilise the benefits of using the server for rendering. It might be worth mentioning the payload inflection point in the drawbacks on the RFC. Looking forward to where this goes!

There will be a very hot wire when I have to ask the server to render a component on the server after I asked to increment a single counter

Hmm, not sure what the hype is about. This still does not solve a lot of my problems with React. You still need the base ~97.5kb react runtime to render a "server component". And if a component is a ~10kb in JS size and their new JSON UI representation is ~1kb in size then if you request 20 renders of that component then over the wire it would be 20kb of fragments than the 10kb component...?

Seems odd that they haven't worked out how this works for routing yet (https://github.com/reactjs/rfcs/blob/07dd4bc4807605020351606...) and that in the demo the whole app is rendered, not individual components. Just seems like turbolinks but for rendering to React VDOM rather than HTML. And I thought most people used React for CSR through hosting files on static buckets leaving out the server...?

Built this HN clone last month which is my first Rust project! So far very impressed with the language.

This also uses my own frontend web framework Prism. Prism is a new web framework which has the ability to "prerender" pages in Rust. Kinda of like something like NextJS is but the render functions are native/pure rust code. There is no other frontend web framework (React, Vue, Svelte) which has this ability, Prism is the first.

Maybe you are writing are site which does rendering through a server side templating language. These are purely server side rendering solutions and miss out on some of the progressive benefits of client side rendering, routing and runtime JS. Using Prism you can get those benefits but can build backend and server side rendering in Rust rather than have to shell out a slower JS server.

It also has a special technique for hydration that is much faster than partial hydration as does not require any JS state blob or rerender on load. You can read about this here: https://dev.to/kaleidawave/jit-hydration-4b62

I have a full article more about the development here: https://kaleidawave.medium.com/hacker-news-clone-with-prism-...

And the site is public here: http://40.115.126.159/

This is very experimental at this stage , if you are writing sites that do SSR in a language other than JS, Prism is working on enable compilation for other languages such has been done for Rust. It would be great to hear your opinions on it!

"server-side rendering with client side dehydration"

lol wtf "dehydration" haha (also "Rolloup")

Still don't really get what Stencil is. Is it a actual single framework or a standard syntax that compiles to React, vue, .. component syntax? This talks about compiling JSX to bindings avoiding vdom diffing but as far as I know that is near impossible to do due to the variable nature of JSX..?

And just a wall of unhighlighted fixed with code is very difficult to compare the differences. And would rather see bundle size comparisons rather than 6 lighthouse screenshots.