Very happy for it finally being there!

I attempted to implement the Temporal spec myself and it really isn't fun. After the tc39 meeting in May, I also switched to `temporal_rs` for `yavashark`. My own implementation ways everything else than optimal, I didn't support the RFC9557 timeformat. In theory you could even use temporal_rs to provide an perfect polyfil with wasm.

We could do a WASM FFI target. I have thought about it lol

My only concern is that temporal_rs packages it's own time zone data, which may make the WASM package a little heavy, so I've been inclined to leave the polyfill up to fullcalendar's implementation.

Diplomat has a wasm backend so it would even be really easy to produce a WASM ffi target with idiomatic JS and TS bindings.

Also, Diplomat supports traits and callbacks so you could actually make the timezone impl pluggable. Though we don't currently have JS support for that.

But also tz info isn't that big I think...

I highly doubt that. At least not in a native way. However, you could make an adapter from the native interface to wasm components. Would be interesting to look into!

Servo and Tauri still let the Application use JavaScript, which is just very wasteful. I was thinking about making it possible to write dynamic websites completely without JavaScript, by building up WASM support and making that even faster. But that's a not the goal for now. Indeed, we don't even have a JS API for websites yet...

Well, the application is basically unoptimized. However, we also don't have many components yet that can eat up your memory. But we try to keep the memory usage as low as possible. We also thought about integrating it into something like Electron, and for something like that it is important to have a low memory usage.

Lateron, we might have some compile time flags to reduce memory usage in cost of a bit of speed. Most Electron apps don't require that big oomf performance on the startup, since everything is locally and can be cached in a better way.

Iirc that thing was also AI generated. I don't like it, but here we are and have this sentence. Imo ChatGPT is for name generation not the... best

No, the website isn't AI generated. There might be some parts of it, though, like general structure of the website and structure of texts.

Yes, the initial logo design was generated by AI, however the current logo was made by a designer from the AI's draft.

I don't know if it is a compliment that my website design skills match the ones of AI or if it is more an insult

I love the logo and I love the name. Sounds like a polarizing logo; that's a good thing. I remember having similar thoughts to this other person when Google first launched their search engine with their "ugly rainbow" logo. You're good.

The "optimised search and unlimited browsing" isn't really a statement, it is the expanded form of the acronym gosub. As I said, I don't really like it, but this is what we have now... :/ But I can definitely see where you are coming from.

if you don't like it. And people are also telling you they don't like it, then why do you insist on having it be an acronym?

The acronym was basically there from Day 1, I am not the Person who came up with it and I also wasn't there at Day 1.

Is there a way of getting the points back?

If someone really cared about it I'd do something manually, but fortunately most HN users don't care.

lol GOSUB as a BASIC command, yes I can see the reference. It actually referes to the BASIC command.

Thanks for this! I didn't really use BASIC much back in the day, but I am from - ahem - an older time...and the name seemed so familiar, but quite couldn't place my finger on it. so, thanks for clarifying this! :-)

Logo? Lisp? Punched cards?

The byte stream is one of the first components that was written. Probably It wouldn't be written nowadays. The browser is quite modular, so in the end you can completely out out of that system.

That’s good to hear. I’m excited to see you’ve got a good html parser. That’s worth a lot just by itself.

Yes, the HTML parser, probably the component that is the most spec compliant. I think the CSS parser also is. For the initial phase, I think it is more important to get something working. For a later implementation, the spec should dictate what we do and what not. But with a small team, it is just not feasible.

Isn't one of the difficultlies of writing a browser that your parser must accept lots of invalid inputs and render it like other browsers would?

HTML5 parsing is relatively easy, because behavior for tag soup is 100% specified. That is, in theory, all conformant HTML5 parsers should output the same DOM for any arbitrary byte sequence.

Layout is much harder because the CSS spec is full of UB, so you will have to do some reverse engineering there.