Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tesseract.js wraps an Emscripten port of the Tesseract OCR Engine

github.com

Post reply on HN
Print view View original

31–40 of 62 posts

Re: Tesseract.js wraps an Emscripten port of the Tesseract OCR Engine

#31

Post by lucideer »

danShumway wrote: post #17
turminal wrote: post #2

This is a wrapper around a c++ codebase compiled with emscripten, so "pure" in the title doesn't really make sense.

> so "pure" in the title doesn't really make sense. I can see where you're coming from, but I've never used or heard anyone in the web world use "pure" to mean only "written entirely in Javascript without transpilation or other tools." If it hits the parts of "pure JS" that most people care about: - it's running entirely in Javascript. - it has no native dependencies. - it can run entirely clientside. - it can be emb…

From a practical standpoint, WASM is "pure JS" insofar as if I am browsing libraries and see one advertising itself as "pure JS", by convention that to me means "no FFI" or "potentially works in browser".

The only place I've seen "pure JS" used in the JS world is differentiating e.g. a Postgres client implementation that does or doesn't depend on the specific version & configuration of libpq you have on your current system. That's about runtime deps, not about source language.

Re: Tesseract.js wraps an Emscripten port of the Tesseract OCR Engine

#32

Post by pstoll »

danShumway wrote: post #17
turminal wrote: post #2

This is a wrapper around a c++ codebase compiled with emscripten, so "pure" in the title doesn't really make sense.

> so "pure" in the title doesn't really make sense. I can see where you're coming from, but I've never used or heard anyone in the web world use "pure" to mean only "written entirely in Javascript without transpilation or other tools." If it hits the parts of "pure JS" that most people care about: - it's running entirely in Javascript. - it has no native dependencies. - it can run entirely clientside. - it can be emb…

“Pure” does definitely connote that you’ll be able to read all the code in the given language.

That’s exactly what “pure” means - “pure rust”, “pure go”, etc. IMO you can’t say the heart of all the work is a c++ lib and call it a “pure JS” anything.

More accurately / correctly / usefully would be calling it “JS wrapper over a c++ library cross compiled to JS”. Or maybe “All JS at runtime” or some other qualifier.

Want to see how to cross-compile a non-trivial c++ lib? Check out here!

Want to see a great JS wrapper library where we had to make cross-language & cross memory-management API decisions? Check this out!

But - want to read some awesome high performance image processing algorithms in JS? Not this.

Re: Tesseract.js wraps an Emscripten port of the Tesseract OCR Engine

#34

Post by btbuildem »

danShumway wrote: post #17
turminal wrote: post #2

This is a wrapper around a c++ codebase compiled with emscripten, so "pure" in the title doesn't really make sense.

> so "pure" in the title doesn't really make sense. I can see where you're coming from, but I've never used or heard anyone in the web world use "pure" to mean only "written entirely in Javascript without transpilation or other tools." If it hits the parts of "pure JS" that most people care about: - it's running entirely in Javascript. - it has no native dependencies. - it can run entirely clientside. - it can be emb…

That's funny, when someone says "pure JS" I expect exactly that, something written in JS and only JS. Language matters.

Re: Tesseract.js wraps an Emscripten port of the Tesseract OCR Engine

#36

Post by danShumway »

pstoll wrote: post #32
danShumway wrote: post #17

Earlier quoted context omitted.

> so "pure" in the title doesn't really make sense. I can see where you're coming from, but I've never used or heard anyone in the web world use "pure" to mean only "written entirely in Javascript without transpilation or other tools." If it hits the parts of "pure JS" that most people care about: - it's running entirely in Javascript. - it has no native dependencies. - it can run entirely clientside. - it can be emb…

“Pure” does definitely connote that you’ll be able to read all the code in the given language. That’s exactly what “pure” means - “pure rust”, “pure go”, etc. IMO you can’t say the heart of all the work is a c++ lib and call it a “pure JS” anything. More accurately / correctly / usefully would be calling it “JS wrapper over a c++ library cross compiled to JS”. Or maybe “All JS at runtime” or some other qualifier. Wan…

> “Pure” does definitely connote that you’ll be able to read all the code in the given language.

I'm not sure where the line here is supposed to be drawn, but I don't personally think looking at asm.js code is significantly harder than looking at something like compiled Typescript, and certainly it's not any harder than looking at minified Javascript. If I'm going to be debugging code, they're both going to be annoying to look at. We're quibbling over definitions so I'm not going to say that you're wrong, "pure" can mean whatever you want it to mean. I'm just saying that most JS devs I know consider (for example) JSX code to still be pure Javascript when it's compiled.

It seems a little odd to me to look at something where every single line of code is Javascript, being run entirely in a Javascript interpreter, and say that isn't actually completely real Javascript, but if the programming circles you frequent are different and think about this differently, :shrug: more power to you.

> But - want to read some awesome high performance image processing algorithms in JS? Not this.

I also wouldn't necessarily assume that every Open Source program written in only JS without compilation is going to be well suited for reading or learning from. But again, sort of splitting straws here -- my only concern is that you're probably going to be disappointed a lot if you equate "pure Javascript" with "readable".

Re: Tesseract.js wraps an Emscripten port of the Tesseract OCR Engine

#37

Post by danShumway »

btbuildem wrote: post #34
danShumway wrote: post #17

Earlier quoted context omitted.

> so "pure" in the title doesn't really make sense. I can see where you're coming from, but I've never used or heard anyone in the web world use "pure" to mean only "written entirely in Javascript without transpilation or other tools." If it hits the parts of "pure JS" that most people care about: - it's running entirely in Javascript. - it has no native dependencies. - it can run entirely clientside. - it can be emb…

That's funny, when someone says "pure JS" I expect exactly that, something written in JS and only JS. Language matters.

If this is compiling to asm.js then every single line of the program is Javascript and it's running entirely in a Javascript interpreter. If it's not Javascript, then what is it?

I mean, if someone compiles a Markdown document and sticks the result on their website, do you say, "this isn't HTML"? People are free to use words however they want I guess, but I don't understand the perspective where the way a project was written suddenly means that the compiled result isn't Javascript -- it feels like it's taking the word "pure" in a metaphysical direction that I just don't really grok.

Re: Tesseract.js wraps an Emscripten port of the Tesseract OCR Engine

#38

Post by danShumway »

pjmlp wrote: post #30
lucideer wrote: post #27

Earlier quoted context omitted.

In my experience "pure JS" is normally used to differentiate projects from those using NodeJS FFI - the important part is the target / executing runtime (which would be the JS runtime for WASM), rather than the project source. For my own purposes, the priority for me when reading "pure" is that the core runtime I'm using (the JS runtime) is the only runtime dependency - I'm not depending on external binaries and exec…

WASM is a form of FFI.

Wait, how so?

WASM isn't an interface or a wrapper, it's a language/format. Having trouble understanding what you mean by this, unless you're arguing that the WASM VM itself is the FFI?

Re: Tesseract.js wraps an Emscripten port of the Tesseract OCR Engine

#39

Post by azakai »

Hasnep wrote: post #22
danShumway wrote: post #17

Earlier quoted context omitted.

> so "pure" in the title doesn't really make sense. I can see where you're coming from, but I've never used or heard anyone in the web world use "pure" to mean only "written entirely in Javascript without transpilation or other tools." If it hits the parts of "pure JS" that most people care about: - it's running entirely in Javascript. - it has no native dependencies. - it can run entirely clientside. - it can be emb…

Can emscripten compile to JS? I thought it could only compile to WASM.

Emscripten can target both WebAssembly and JavaScript. The JavaScript option uses wasm2js - it compiles first to wasm, then compiles that to JS.

https://github.com/WebAssembly/binaryen#wasm2js

The emcc flag -sWASM=0 disables the wasm final output and emits JS instead.

Re: Tesseract.js wraps an Emscripten port of the Tesseract OCR Engine

#40

Post by azakai »

jcelerier wrote: post #23
Hasnep wrote: post #22

Earlier quoted context omitted.

Can emscripten compile to JS? I thought it could only compile to WASM.

Emscripten started as an asm.js compiler iirc ? Or even "plain" js

Yes, historically Emscripten began before asm.js, targeting pure JS. That JS backend was replaced by an asm.js backend, which was later replaced by the current wasm backend (the wasm backend in upstream LLVM).

(But as already mentioned, JS is still supported today, using wasm2js.)

Post reply on HN