221–230 of 248 posts
Earlier quoted context omitted.
Didn't python add static typing?
Only type hints. They help a linter/IDE bitch about types but they don't have any enforcement beyond that. They're great for self documenting methods but don't remove any dynamic typing from the language itself.
Coffeescript was well before "tree shaking" (the JS ecosystem's way of spelling "dead code removal") and code splitting, both being relatively new things in the bundler world ("tree shaking" being introduced with rollup if memory serves). Then came Acorn, which gave way to a whole slew of JS transformation bits. It also didn't help that Node was fixed at 0.12 for years and years, and we had the IO.js fork until Node…
> As a maintainer of several large JS packages, and being so dreadfully burnt out on JS, there are other words I'd use to describe the whole thing than "delightful". My first project that used JS was in 1996, so I've been along the ride every step of the way. Up until today where I am working with all of this on an Angular 15 enterprise project. I actually would describe it as delightful, compared to what it was like…
Earlier quoted context omitted.
Not a fan, for one reason in particular: they allow URL imports[0]. It's a massive uptime and security flaw in my opinion that was added because someone asked for it. It's been asked for on the Node repository as well where it's received mixed feedback (namely, negative feedback from several core contributors) due to it being, well... a dumb idea. I've never seen the need for Deno. Every library I've written that has…
They have ways to lock, bundle & version those in the faq you linked, so it doesn't seem to be a problem. I wonder if people have the same complaints about golang
Earlier quoted context omitted.
They weren’t criticizing OOP per se. Before the class keyword, JavaScript had much more powerful OOP semantics using metaobjects.
The class keyword is just syntactic sugar. JS still uses prototypal inheritance. Nothing has changed. Check out objectplayground.com for details.
Earlier quoted context omitted.
Exactly what I thought a few months ago. The DOM and the HTTP api (or pretty much all browser APIs for that matter) should be interfaces that can be implemented in WASM code. I have no idea why this hasn’t been proposed let alone implemented. I mean, why give us the ability to use other languages if we can’t implement the (browser) APIs?
If having access to all browsers API had been a prerequisite to getting WASM on the browser, we’d still be decades away from having that, and we’d still be debating what the APIs should like in WASM. I’m grateful that people went for the pragmatic approach.
Earlier quoted context omitted.
They have ways to lock, bundle & version those in the faq you linked, so it doesn't seem to be a problem. I wonder if people have the same complaints about golang
Locking, bundling and versioning do not solve availability.
Coffeescript was well before "tree shaking" (the JS ecosystem's way of spelling "dead code removal") and code splitting, both being relatively new things in the bundler world ("tree shaking" being introduced with rollup if memory serves). Then came Acorn, which gave way to a whole slew of JS transformation bits. It also didn't help that Node was fixed at 0.12 for years and years, and we had the IO.js fork until Node…
Earlier quoted context omitted.
There are plenty of ways these days to build rich web applications without writing much JS. LiveView, Hotwire, Reactor, LiveWire, Blazor...
Not really against JS as a language, everything against the current state of its ecosystem
I like javascript, but I always think about the time when I was working as a front end developer, and a guy across the room suddenly stood up, walked over to the white board, and wrote "F*CK JAVASCRIPT" in massive letters. I believe his concern was around the lack of type safety (this was before we used Typescript). And this was someone not prone to dramatic gestures. At the time I laughed. Guy must be having a bad d…
My experience with javascript as a non-software developer/non web person has often involved frustration. A good example is an experience I had a few years ago (circa 2018) My work acquired some new software which published some results using a REST endpoint. I wanted to pass some parameters to the endpoint get a response and display the response on a webpage. I'm used to working with Python/R and SQL databases it is…
Maybe it's more simple in Python but this really isn't that complicated, it's certainly not a valid criticism of JS.
I must be the only person left not writing TS at this point. Once EcmaScript adopts optional static types or some kind of standardized type annotations [1] I will probably use those. At least in Node, where I have more control of the runtime version. [1] https://github.com/tc39/proposal-type-annotations
You're not the only one. I'm sure Typescript is nice / better, but I don't feel like having yet another bullshit language foisted on me. Also I dislike Microsoft.