25 ms·

JavaScript Gom Jabbar

• Hackbraten 3y ago
  I love Alex Kotliarskyi’s writing style.
  • ncr100 3y ago
    > 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.
    • jrflowers 3y ago
      It reminds me of the end of Neo’s “tears in the rain” monologue when he says “Now I know what a TV dinner feels like”
      • selimthegrim 3y ago
        Neo?
        • jrflowers 3y ago
          The timelord.
          • vba616 3y ago
            On an unrelated note, should I be concerned if a British style police box seems to have appeared in a random location in my town? ...and it's red? ...and there is a line of tiny skulls on stakes near it? ...and until I checked Google Street View I could swear it was blue when I drove past?
            • selimthegrim 3y ago
              Only if there’s VHS cases on top of it
              • vba616 3y ago
                I really don't know anything about Dr. Who. All I know is allegedly, according to Google today, in this particular timeline, the Tardis is not supposed to be red. And I remember this, from the VHS era: https://www.macintoshrepository.org/3913-daleks https://www.macintoshrepository.org/3913-daleks
                • ncr100 3y ago
                  What is this thread. I am thankful for it. Edit: I too remember the Daleks game. <3 A round of Member-Berries for all of us! <3
            • jrflowers 3y ago
              According to the lore it’s fine as long as you hit 88mph
• voz_ 3y ago
  JavaScript IS the gom jabbar
  • strken 3y ago
    JavaScript is the gigantic man-eating worm that we all rely on for our spice.
    • masswerk 3y ago
      To be fair, as already mentioned in other comments, it's the JS ecosystem. Writing plain vanilla JS in a text editor is still a pleasant experience. (However, this is deemed impossible, nowadays.) Having said that, I do get the comedy.
    • saint_yossarian 3y ago
      JavaScript is the little death that brings total obliteration.
  • AmericanChopper 3y ago
    If this is a reference to the Bene Gesserit test of humanity, then the gom jabbar is not the device that causes the pain. The gom jabbar is the needle with a poison tip held to the neck of the test taker. It’s just a poison weapon. Alia kills the baron with a gom jabbar.
• imbnwa 3y ago
  >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?.
  • xctr94 3y ago
    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_does_it_solve_for_node_and/ https://www.reddit.com/r/node/comments/rby64z/why_esm_what_d...
    • imbnwa 3y ago
      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 3y ago
      > 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.
  • deleted 3y ago
    [deleted]
  • jitl 3y ago
    Jarred says it best: https://bun.sh/blog/commonjs-is-not-going-away 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(…)`
• 0xr0kk3r 3y ago
  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__ 3y ago
    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.
    • Sivart13 3y ago
      this list feels just a short jump from “we didn’t start the fire”
      • eyelidlessness 3y ago
        The only change in lyrics is “it’s been burning us since…”
      • Ygg2 3y ago
        "It's been burning, since IE was turning"
      • theblazehen 3y ago
        Inspired by it: We're gonna build a framework https://www.youtube.com/watch?v=Wm2h0cbvsw8 https://www.youtube.com/watch?v=Wm2h0cbvsw8
• uglygoblin 3y ago
  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 3y ago
  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 3y ago
    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.
    • Uehreka 3y ago
      At a previous job where I had to deal with this stuff, I was able to make the case for an “update task” every six or twelve months, where we’d update all of the dependencies, change the config files that needed to be changed, etc. This would require a full-regression test, but this employer was in the business of doing these fairly frequently since they were super risk averse, and so adding another full regression test that only happened every six months or so was no big deal. We’d update a ton of stuff, inevitably break some obscure feature when used in IE11 (which at the time, they still supported), so we’d add a polyfill or chuck a dependency through babel and problem solved. Then nothing for 6–12 more months. This was annoying, but not nearly as annoying as taking inventory at a grocery store or dealing with bad customers at a restaurant. It’s just work, and we were paid to do it.
  • ghayes 3y ago
    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).
    • dezsiszabi 3y ago
      You can override the dependency of a dependency in npm. https://docs.npmjs.com/cli/v9/configuring-npm/package-json?v=true#overrides https://docs.npmjs.com/cli/v9/configuring-npm/package-json?v...
• intesars 3y ago
  TS and NodeJS is has become my fav for web.
  • mock-possum 3y ago
    Have you played around with the Lit library for defining UI components / custom web elements? It’s pretty slick.
• mock-possum 3y ago
  > double-escaping JSON-formatted arguments God how I hate anything to do with command line
• revskill 3y ago
  Typescript is the JS life-saver.
  • shepherdjerred 3y ago
    TypeScript doesn't solve any of the issues mentioned in the article
    • revskill 3y ago
      It just solved the "untyped" problem, and it's more than enough.
      • shepherdjerred 3y ago
        Yes! TypeScript is fantastic, but you still do need the pain of the JavaScript ecosystem to do much with it.
    • vbezhenar 3y ago
      And adds its own layer of weirdness. Just one simple example: you must write `import { name } from "./file.js"`. Not `"./file.ts"`. Why js? Because TypeScript developers are stubborn that their thing is just a layer on top of JS so they refuse to change ".ts" to ".js" in the generated output. This is just wrong approach. But here we are, importing things from "./file.js" which doesn't even exist.
      • leshenka 3y ago
        if `import { name } from "./file"` doesn't work for you, something's up with your setup
        • shepherdjerred 3y ago
          I don't know the details, but I think there's some new-sh flag or something in TypeScript that requires the `.js` extension. I don't know if they're pushing that to be the default or what.
• tomaskafka 3y ago
  What a nice Deno promo :).
• Dudester230602 3y ago
  This COBOL will keep feeding us until proper GPT tooling arrives making the whole hands-on coding side of work obsolete.
• jahsome 3y ago
  This was delightful.
• blehblahboo123 3y ago
  [flagged]
  • 0xr0kk3r 3y ago
    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.
  • afavour 3y ago
    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.
• deleted 3y ago
  [deleted]
• unsupp0rted 3y ago
  > Every time you modify dependency list, some of the dependencies print out screens-worth of messages to your console, asking for donations, warning about breaking changes.
• joeyguerra 3y ago
  it's not just javascript.
• quxbar 3y ago
  I appreciate the playful tone, it's good to be reminded of these pain points after the first few layers of skin and nerve endings have burned away. On the flip side, I can throw a hungry junior dev with a new macbook into the deep end, and they can be productive within a day. They don't have to know anything about containers, .net, nginx, or the top 100 most common command line tools. When they hit an issue they can just google it.
  • dfsafklsjv 3y ago
    > When they hit an issue they can just google it. Now they chatgpt it.
    • jszymborski 3y ago
      And get unreliable results from a stochastic parrot
      • voz_ 3y ago
        I regularly find chatgpt to be better than googling for code related stuffs.
        • jszymborski 3y ago
          I think that speaks more to how much Google search result quality has plummeted over the years more than its suitability for the task. > regularly The trouble lies in the credible sounding results that are in fact subtly (or less subtly) nonsense. It's a bit like old W3schools but instead of poor practices, its authors were half-in-the-bag
          • voz_ 3y ago
            I’ve no problem distilling those! I find stackoverflow and co to be of worse signal:noise
      • logicallee 3y ago
• cxr 3y ago
  This is yet another case of people saying "JavaScript" when they mean "a bunch of Node ecosystem junk". Right out of the gate: > It’s time for your test. You are sitting in front of a computer. The test is simple: you have to open a package.json file and read it. And it continues in that vein. For all the stuff mentioned, there's actually almost nothing that has anything to do with JS per se.
  • dfsafklsjv 3y ago
    Try writing any JS without a bundler that uses package.json. I mean really, try it. Until ECMA codifies a package manager or bundler in the official specs, package.json is de facto part of JS.
    • chrisco255 3y ago
      > opens dev tools > types `console.log("this is impossible without a package.json")` To my astonishment, it worked, without a package.json file. I definitely prefer using npm for any non-trivial front end, but let's be real: JS is an integral part of the web stack. You can even inline JS inside a <script> tag on an HTML file. It's not that hard.
      • floydnoel 3y ago
        I do sometimes wonder how many of the critics have only ever worked on Angular frontends and such. The frontend for my little site https://bongo.to https://bongo.to doesn't use Node or NPM at all. Just a script tag, like you said. It's very simple and easy to use JS this way, and I wish people would learn to do this before learning how to write a SPA in the framework du jour.
        • philipwhiuk 3y ago
          `<!-- prettier-ignore -->` You run prettier though? How do you download and run it - it seems to require Node.
• cobertos 3y ago
  And here I was thinking the first thing about version was going to mention that v0.x.x (major 0) semver packages are considered "unstable" and every update to the version string, even minor or patch numbers, is considered a major update, by the logic that determines whether or not to update the package/which compatible highest version to install
• nologic01 3y ago
  What would be the minimal but modern setup to develop web apps that use javascript to good effect in conjunction with an agnostic server stack. I am intrigued by "less js is more fun" approaches like htmx and alpine.js but that still leaves a range of options on how to organize things and some may bring you dangerously close to what OP describes.
  • irrational 3y ago
    Just a .JS file. Oh, modern. Sorry, nothing but unnecessary complexity and suffering is allowed in modern dev environments.
    • nologic01 3y ago
      Was meant to be a serious question :-) There must be a sweetspot of tools and designs that helps organize a modest code base to get the benefits of reusability and readability without too heavy a penalty. Imho frontend people gladly walked into the trap of "excess complexity" as this elevated this niche into a "serious" business. Whenever some aspect of tech doesnt make sense, follow the money and this usually clears things up.
      • jrajav 3y ago
        Native DOM APIs are a lot nicer than they used to be. Just JS will work just fine as long as you're comfortable building a whole UI yourself. You can sprinkle on Typescript for static types (which I wouldn't do without for any serious project, myself), esbuild for bundling, then serve it how you like. The issue you might run into as you scale up is managing the state and synchronization of a large, complex UI. This is where having a reactive, declarative interface can help out a lot - which is why you arrive at React and tooling around that, or something much like it. That's where most large UI projects end up, frontend or backend.
        • t0astbread 3y ago
          Don't know if it's still a good approach but a few years ago I used Preact with htm without any build tools for a project. No compilers, bundling or package managers, on my part. (Preact and htm were, of course, pre-compiled and bundled so that might be a turn-off with this approach.) The Preact devs provided CDN links to add to your app but I decided to just download the two JS files and host them with the app's files. My only gripe back then was that the bundle for the Preact hooks library somehow had a CDN location hard-coded so I had to decide between using the CDN but having hooks or using class-based components but having it all local.
• mikl 3y ago
  > Oh, dear jest. […] Properly configuring it with ESM and TypeScript was a PhD science project. No kidding, I had to do this recently. It was a trek and a half.
  • dylanowen 3y ago
    Same here. Once I thought the nightmare was over another team's dependent project's jest started failing for a different reason.
• lukev 3y ago
  I'm a polyglot developer who likes to think they're comfortable in a wide range of programming paradigms and languages across both frontend and backend. This is pretty much exactly my reaction any time I see a package.json longer than ~20 lines.
  • airstrike 3y ago
    Same. But commenting to make an off-topic remark: the link in your profile is blocked by uBlock Origin and leads down a rabbit hole of strange websites. Since I never used hackernewsers I can't tell if it's working as expected, tbh
    • lukev 3y ago
      Huh. Thanks for the heads up. Used to be a useful service but apparently the domain expired and was replaced by spam.
  • LilBytes 3y ago
    stairs glaringly at the new Angular front end we're developing that has four seperate front end components, each with package.json files of 200+ lines Speaks out loud, hoping to keep the demons at bay. “I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain.” cries
    • zelphirkalt 3y ago
      Very in tune with the reference of the articles title.
• spartanatreyu 3y ago
  The article was fine until this part near the end: > engines prominently lists node. And while you hate it with the depth of your soul, you are not going to Bun or Deno because you know this will not stop the pain. This will only make the pain worse. Deno will make the pain worse? Nearly every complaint in the article could have been solved by using Deno. - Package.json, no such thing for Deno (not unless you go out of your way to infect Deno with it) - main, browser, and fs don't matter in Deno since Deno's APIs are based on browser APIs. - type, module, requires, and imports doesn't matter in Deno since it shares the same import API as browsers. - scripts, doesn't matter since all Deno projects have the same tools built-in (benchmarker, bundler, compiler, formatted, linter, task runner, test runner, etc...) - watchman doesn't matter since deno has watch support built in - dependencies doesn't matter anywhere near as much because Deno comes with a standard library - left-pad doesn't matter because it's part of the language - moment.js doesn't matter since you can just use the browsers built-in Temporal api - resolutions, dev-dependencies don't matter for the same reason that dependencies doesn't matter - eslint doesn't matter since deno has a linter - postcss matters less because modern css is great - jest doesn't matter because deno includes a test runner - no need to work out typescript installation with your dependencies because deno includes typescript and has less dependencies The only things not solved by using deno is version and name, which are universal concerns amongst all projects, not just the js ecosystem.
  • phist_mcgee 3y ago
    There's a lot of 'just' in your argument. As programmers we fall into this trap where we think that 'just' doing something else will solve all our problems. But I can guarantee that it's never that simple, and for the people who consume your library, it won't be either.
    • spartanatreyu 3y ago
      There's a lot of 'just' in your argument. I used the word "just" once in my comment in the point about using Temporal. The Temporal spec was created in part specifically because of the issues with moment.js. ---------------------------------------------------------------------------------------- > But I can guarantee that it's never that simple, and for the people who consume your library, it won't be either. Unfortunately, Node has historically not used the same standards as browsers over a whole swath of functionality, which lead to differences in the language based on whether it was running client-side or server-side. Simple libraries intended to run anywhere would sometimes need to release a client version and a server version. Even when node started adding support for the standard APIs instead of creating new proprietary APIs, they ended up with a fractured ecosystem where some things would only work with the proprietary APIs, and some would only work with the standard APIs. There were so many missteps with node that the creator of node essentially said screw this, I'm starting again from scratch, hence: Deno. Coming back to your point: > But I can guarantee that it's never that simple, and for the people who consume your library, it won't be either. But it *IS* that simple. How? Because Deno uses the standard APIs for things. If it already works in the browser, it will continue to work in the server. No more fractured language.
• shanghaikid 3y ago
  Yeah, these are pain points for engineer, but not for any product, so there is no priority and space to improvement.
• thewarpaint 3y ago
  It feels as if JavaScript (and its ecosystem) has left us all with PTSD that makes us unable to appreciate the comedy on this post. So much “serious” discussion around a funny piece. Feel free to dissect it as you may, but keep in mind its true intent: humour.
  • pwdisswordfishc 3y ago
    Just because it’s humorous doesn’t mean it’s not serious.
• sgammon 3y ago
  What a wonderful piece. Phenomenal writing
• fnord77 3y ago
  I still think it is funny that javascript has nothing to do with java except marketing
• gpspake 3y ago
  This is the world I live in. Loved every word of it :)
• jszymborski 3y ago
  Am I the only person who actually still kinda like gulp?
• shepherdjerred 3y ago
  Every time I start up a new JavaScript (well, TypeScript) project, I go through the usual routine. Usually it's a front-end project, so I'll pick my framework. Usually React, although I've been wanting to try out Svelte. Next my bundler, which used to be create-react-app, or some other Webpack wrapper. Today, Vite is the best choice because it works pretty well without much configuration, and it supports all of the major frameworks which is quite nice. I'll be sure to install and configure the TypeScript compiler, which is usually copy-pasting from a template. I always make sure to target the latest well-supported version of JS and use ESM modules, because I like being on the bleeding edge. Next up I setup linters -- eslint + prettier. They do a good job. I have to configure eslint so that it plays nice with Prettier, and I also have to configure eslint for TypeScript and add any other plugins that the project might need, e.g. those for React. I usually like to setup some kind of pre-commit hook to run Prettier and eslint before committing, which saves time. Additionally, I always install my IDE extensions and try to create a .devcontainer file or add list of recommended extensions so that both myself and others can setup their IDEs in the future. I tend to not configure eslint much and just use off-the-shelf configurations because I don't care about the style, I just want consistency in the code and mistakes to be caught. Next up I setup my unit tests, usually jest or vitest or similar. Lots more configuration for TypeScript and whatever, and also usually a set of eslint rules. Then I want a CSS framework. I like tailwind, so I install that and styled-components and twin.macro so that it all works nicely with React. Fonts and icons are often needed too, so I install a plugin for Google Fonts and whatever font library. Anyway, after about a day of doing the above I'm ready to program. Why is it so much work? Why isn't there something that just works for 90% of the use cases? So many people are using Vite + TypeScript + [React|Vue|Svelte] + [eslint|prettier] + [tailwind|bootstrap] + [jest|vitest]. Why isn't there some non-configurable library that just does everything for me?
  • petesergeant 3y ago
    I just copy my TypeScript starter directory over, and change the name in package.json, although admittedly I'm only ever doing back-end stuff -- couldn't you set something up like that for yourself?
    • 3y ago
• cunningfatalist 3y ago
  This so accurate it hurts. And it's also super funny. Good job :)
• ropable 3y ago
  Every time I get close to being tempted to try out JavaScript again for anything beyond basic DOM manipulation, I read something like this and slowly back out of there, trying to avoid any eye contact.
• vbezhenar 3y ago
  JavaScript tooling it bad. So many half-ready choices. I tried to set up TypeScript project for last few days. It's a major pain. I originally wanted to use multi-module project: 1 node.js server, 1 webapp and shared code. I spent too much time trying to figure out all those things, TypeScript moduleResolutions and whatnot just to throw it all away. To hell with it. Yesterday I tried to understand how would I generate type-safe server code from OpenAPI spec. No way. zod, yup, ajv, wtf, but just dumb simple openapi generator which can generate code even for Ada, but node.js does not exist. I love TypeScript, I love node, but I so much hate all the associated tooling. It's incredibly terrible. I don't want to make a single choice. I want a single build system which does everything good enough. I want a single "Spring Boot" framework which does everything good enough. I want a single linter, which built into my IDE and does not require me to exclude my dist folder. I don't want to configure my TypeScript compiler, it should be smart enough to configure itself. I don't want to spend days reading about project references, npm workspaces and other stuff. I want to create few folders like I do with maven and it's just works. I don't want to browse 10 different libraries for typings (why is it even needed for typescript???). I want things like JSON parsing and validation to be built into language or stdlib. I hate go language. But their tooling is so right that I can withstand all those `if err != nil` every second line.
  • kozzz 3y ago
    [dead]
    • vbezhenar 3y ago
      It is client API. I was talking about server API. For example express.js or fastify-based.
      • kozzz 3y ago
        [dead]
        • vbezhenar 3y ago
          Thanks for pointers. I'm afraid, that's a bit wrong direction. I'm talking about spec-first development. This project generates spec from sources. For now I think I'm going to use zod, as it seems popular enough and pragmatic enough.
• WirelessGigabit 3y ago
  It's 2023 and NPM still doesn't support a comma after the last item in a list, and no comments. It's still stuck to the same old JSON version that it used on day one. Also, I started with `grunt` before using `gulp`. And I used `bower_components` to build a website. I try not to remember too much though. There is only so much that therapy helps. I just do Rust now. It's not perfect by any means but at least there is design there.
  • troupo 3y ago
    > It's 2023 and NPM still doesn't support a comma after the last item in a list, and no comments. It's still stuck to the same old JSON version that it used on day one. Because that's the only version of JSON. It never changed: https://www.json.org/json-en.html https://www.json.org/json-en.html
    • WirelessGigabit 3y ago
      https://spec.json5.org/ https://spec.json5.org/ Maybe not by the original people, but still a superset. And a more useable superset.
      • troupo 3y ago
        There are multiple supersets of JSON with various degrees of adoption. Adopting anything else but JSON would probably break innumerable tools that rely on the package.json format. Note: the stable version of json5 spec was only released in 2018.
    • pvillano 3y ago
      # Parsing JSON is a Minefield "The conciseness of the grammar leaves many aspects undefined. On top of that, several specifications exist, and their various interpretations tend to be murky." https://seriot.ch/projects/parsing_json.html https://seriot.ch/projects/parsing_json.html
      • pvillano 3y ago
• yard2010 3y ago
  I didn't like the Netflix dramatization, but I'm waiting for the next post about python and optional requirments.txt :)
• Jach 3y ago
  "I followed the instructions and it said I didn't have grunt installed. Now I'm an old guy so I didn't really know what grunt was and my grunt files weren't right or something. So I googled a bit and I found out what grunt was. Grunt's... I still don't really know what it is." --Joe Armstrong, https://www.youtube.com/watch?v=lKXe3HUG2l4 https://www.youtube.com/watch?v=lKXe3HUG2l4 The other day I ran `gem install wayback_machine_downloader`. I never liked Ruby the language enough to get into its ecosystem, but I note that said ecosystem has from an outside perspective remained remarkably stable. gem is still the thing to use (dear god Python what became of you), Rails is still around... I'm waiting to work on a new project with a complex enough front-end that justifies more than 0-30 lines of JS, then I can be happier with HTMX instead of whatever giant framework is most popular these days.
• epolanski 3y ago
  I will be honest, the first ecosystem I started in was node, and I absolutely think that those that I learned later had their insane share of issues too. Haskell has proven very hard to use cross machine, installing it on MacOS in 2019 was painful, the ecosystem is painful to handle, there's a huge macro/extension confusion, language isn't very retro compatible while you can generally expect 2010 JS to work in 2023 out of the box. Even creating a full fledged docker image, codespace/gitpod-like proves difficult, the base one provided by GitHub kinda sucks and has issues. C has proven generally okay to work on most platforms but the language is honestly complex and the sheer amount of knowledge of systems (in all possible meanings of the word), produces non-portable code that doesn't fit most usecases of general programming. I could go on, but everyone who has tried several languages knows that we all suffer and will always suffer with several shortcomings in all kind of ecosystems. Php has always been one that I've never got to setup a project in less than few days. Elm is the less painful but the ecosystem suffers from its own degree of benevolent dictator's state and rate of development.
  • parasti 3y ago
    Is C complex? It's probably the one language that I can keep in my head regardless of usage frequency. Parts of modern JavaScript syntax evaporate from my memory easily and I write that language daily.
    • ygra 3y ago
      I guess it's not so much the language that is complex. Indeed, it's pretty simple for the most part (although there are archaic warts few people ever need and modern features that sometimes feel like C versions of C++ features). But the result has some emergent complexity because of the simplicity and lack of guarantees. When every line coupled with an antagonistic (i.e. optimizing) compiler has the potential to bite you and you no longer think about the apparent semantics of your code, but rather the semantics guaranteed by the C abstract machine that no one actually really knows, I guess the result is not very simple anymore.
    • otikik 3y ago
      I wouldn’t say it is complex, but since it is relatively low-level it doesn’t insulate from a lot of things that other higher level languages handle for you. Like the fact that an int has different sizes depending on the compile target. Or that one must remember to call this one function before calling this other function, otherwise Bad Things Happen (but it might only be visible way later, in production).
• thesuperbigfrog 3y ago
  [Old school JS developer reading the article and suffering PTSD and flashbacks] I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past, I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. [Finishes reading the article and realizes they survived, but now all sweaty]
• Makhini 3y ago
  As a Java developer, why the hell does Javascript still doesn't have a equivalent of Gradle or Maven? An extensible build tool that does it all and uses sensible defaults?
  • vbezhenar 3y ago
    One issue with JS is completely different environments. There's very little in common between node.js and browser environment. For node.js you technically don't need a build system at all. For browser: it depends. Until recently you had to bundle your frontend into a single or few large files. Right now you technically can develop a frontend without a build system either, at least when it comes to your code, without dependencies. Second reason is quickly moving APIs. Common.js, AMD, ESM. Those are foundational APIs and they were changing every few years. Just similar Java example: java modules were introduced in Java 9 and even today maven (AFAIK) does not utilize those at all. But java modules were infinitely more compatible with old code. Third reason is TypeScript. It does require a "stripping types" step which could be counted as a compilation. Fourth reason is community. I don't really know what's so special about JS community, but they deliver new tools and frameworks at alarming speed. There's no single source of truth. You can't really do anything with this chaos. Google develops angular, but it's not popular. Facebook develops React and it is popular but people still use other frameworks like vue from small companies. 10 years ago I thought that with time things will settle down. Now I'm not so sure.
• mattlondon 3y ago
  This is not about javascript, this is about npm. I detest npm and avoid it at all costs preceisely because of all this junk (personally I use Deno, but at work we use something like bazel with a monorepo that means we don't need npm), but I find Javascript/Typescript a lovely language to program in and it is my absolute number 1 goto language for anything. It makes me sad when people say "javascript sucks!" but actually they mean that using npm to build react applications suck. Modern Javascript/typescript is an absolute joy to code in.
  • cnity 3y ago
    I agree. I am working on a video game and decided to use no dependencies (at all!). It has been such a joy to code.
    • berniedurfee 3y ago
      I’ve been writing a bunch of GitHub actions lately and immediately fell into the habit of just using someone else’s action in each step. I went back and rewrote almost everything to remove dependencies and I just write little shell scripts to do what I need rather than relying on someone else’s little shell script that hasn’t been touched it 2 years. The fewer dependencies, the better I can sleep at night.
      • vbezhenar 3y ago
        https://github.com/cmctec/ci-workflows/blob/main/.github/workflows/docker.yaml https://github.com/cmctec/ci-workflows/blob/main/.github/wor... This is my shared workflow which I apply to few dozens of projects in my company. Works like a charm! Extremely simple and understandable script. Build times are mere seconds (when cache works). I tried to understand this whole github actions stuff but decided that I don't need all that complexity.
• carrja99 3y ago
  Sorry I pulled my hand out at “left-pad”.
• menacingly 3y ago
  I've said it before, but the node build tool ecosystem looks like any project in any language where no one was around to tell a bright young developer "no"
• tiborsaas 3y ago
  I have a new side project and I started coding it in Deno just to try something now, but not too far from the tree. Not having to worry about setting up TS, bundling, linting is a breath of fresh air. No node_modules, just a depts.ts file to manage my imports. This also means no yarn, NPM or PNPM to decide. It still has a learning curve sometimes because some tooling is not mature enough, but it's nice figuring out that I don't need PM2 just a systemd service to keep the process alive.