Clojurians Log v2

If you want to minimize javascript interop, replicant can help. The author of replicant has almost no javscript interop code in his clojurescript projects.

WASM is not the silver bullet everybody sells. There's a huge cost on conversion. For example, parinfer have a version in Rust that performs orders of magnitude better than the JS version, but if you have a big file (like the clojure.core namespace) then it takes almost a second every keystroke, and like 96% of the time is via sending the full source code text to and from WASM.

What conversion? Can webassembly remove most of the conversions in the future?

You can't just pass Javascript objects to WASM, you need to convert them. Even strings, numbers, need to be converted. For example, C strings are null-terminated (usually), and JS strings are UTF-16. To pass them to a WASM-compiled C string, you need to allocate WASM memory, copy the bytes from the JS string (re-encoding in the process if C is not using UTF-16, and it usually is not), then as soon as the WASM function runs, copy back the contents from the WASM memory into JS

This conversion part is usually a huge performance hit, and most "WASM good, look how fast it is" articles completely ignore this

Will webassembly component model not reduce conversion?

Let's imagine a future when everything is wasm component. Even DOM API is wasm.

If a programming language adopts wasm component memory model, perhaps there is no conversion required.

If you can design a copy-less component memory model, perhaps you can eliminate conversion. A unified memory model shared by every wasm language can eliminate conversion.

Unless it's very well designed, I find it hard to eliminate components. For example, C and C++ have completely different "strings". Haskell, too. It's hard to know how I could share a JS string between all three languages without any kind of conversion; then, you need to "share memory" between the JS and WASM VMs, which is basically the opposite direction JS is moving (Electron, for example, disabled some pure memory manipulations for native extensions because it could crash webworkers with node access). To make things worse, JS string are immutable, C, C++, and Ruby are not - how could an unified memory model work in this situation?

I can see some kind of "copy-on-write" or things like that working, but again, this unified model will need to create some "adaptation" of different memory organizations (JS numbers need to appear as integers/floats/doubles to C/C++ for example, without actually stuff), probably for primitives at least (and strings, because these are the biggest cost I believe)

I have seen libraries in which web worker can run main thread, so expensive computations can run in web worker.

@mauricio.szabo can't we extend or use latest JavaScript features in .js files and consume them from .cljs files when said feature isn't available in ClojureScript directly?

https://martinklepsch.org/posts/embracing-js-files-in-clojurescript/

Yes, but eventually you start to think why you're using ClojureScript in the first place; debugging a code with lots of "glue code" can end up being very tedious, and you lose the best of both worlds... eventually, it gets harder and harder to justify using a different language than pure Javascript

@mauricio.szabo what do you use for backend when using JavaScript for front-end? Node.js or Clojure or something else?

Well, for my job I use Ruby + Javascript (with all the bull:hankey: that comes with Rails and frontend code) For my personal projects, I don't really have a "frontend" or "backend" - I keep a fork of Atom (so front+back are together in the same codebase) and some Clojure/Ruby/Python plug-ins for it; the fork of Atom is pure Javascript, the plug-ins are ClojureScript (even with all the problems)

I think "Using JS in ClojureScript Projects" is an acceptable way to interact with javascript. Even in purescript, when you want to interact with javascript, it's best to just write javascript glue code that purescript can understand. If you minimize the number of javascript components you interact with in clojurescript, it shouldn't be too painful.

> In PureScript, JavaScript code is wrapped using a foreign module. A foreign module is just a CommonJS module which is associated with a PureScript module. Foreign modules are required to adhere to certain conventions:

Write foreign modules for clojurescript, and don't outsource functionalities to javascript too much.

https://github.com/WebAssembly/component-model/blob/main/design/high-level/Choices.md says > The component model adopts a shared-nothing architecture in which component instances fully encapsulate their linear memories, tables, globals and, in the future, GC memory. Component interfaces contain only immutable copied values, opaque typed handles and immutable uninstantiated modules/components. So, webassembly forces copying in most cases between languages. But, • It is going to be fast within a language. Right now, clojurescript is not fast. • webassembly component interop will be less painful than javascript interop because webassembly component model will be stable.

When you write higher-level languages that are very different from the lower-level languages, writing a binding or foreign glue code seems unavoidable. At least, webassembly components can ease the pain of interop. I understand that having to write glue code or tight loops in C when you want to write python is frustrating, but it has to be done. At least, javascript is easier to work with than C.

I am using ClojureScript mainly for my own personal projects. But I must say that I'm only partially satisfied with my decision...

@mauricio.szabo what's the reason for being only partially satisfied? Are there better alternatives?

There are no better alternatives for now, but I feel ClojureScript is being "left behind". Basically, JS now supports a lot of things that we can't do in CLJS; classes, private methods (these ones are literally unsupported, the Closure Compiler can't parse these), async iterators, template strings etc; these are hard to interop in CLJS, and clumsy to adapt (at best).

There's also the problem of the compilation process too - it's slow, and sometimes generates invalid Javascript; I got into way too many situations where I was developing something just to see it crash under some "undefined is not a function", and after a lot of debugging, discovered that the fix was to remove Shadow-CLJS's caching and re-compile everything.

TypeScript, VS Code and rest of the ecosystem are also pretty good.

Back-end/Node.js ecosystem also got better.

If we look at Clojure(Script) for full stack web development, JavaScript is also a potential alternative, which can perform better in many cases.

Javascript will perform better in most cases. Different from Clojure, where the structures have near-native speed (hindered only by immutability) ClojureScript's structures are orders of magnitude slower than Javascript, unfortunately

But I don't even think this is a problem, to be honest - my problem with ClojureScript is that it became "isolated". It's hard to interop with some libraries because they expect, for example, that you're able to create a class and extend from something and it's hard to do that in ClojureScript (even with Shadow)

Will javascript interop be improved?

Perhaps, clojurewasm and webassembly component model can ease the pain in the future.

I wouldn't say that i'm an agency but for my projects i use only clojure(script).

What are you, then?

I work as a developer but if I find a freelance job I do it. Apart from that I'm working on some of my own apps.

I want to aggressively reach out to niche owners and solve their problems with simple tiny clojure(script) programs. I have to build and sell.. It will be hard...

Me too. I like that model.

I don't recommend working on SaaS right away without knowing the market. Agency work makes you learn the market.

Yeah. I agree!

I decided to stick to a unified clojure(script) stack for as long as possible. Otherwise, I can't build up leverages over time. Even HTML and CSS will be generated from clojure(script) in advance or during the runtime.

I used htmx for one of my projects.

I will try to use only replicant for UI. I have to specialize in one unified stack. Enormous power comes from specialization.

I'll take a look into replicat as well.

I chose replicant because htmx and datastar aren't going to be enough, and I don't want to deal with react upstream changes. Replicant is finished and simple and first-class in clojurescript.

Thanks for the heads up. I see what you mean.

Do you know reagent had to deal with multiple react upstream changes? Even UIx may have to deal with upstream changes at some point. It may be slower to use replicant at first, but you will gain speed over time. If you build on a stable foundation, you will gain leverage over time.

I'm open to new things. That's why I got into clojure as well.

I just described my supposedly life-time tech stack. If you change tech stack frequently, you can't build leverages. I plan to stick to one tech stack for as long as possible.

Clojure is also being built on webassembly, so we are probably future-proof.

I intend to stay on clojure as well for the long term.

Cool.