graderjs VS simdjson

This is very polished and cool looking. Inspiring. I find this project's level of polish very inspiring.

It's lovely to see someone has captured this idea and expressed it in the right way to make it interesting to many people. I really hope this mode of desktop apps can take off, at least to the level where the community has something to explore for a while to see if it works. I made something like this for Chrome browsers a while ago, nodejs backends, vanilla front-ends, built-in packaging using pkg. It's just a nice approach: https://github.com/dosyago/graderjs

And I made a demo using the venerable MS Paint clone JS Paint^0. The dev experience was great, I literally just dropped in the front-end code to the right folder, compiled it and wham, "desktop JS paint" on 3 platforms, haha.

Using the ubiquitous local browser as the rendering / API engine for desktop just seems smart. And it's technically interesting, because you get to think in terms of how can you step back from the browser, the platform, the front-end and the back-end and come up with a general API that addresses all of it, which is kinda cool.

0: https://github.com/00000o1/jspaint.exe

Client / Server Web App: Node.JS, Bang.html[0], the filesystem

Native downloadable executable desktop GUI application: Node.JS, GraderJS

CLI app: ??? Don't know yet, GraderJS can work but it's focused around GUI

Mobile app: ??? Don't know yet

Embedded: ??? Don't know yet

Graphics: Processing (but surely there are much better options nowadays)

AI: ??? Don't know yet

[0]: https://github.com/crisdosyago/bang.html/

[1]: https://github.com/crisdosyago/graderjs/

I'm working on an alternative. It's a slightly different take, but provides similar functionality of Node.js plus front end code in a packaged binary. Instead of using a weird custom fork of chrome and downloading that for every different binary we just use the system Chrome browser (or install it once for all apps). Eventually we can probably expand to use other Chrome browsers or even other web driver supported browsers which Firefox seems to be building that support out. I just like the idea of using something that's already on the system.

Take a look at the wonderful GraderJS, heh :)

https://github.com/crisdosyago/graderjs

For those who didn't reach the end of the README.md, it seems to use an electron-alternative called grader, from the same author:

https://github.com/i5ik/graderjs

It runs server and downloads Chrome (if not available already) and starts it in app mode.

It is a good idea but it is not a new idea

the interesting history of these sorts of frameworks is that Google actually created a framework that did this and stopped development on it. the code is still on GitHub. And there's a bunch of other frameworks that use a variety of different languages not just rust as the application language that also have this idea of not bundling chromium but instead using the system webview for rendering HTML and JavaScript.

You can find a bunch of different approaches in lists like "alternatives to electron." There's some on GitHub.

I took a slightly different approach where instead of using the system web view which I thought you know is going to be inconsistent across systems and it's not going to support the latest HTML JavaScript and security features I used the assumption that the user already has chrome installed which works in a high number of cases or can download and install it if that's not the case. predictably I suppose some people express to satisfaction that it was not using Firefox. using Firefox becomes more possible and more likely I suppose as firefox's support for the dev tools protocol achieves parity with chrome support for that.

https://github.com/c9fe/graderjs

It's also supported by simdjson [0] (which has a lot of language bindings [1]):

> Multithreaded processing of gigantic Newline-Delimited JSON (ndjson) and related formats at 3.5 GB/s

[0] https://simdjson.org/

[0] https://github.com/simdjson/simdjson?tab=readme-ov-file#bind...

String parsing is negligible compared to the speed of the DOM which is glacially slow: https://news.ycombinator.com/item?id=38835920

Come on, people, make an effort to learn how insanely fast computers are, and how insanely inefficient our software is.

String parsing can be done at gigabytes per second: https://github.com/simdjson/simdjson If you think that is the slowest operation in the browser, please find some resources that talk about what is actually happening in the browser?

Thanks for all the detailed information! That answers a bunch of my questions and the implementation of strlen is nice.

The instruction I was thinking of is pshufb. An example ‘weird’ use can be found for detecting white space in simdjson: https://github.com/simdjson/simdjson/blob/24b44309fb52c3e2c5...

This works as follows:

1. Observe that each ascii whitespace character ends with a different nibble.

2. Make some vector of 16 bytes which has the white space character whose final nibble is the index of the byte, or some other character with a different final nibble from the byte (eg first element is space =0x20, next could be eg 0xff but not 0xf1 as that ends in the same nibble as index)

3. For each block where you want to find white space, compute pcmpeqb(pshufb(whitespace, input), input). The rules of pshufb mean (a) non-ascii (ie bit 7 set) characters go to 0 so will compare false, (b) other characters are replaced with an element of whitespace according to their last nibble so will compare equal only if they are that whitespace character.

I’m not sure how easy it would be to do such tricks with vgather.vv. In particular, the length of the input doesn’t matter (could be longer) but the length of white space must be 16 bytes. I’m not sure how the whole vlen stuff interacts with tricks like this where you (a) require certain fixed lengths and (b) may have different lengths for tables and input vectors. (and indeed there might just be better ways, eg you could imagine an operation with a 256-bit register where you permute some vector of bytes by sign-extending the nth bit of the 256-bit register into the result where the input byte is n).

Additionally, if you like low level stuff, check out libfmt (https://github.com/fmtlib/fmt) - not a big project, not difficult to understand. Or something like simdjson (https://github.com/simdjson/simdjson).

Everything you said is totally reasonable. I'm a big fan of napkin math and theoretical upper bounds on performance.

simdjson (https://github.com/simdjson/simdjson) claims to fully parse JSON on the order of 3 GB/sec. Which is faster than OP's Go whitespace parsing! These tests are running on different hardware so it's not apples-to-apples.

The phrase "cannot go faster than this" is just begging for a "well ackshully". Which I hate to do. But the fact that there is an existence proof of Problem A running faster in C++ SIMD than OP's Probably B scalar Go is quite interesting and worth calling out imho. But I admit it doesn't change the rest of the post.

I have same question as /u/JDRiverRun : how do you deal with JSON, do you parse json on Rust side or on Emacs side. I see that you are requiring json.el in your lspce.el, but I haven't looked through entire file carefully. If you parse on Rust side, do you use simdjson (there are at least two Rust bindings to it)? If yes, what are your impressions, experiences compared to more "standard" json library?