Hacker News Reader

Comment by oVerde | Hacker News Reader

So basically you live JavaScript free?

as much as i can yes.

I try to avoid JS, as it is a horrible language, by design. That does include TS, but it at least is useable, but barely - because it still tied to JS itself.

Off-topic, but I love how different programmers think about things, and how nothing really is "correct" or "incorrect". Started thinking about it because for me it's the opposite, JS is an OK and at least usable language, as long as you avoid TS and all that comes with it.

Still, even I who'd call myself a JavaScript developer also try to avoid desktop applications made with just JS :)

JS's issue is that it allows you to run an objectively wrong code without throwing explicit error to the user, it just fails silently or does something magical. Seems innocent, until you realize what we use JS for, other than silly websites or ERP dashboards.

It is full of gotchas that serves 0 purpose nowadays.

Also remember that it is basically a Lisp wearing Java skin on top, originally designed in less than 2 weeks.

Typescript is one of few things that puts safety barrier and sane static error checking that makes JS bearable to use - but it still has to fall down to how JS works in the end so it suffers from same core architectural problems.

> JS's issue is that it allows you to run an objectively wrong code without throwing explicit error to the user, it just fails silently or does something magical. Seems innocent, until you realize what we use JS for, other than silly websites or ERP dashboards.

What some people see as a fault, others see as a feature :) For me, that's there to prevent entire websites from breaking because some small widget in the bottom right corner breaks, for example. Rather than stopping the entire runtime, it just surfaces that error in the developer tools, but lets the rest to continue working.

Then of course entire web apps crash because one tiny error somewhere (remember seeing a blank page with just some short error text in black in the middle? Those), but that doesn't mean that's the best way of doing things.

> Also remember that it is basically a Lisp wearing Java skin on top

I guess that's why I like it better than TS, that tries to move it away from that. I mainly do Clojure development day-to-day, and static types hardly ever gives me more "safety" than other approaches do. But again, what I do isn't more "correct" than what anyone else does, it's largely based on "It's better for me to program this way".

>it's there to prevent entire websites from breaking because some small widget in the bottom right corner breaks, for example.

the issue is that it prevents that, but also allows you to send complete corrupt data forward, that can create horrible cascade of errors down the pipeline - because other components made assumption about correctness of data passed to them.

Such display errors should be caught early in development, should be tested, and should never reach prod, instead of being swept under the rug - for anything else other than prototype.

but i agree - going fully functional with dynamic types beats average JS experience any day. It is just piling up more mud upon giant mudball,

IME, JSDoc is sufficient for type checking.

TS is just too much overhead for the marginal gains.

> JS is an OK and at least usable language, as long as you avoid TS and all that comes with it.

Care to explain why?

My view is this: since you can write plain JS inside TS (just misconfigure tsconfig badly enough), I honestly don’t see how you arrive at that conclusion.

I can just about understand preferring JS on the grounds that it runs without a compile step. But I’ve never seen a convincing explanation of why the language itself is supposedly better.

out of sincere curiosity, which one is a great programming language to you?

depends on use case, i don't think one language can fit all cases. 100% correctness is required for systems, but it is a hindrance in non-critical systems. or robust type systems require high compilation times which hurt iterating on the codebase.

systems? rust - but it is still far from perfect, too much focus on saving few keystrokes here and there.

general purpose corporate development? c# - despite current direction post .net 5 of stapling together legacy parts of .net framework to .net core. it does most things good enough.

scripting, and just scripting? python.

web? there's only one, bad, option and that's js/ts.

most hated ones are in order: js, go, c++, python.

go is extremely infuriating, there was a submission on HN that perfectly encapsulated my feelings about it, after writing it for a while: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...

Under a submission like this you picked Rust, that is neat.

Lucky you. I keep coming back to it because jobs and even for desktop apps a native webview beats everything else.

We fcked up with js, big time and its with us forever now

For game dev too - all game engines suck. <canvas/> FTW.

I was hyped for wasm because i thought it was supposed to solve this problem, allowing any programming language to be compiled to run in browsers.

But apparently they only made it do like 95% of what JS does so you can't actually replace js with it. To me it seems like a huge blunder. I don't give a crap about making niche applications a bit faster, but freeing the web from the curse of JS would be absolutely huge. And they basically did it except not quite. It's so strange to me, why not just go the extra 5%?

Maybe its something about sharing memory with the js that would introduce serious vulnerabilities so they can't let wasm code have access to everything.

The only way to remove Js is to create a new browser that doesn't use it. Fragments the web, yes and probably nobody will use it

That 5% of js glue code necessary right now is just monumentally difficult to get rid of, it's like a binary serialization / interface (ABI) of all DOM/BOM APIs and these APIs are huge, dynamic, callback-heavy and object-oriented. It's much easier to have that glue compiler generated, which you can already do right now (you can write your entire web app in rust if you want):

https://github.com/wasm-bindgen/wasm-bindgen https://docs.rs/web-sys/latest/web_sys/

This is also being worked on, in the future this 5% glue might eventually entirely disappear:

> Designed with the "Web IDL bindings" proposal in mind. Eventually, there won't be any JavaScript shims between Rust-generated wasm functions and native DOM methods

The DOM is fundamentally dependent upon JS shaped data structures and garbage collection. They are BFFs.

Any attempt to bypass this will be perilous.

So we'd need a new DOM, seems feasible

A webview doesn't beat anything for desktop apps. It is the worst option available.

A go desktop app with native webview: 3.3 MB starting size

A go desktop app rendered with OpenGL: 39MB starting size

So its smaller than Gpu rendered desktop app and I get to use CSS for styling which is very powerful

You can write javascript without using npm...

I mean, it's hard to avoid indirectly using things that use npm, e.g. websites or whatever. But it's pretty easy to never have to run npm on your local machine, yes.

Reply on news.ycombinator.com