• codeinabox@programming.devOPEnglish
      93·
      2 months ago

      The way the author described programming in 2025 did make me chuckle, and I do think he makes some excellent points in the process.

      It’s 2025. We write JavaScript with types now. It runs not just in a browser, but on Linux. It has a dependency manager, and in true JavaScript style, there’s a central repository which anyone can push anything to. Nowadays it’s mostly used to inject Bitcoin miners or ransomware onto unsuspecting servers, but you might find a useful utility to pad a string if you need it.

      In order to test our application, we build it regularly. On a modern computer, with approximately 16 cores, each running at 3 GHz, TypeScript only takes a few seconds to compile and run.

    • squaresinger@lemmy.world
      41·
      2 months ago

      Hmm, partially. One real thing that I see now is cloud costs. All of the stuff we now have in our pipeline does inflate our costs quite a bit, which then puts pressure on the budget and that crunches everywhere.

    • hornywarthogfart@sh.itjust.worksEnglish
      2·
      1 month ago

      What’s funny is if you added another “level” to this going back another 15 years there would be someone complaining about the same things but with Java as the target. “Java is slow” wasn’t just a joke for no reason after all.

      There are some funny parts in the post as well as some true statements to the current state of things. We’ll see another post like it in 10-15 years and it will be a chuckle. Then we’ll all continue as we always have and deal with whatever comes down the pipe next.

      It’s what humans do and it isn’t restricted to technologies or programming languages.

  • Eager Eagle@lemmy.worldEnglish
    13·
    2 months ago

    Every time I read something like this it comes to mind that we’re more likely to remember the good bits of the past than the struggles. People use containers because the “works on my machine” problem was a constant pain.

    You can still ship code into production quickly if you pair program and commit to trunk to bypass the code review process, and have a CI/CD pipeline set up to automatically build and publish the package.

    And I’d much rather have a cloud env pull my code and automatically deploy something than manually transfer files over FTP.

  • Caveman@lemmy.world
    10·
    2 months ago

    I started programming in 2015 and I’m very surprised that webapps have managed to get worse in that time period. We have 10 years of work on the V8, 10 years of React and Angular, 10 years of DX improvements and my current work is C# takes a minute to compile and Angular takes 4 minutes for a production build.

    I know now we have TS and there’s a lot of safety that comes with it but somehow things are just slow, both building and on deployed websites. Websites should be snappy when everyone has a GPU that can go incredibly fast compared to 10 years ago and cores that are 2x faster and 4x as numerous.

  • albsen@beehaw.org
    9·
    2 months ago

    well there is some Rust building up under that JavaScript… maybe that can save us.

      • Ephera@lemmy.mlEnglish
        5·
        2 months ago

        Their primary purpose certainly isn’t the same, but with JavaScript being used to implement text editors, it’s in a playing field where many would argue that Rust is better suited.

        Well, and Rust can play in JavaScript’s playing field, too: You can implement webpages in HTML+CSS+Rust by going through WebAssembly.

  • TehPers@beehaw.orgEnglish
    6·
    2 months ago

    I miss the days when it was simpler as well. Back before there were botnets with hundreds of thousands of compromised routers across several countries that could send tens of terabytes per second of data to your server for a sustained period of time. Back before there were thousands of bots crawling every IP and domain imaginable for exposed, abusable ports and wp-admin endpoints. Back before people started to compete in how many 9s of uptime they supported (before killing that all with LLMs anyway).

    Sadly, we can’t go back to those times. Doing so with a production service would not end well.

    The issue is not npm. Npm is a solution to a problem, even if it isn’t perfect.

    The issue is we live in a different landscape.

    Eclipse was great, having used it in the past, but its features are not exclusive to Eclipse. I can do the same inlining and extracting of code in vscode with code actions. The compile times weren’t seconds for me in the past, but they are for me now. Vite helps that even more (though that’s comparing JS to Java).