[HN Gopher] JavaScript Gom Jabbar
___________________________________________________________________
JavaScript Gom Jabbar
Author : disadvantage
Score : 152 points
Date : 2023-07-02 18:12 UTC (4 hours ago)
(HTM) web link (frantic.im)
(TXT) w3m dump (frantic.im)
| Dudester230602 wrote:
| This COBOL will keep feeding us until proper GPT tooling arrives
| making the whole hands-on coding side of work obsolete.
| mock-possum wrote:
| > double-escaping JSON-formatted arguments
|
| God how I hate anything to do with command line
| jahsome wrote:
| This was delightful.
| voz_ wrote:
| JavaScript IS the gom jabbar
| strken wrote:
| JavaScript is the gigantic man-eating worm that we all rely on
| for our spice.
| Hackbraten wrote:
| I love Alex Kotliarskyi's writing style.
| ncr100 wrote:
| > There's left-pad, the legendary tiny package that broke all
| internet, collectively causing the amount of pain and drama
| comparable to the destruction of Alderaan.
|
| Mind blown. Awesome.
|
| It's like a stand-up comedy routine delivery.
| revskill wrote:
| Typescript is the JS life-saver.
| tomaskafka wrote:
| What a nice Deno promo :).
| uglygoblin wrote:
| I tell myself the only reason they grow into these monstrosities
| is because they were successful projects but I know this is just
| a coping mechanism.
| Waterluvian wrote:
| So many of these points feel like superficial pains that are
| really quite optional. So many things don't actually matter
| beyond offending our sensibilities.
| nosefurhairdo wrote:
| They're painful because nobody is willing to argue the
| "business justification" for cleaning up tech debt, so your
| management asks you to hack away at the next feature instead.
| We've inherited a mess that slows us down in ways we can't
| produce metrics for, so we can't explain with pretty graphs how
| much more effective we would be if we cleaned up our config and
| tooling.
| james2doyle wrote:
| Not everyone has a choice to not make these decisions. They
| inherit a project that is already mired in scripts, tools, and
| dependency hell.
|
| If your CI fails because of eslint is it really something
| superficial and optional?
| ghayes wrote:
| I'm not sure if they are all optional, since half of the pain
| comes from dependencies of dependencies, where you have very
| little control (esp in the npm world where you can't override
| resolutions).
| blehblahboo123 wrote:
| The JavaScript ecosystem is a result of tech bro/hipsters
| discovering web development. If they all could jump on the next
| profitable scheme. The rest of us would enjoy it more.
| afavour wrote:
| I have to disagree. The ecosystem is what it is because the
| hipsters left it and it became the spiritual successor of
| Java's enterprise-y mindset.
|
| When I think of JS hipster I think of CoffeeScript, Elm,
| ClojureScript and all the other trendy stuff from a decade or
| so ago. JS borrowed enough stuff from them to be tolerable and
| now everything is React and Webpack plug-ins.
| 0xr0kk3r wrote:
| Not just techbro/hipsters: programmers have huge egos, when in
| reality they are just mediocre tradesmen. Like your typical
| construction worker. There are 10,000 hammer swingers for every
| architect, but those 10,000 think they are all in the top-10.
| So we end up with egos and factions creating a tidal wave of
| mediocre tools, each with just enough fan base to grow large
| enough to be cancerous. Too few architects with experience at
| the helm (and trained by the old guard), unfortunately, is the
| problem.
| imbnwa wrote:
| >The type is set to module. This has something to do with the
| migration from requires to imports. Why do we have to care about
| this, again? The extensive pain you've experienced trying to
| importing ES5 modules from ESM modules and vice versa overwhelms
| you again.
|
| Would anything truly have been lost if Node simply ignored ESM?
|
| The half-measure seems, abstractly, worse than announcing that
| Node was all-in on ESM, deprecating CJS by a certain LTS release,
| as the end-user has no real notion of the ultimate destination of
| ESM in a Node project; what is the struggle for?.
| jitl wrote:
| Jarred says it best: https://bun.sh/blog/commonjs-is-not-going-
| away
|
| - 75% of NPM is CommonJS
|
| - It's better for lazy loading / cold start outside the browser
| than `await import(...)`
| Jarred wrote:
| ESM has nice things too, like top-level-await and strict mode
| by default. Explicit imports/exports are better for
| autocomplete when TS is unavailable.
|
| I think the ESM slowness can eventually be compensated for
| but it will need spec changes. Possibly the defer import
| proposal.
|
| But yeah, CommonJS is basically never going away.
| xctr94 wrote:
| Progress, the one thing JS has too much of, too quickly,
| without stabilizing for quality.
|
| There are a number of benefits (see the link below). We could
| argue JavaScript shouldn't be isomorphic, as it barely does its
| job well on either end. Node might in fact be better off
| without the 'pollution' of client-side packages, but well...
|
| https://www.reddit.com/r/node/comments/rby64z/why_esm_what_d...
| imbnwa wrote:
| Thing is, Browser JavaScript projects tend to implicitly rely
| on CJS hacks, such as Jest, as the article points out, or,
| and correct if I'm wrong, most popular HRM implementations.
| marcosdumay wrote:
| > Progress
|
| It's lack of quality.
|
| When you have a badly designed layer, you have a lot of
| problems to progress over. And each bit of progress creates a
| whole lot of new problems you can solve with further
| progress.
| z3t4 wrote:
| I think it has to do with Node.js using Chromes JavaScript
| engine called V8. So whatever V8 does, node.js must do too.
| [deleted]
| 0xr0kk3r wrote:
| This is actually pretty funny. I coded javascript for a solid ~18
| years (I stopped about 3 years ago) and the majority of the
| concerns in this list are from the past 10 years. What I find
| glaringly absent, which would have been present if this were
| written in 2013, is the absence of polyfills.
|
| What other things that were JS nightmares in 2013 have largely
| ceased to exist? (Only to be replaced by this funny list.)
|
| This is my favorite part: "You stop to count how many tools and
| parsers work on your codebase: TypeScript, esbuild, swc, babel,
| eslint, prettier, jest, webpack, rollup, terser. You are not sure
| if you missed any. You are not sure if you want to know. The
| level of pain is so high you forget about anything else."
| k__ wrote:
| Grunt, Gulp, CoffeeScript, IIFE, overridden undefined, with,
| closures to create private fields, modified prototypes,
| variables global by default, call-site-this, automatic
| conversions for comparisons...
|
| Ah yes, over a decade of JS.
| yawnxyz wrote:
| dealing with IE6 nightmares
| Sivart13 wrote:
| this list feels just a short jump from "we didn't start the
| fire"
| intesars wrote:
| TS and NodeJS is has become my fav for web.
| mock-possum wrote:
| Have you played around with the Lit library for defining UI
| components / custom web elements? It's pretty slick.
| [deleted]
___________________________________________________________________
(page generated 2023-07-02 23:00 UTC)