Hacker News Reader

Comment by FractalHQ | Hacker News Reader

I love JavaScript and Typescript. They’re fun and easy to read and write, and there is little they can’t accomplish for the average use case. I haven’t dug nearly as deep into other languages, but I’ve dabbled with dozens, and Ecmascript 2020 is still my favorite language to code with.

The ecosystem is gargantuan, npm is great with pnpm, and all of the annoying parts of client side JS is made fun and easy with Svelte. With TS, CSS, and HTML (and Svelte bringing out their full potential), I can quickly make almost any app I want with incredible DX, comprehensive tooling, and next to no boilerplate. Every year it gets faster and faster, and when it’s not fast enough, there is WASM.

I would genuinely love to know what is so bad about it, and what I’m missing out on!

View on HN

Personally, some of it is the language. the need to triple equals and all the type coercion. it's harder to get those wrong with typescript I agree.

another is the ecosystem. pnpm feels like a bandaid to a bad package management system . the whole 'node_modules' folder ends up being a polluted mess very quickly. I import a small library and I feel like I download half of npm registry with it.

any time I've wanted to do anything in the JS world, I have to download 30 different frameworks, that don't quite mesh well together. svelte+tailwind a year ago was a disaster to setup with rollup. had to switch to webpack which pulled in a bunch of other stuff and svelte broke.

I think the biggest problem is interop and all the translators and transpilers in a standard application. between Babylon, es6/7/8/next/jsx/TS/tsx transpilers. the scss, css, transpilers. media pipelines and converters. and half the time if you don't set them up just right. they don't play well together.

maybe it's just not my world. I'm a backend/DevOps/systems dev. and while many languages have similar problems, rarely do they have ALL of these at the same time.

back to the language, I feel like early on all the prototype overriding/monkeypatching/etc made for a very very messy language. I'm familiar it's gotten better, but all that cruft is there and still used often.

finally, while all the WebApps have been good, I hate how EVERYTHING is using JS on the web, even for useless things, or things that don't need to be JS. I hate how many sites literally are blank I'd you don't have JS enabled. it's also slowed down the web a lot. things take forever to load.

so I have many factors that contribute to make having a disdain for JS, both social and technical.

It's hardly fair to go to a thread on an embedded JavaScript implementation to criticize JavaScript by focusing on the JavaScript ecosystem. It's up to you to decide which and how you use a third-party package. If you adopt a dependency that's so bloated that it drags in half of NPM's repository them the responsibility of your personal choices lies solely on you and on you alone. I mean, you can fall for that mistake with pretty much any stack or framework or programming language which supports modularization and provides a package manager. Why single out JavaScript?

I didn't come here to criticize, if you notice my first post, I came here to tell others to not to, regardless of my beliefs. then I was specifically asked for more detail, so I answered.

and I single out JS because I like programming languages and learn and use most of them, JS suffers from this problem the most. anyways, sorry, I did not intend to argue over this. so I will refrain from continuing. I have my personal views on JS and I was trying not to detail the thread, seems I failed.

The problem is not Javascript itself IMO, the problem is that there exists a large portion of web-only developers with knowledge only about Javascript, who try to cram it down every corner and every problem space that they can. This leads to things like Electron polluting a space where Qt/wxwidgets/win32/GTK would be technically superior by producing small and native binaries, yet we get steaming messes of Chromium that swallow hundreds of megabytes of RAM and waste millions of CPU cycles.

In 2021, nobody likes programming efficiently in native languages anymore it seems.

That's not the problem. I did GUI programming for a decade before switching to web.

The reason that people write GUI apps in Electron instead of Qt/Gtk is because the latter is so far behind technologically that it feels like ancient technology. Electron has GPU-accelerated, declarative graphics in CSS, it has React, it has the web inspector, it has a scripting language with an extremely good JIT.

Qt/Gtk has not adapted to the state of the art, it has stayed static while the world has moved on. It's now 20 years out of date. That is why people use Electron.

Non-uniform non-platform-widget based rendering of applications is not something I would call state-of-the-art. The overton window has only shifted to that recently. I would claim that a small statically linked executable displaying a native window containing native widgets is state-of-the-art, and would blow everything ever created in webland out of the water instantly in terms of resource usage and performance.

Since you named it explicitly - why would my application want a web inspector or CSS layouting overhead if the goal is to display a small batch of controls? This is exactly the mindset I meant when I wrote my post.

Qt has GPU-accelerated graphics with the QtQuick scene grqph since 2014. Qml is a declarative language and quite easy to learn with Js based property bindings. It also has an inspector with Gammaray and many profilers (e.g. hotspot,heaptrack, qt creator profilers, kcachegrind, massif,...). The real reason why people are not using it more is the licensing LGPL3 is a bit too scary for some people and the commercial license to expensive

Red Hat and other Gnome-/GTK-adjacent people were on the JS bandwagon well before Electron was a thing. Most Electron developers have never actually made a good faith effort to try out JS development using GTK. How many Electron developers even know that when they interact with a vanilla Ubuntu desktop, they are using a window manager and desktop environment written in JS? I'd be skeptical that it was anywhere north of 15%.

If GTK had received a fraction of the attention and misdirected enthusiasm that went into bolstering the NodeJS ecosystem, things would be very different.

I'm with you that most of the criticism of JS is directed at 2011 JS rather than 2021 JS.

A few things that aren't great for my use cases:

- The language has its fair share of footguns. It's a much better language than most people give it credit for, and most of them are easily avoided by a good linter, but still doesn't feel as clean as something like Python.

- The ecosystem is great but it's hard to separate the wheat from the chaff. node_modules with gigabytes of dependencies isn't even funny. I'd still classify the ecosystem as a big win for JS, but there are things that could be handled better.

- The standard library is awful and some parts are downright broken (e.g. dates). If I'm using C++, Java or Python I have at my fingertips very powerful data structures an import away. Many of those things are also available for JS, but they come as separate dependencies.

- Having the same language full-stack is nice, but client-side JS and server-side JS are different enough that there's going to be a context switch regardless. That point is true but somewhat oversold.

(You didn't say this and I'm not going to claim you did, but don't even get me started on how full stack JS evangelists try to sell you mongoDB-like datastores. There is a 99% chance the correct place to put your data is a SQL database.)

- It doesn't play nice with C.

- Doesn't lend itself to quick stuff outside the browser/web server paradigm. Things like OS scripting or small ad-hoc programs.

> Things like OS scripting or small ad-hoc programs.

I would imagine that you can run those in Deno (for example ) just fine?

I have no doubts that Deno or Node can run those fine, but their evented interfaces make everything harder than it needs to be, especially since those tasks often require reading and writing to stdin/stdout/files.

It's not a problem for larger projects, but very clunky in a script.

From what I can tell, Deno doesn't force you to use evented interfaces for I/O.

Reply on news.ycombinator.com