On the current typescript / anti-typescript internet drama I saw someone mention javascript without a build step.

Do you think we’re already there?

Last time I attempted it:

  • there were too many libraries I couldn’t import
  • JSX (using babel) had a warning saying you shouldn’t do it in the browser for production
  • there was some advice against not using a bundler, because several requests for different .js files is slower and bigger than a bundled package
  • JackbyDev@programming.dev
    link
    fedilink
    English
    arrow-up
    2
    arrow-down
    1
    ·
    1 year ago

    I don’t do front end work so I don’t know how all the terms are used. If by build step you mean any sort of CI process then I would say no, I think automated tests are important and should be ran before pushing.

    If you just mean some sort of transformation, transpilation, bundling, etc. then I don’t know enough to answer. My gut feeling is that the question is framed incorrectly. Many of these things were made as workarounds for various problems (or to make things easier). If you don’t have those problems then you don’t need those solutions. It doesn’t have anything to do with progress (as in what year it is). Originally JavaScript was just plain old JavaScript. If it worked then it can work now. If you need the solutions people have made to get around limitations and short comings and vanilla JavaScript can’t do it then you’ll still need those solutions.

    • alr@programming.dev
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      That’s a great point. In any sort of enterprise system, you should be unit-testing your front end when you commit, and you should be UI-testing your front end before you deploy. If you’re in a CI/CD pipeline, that normally happens right after the build step. If you need to have the pipeline running anyways, you might as well build.