![]() ![]() This is not the right way to look at it though Go and JavaScript are hugely different languages and compiling from one to the other is far from trivial. So technically it could look as if we’re comparing a Go → JavaScript compiler with a TypeScript to JavaScript compiler. In order to be accurate, I have to clarify something.įzf-for-js is, like many large JavaScript projects, not actually written in JavaScript, but in TypeScript. The last 5% is hell!), but rather tries to port the Go code file by file. This project aims to port the fzf code (or at least the same part that I called the core, when deciding what to include in fzf-lib) to TypeScript – so unlike some of the other efforts out there (including my own ill-conceived-now-discontinued one), he didn’t try to reverse engineer the fzf code from example inputs and outputs, and then rebuild it in JavaScript (trust me, getting 95% to work, is no problem. So I was very surprised when a couple of weeks ago I ran into fzf-for-js. When I first started looking at compiling the Go code a couple of months ago, I did have in the back of my mind that I wanted to manually port it to JavaScript as well, if only to see how much better (or worse) I would be compared to the automatic tools.īack then I had obviously checked if someone had already done this, and nobody had. In the last post I showed 2 solutions based on a Go → WebAssembly compiler (Go & TinyGo), and a single solution based on a Go → JavaScript compiler (GopherJS). browsers).Īs I mentioned in the previous post, there are generally 4 ways to get some Go code to run in the browser: compile it to WebAssembly, compile it to JavaScript, manually write it in WebAssembly (or possibly in C and compile that) and manually write it in JavaScript. Before we simply tested in node this time we’ll extend the test to different platforms (i.e.Some compilers allow different compile flags that influence performance, we’ll play with those a bit.In the last test we did one simple performance test this time we’ll test with different amounts of data to search in, and different access patterns.We admit a new contender: fzf-for-js, a (manual) JavaScript port of fzf.In this post we’ll dive deeper into performance: If you did not read that post, I very much advice you to do so now this post builds on that one, and readers are assumed to know the information in that post We used both the standard go compiler and TinyGo to compile Go code to WebAssembly, and we used GopherJS to compile Go code to JavaScript. In past posts in this series, I looked at how to convert a Go library in order for it to work in the browser. Performance of a Go library (fzf-lib) in the browser August 30, 2021.Using a Go library (fzf-lib) in the browser August 10, 2021.Interface between Go 1.16 (compiled to WebAssembly) and JavaScript (syscall/js) August 05, 2021.Creating Fzf into a library: fzf-lib July 08, 2021.This post is post 4 of a (so far) 4-part series on "Making fzf available in the browser".
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |