It turns out that even if you accept "Python is great and JavaScript sucks" that "Python compiled to JavaScript" ends up even worse than JavaScript.

> It turns out that even if you accept "Python is great and JavaScript sucks" that "Python compiled to JavaScript" ends up even worse than JavaScript.

Clearly, there are people that disagree with this value judgement, and the existence of that disagreement is an existence proof that Python for frontend is, in fact, a choice people can make, even if it is one you find unattractive.

I also have gotten DMs on Reddit from companies looking for devs since I commented on a thread 10 years ago about an obscure toy language: it doesn't mean thats a reasonable choice for technology.

I think theres legitimate reasons to compile Python to JS, but "JS is bad" can't be one of them, since you still have JS that you have to worry about. It makes sense for codesharing with server code or preexisting business logic.

Over the years I've debugged js compiled from various languages, and it's seriously a terrible experience: however bad you think debugging handwritten js is, reading and debugging generated js is strictly worse (and you will have to)

> however crazy you think handwritten js is, generated js is just obviously worse to try to read (and you will have to)

Or...maybe I won’t; I’ve used plenty of compile-to-JS languages (including what starts as “js” with JSX and modern features but gets compiled to plain, and more widely supported, JS), and I spend as much time reading and debugging JS in its compiled form as I do reading and and debugging .NET or Python bytecode instead of source, which is none.

That's not a solution if you end up with Javascript in the end. (Also Dash is absolutely terrible, horrible documentation, horrible code.)

> That's not a solution if you end up with Javascript in the end. (

It is, just as using compile-to-(or interpreted-by-a-runtime-in-)-native-code languages is a solution to “I don’t like raw x86_64 machine code for desktop applications”, even if you end up running machine code in the end.

> Also Dash is absolutely terrible, horrible documentation, horrible code.

“X is not a choice people can make” is a different claim than “One example of X is not something I personally would recommend”.

The issue is that writing code that goes through a JS-transpiler is more complicated than just writing Javascript, unless the language you choose is Javascript-adjacent, whereas writing code that compiles to machine code is infinitely less complicated than just writing machine code.

As to your second point, that's why I put it in parentheses, of course it doesn't refute your claim but if you use as example a technology that has awful documentation because of this two-language paradigm, and leads to garbage code both at the Python stage and the Javascript stage, to me it doesn't paint a good picture of the whole concept.

Why is that not a solution? The concept of compiling/transpiling a language into the target language for the runtime is everywhere.

Even native languages like C/C++/Rust compile their language into binary format that the platform can run. It just so happens that the web runtime format is JS instead of binary machine instructions.

Because debugging your transpiled JavaScript becomes a nightmare in a language you already hate

> Because debugging your transpiled JavaScript becomes a nightmare in a language you already hate

That’s what sourcemaps are for; you don’t have to debug compiled instead of source format on the web just like you don't on other platforms.

IDOM looks a lot like what I had been thinking of implementing, but with the additional benefit of actually existing. :) Thanks for the pointer!