5 ms·

Webdev truly is one of a kind. Not only do you have your source code, you also have your build code, oddly dictating the organization of your source code. For e

Webdev truly is one of a kind. Not only do you have your source code, you also have your build code, oddly dictating the organization of your source code. For extra fun, some libraries don't build with build system a, others require build system b, when you're lucky enough to have a working mix, changing build systems is better to be avoided. Of course periodically the officially blessed build system for your used libraries changes. The webdev ecosystem is so broken, it's no wonder so many websites deliver assets that are extremely suboptimally optimised, big unused blobs of assets /scripts slowing page load, optimising it all is actually made harder than coding it all.

napsterbr 5y ago
> The webdev ecosystem is so broken Allow me to correct this statement: The Javascript ecosystem is so broken. Working with Clojurescript and Elm is an experience that will make most developers fall in love with web development again.
- krapp 5y ago
  Hate to break it to you but Clojurescript, Elm and the whole paradigm of "compile to JS" languages are part of what is broken about the javascript ecosystem. So much unnecessary complexity and energy wasted making javascript pretend to be something it isn't and to make it do things it was never meant to do, pressing a small, simple and powerful scripting language into the service of the profane eldritch abomination that is Enterprise Development.
  - deergomoo 5y ago
    I dunno, I feel that’s like saying that Lisp and Haskell are part of what’s broken about the machine code ecosystem. ClojureScript and Elm aren’t compile-to-JS languages for the sake of doing something weird, there’s just literally nothing else that will run in a browser (except wasm but probably best not to get into that). Different programming languages exist for a multitude of valid reasons, the compiled output isn’t particularly important as long as it can express everything you need it to.
    - krapp 5y ago
      > I dunno, I feel that’s like saying that Lisp and Haskell are part of what’s broken about the machine code ecosystem. It would be if machine code were another high-level text-based language completely unrelated to either Lisp or Haskell with its own semantics, execution model and type system rather than a more directly machine-readable format of those languages themselves. Javascript is fundamentally different enough from a bytecode for any arbitrary language that, at least to me the distinction matters. I can accept that it works well enough that most people don't care, even though I suspect most of the use cases for doing so (error checking, type checking) could be better served with linters or editor tools for JS itself. But the decision to avoid actually writing javascript at all costs has contributed a great deal of complexity in the JS ecosystem, which translates into the bloat in the web that everyone complains about, because all of that javascript is wasting time and cycles simulating other languages.
      - zachrose 5y ago
        > But the decision to avoid actually writing javascript at all costs Who's JavaScript is it anyway? ES7? ES6? Internet Explorer 11's? How do you isolate things for the sake of unit tests and then bring them together into a performant build?
        krapp 5y ago
        >Who's JavaScript is it anyway? ES7? ES6? Internet Explorer 11's? Cross-browser compatible Javascript was a solved problem when JQuery and shimming came along. >How do you isolate things for the sake of unit tests and then bring them together into a performant build? Use one of the many unit testing libraries and frameworks that already exist for Javascript.
  - jupp0r 5y ago
    Hate to break it to you, but what you call "Enterprise Development" is really just "large software projects", for which many find the "simple and powerful scripting language" inadequate.
    - krapp 5y ago
      But those projects use that "simple and powerful scripting language" anyway, so clearly it is adequate.
      - jupp0r 5y ago
        Are you using JavaScript when you are using TypeScript? I guess so, to some degree. The additional tooling complexity is just not that significant compared to the gains of a language that compiles to JavaScript vs using vanilla JavaScript.
- curun1r 5y ago
  Also Trunk [0] for Rust-wasm web dev. It’s made me not hate doing the front end for my projects. I look forward to the Rust web ecosystem evolving to the point where I can recommend it in a work context. [0] https://trunkrs.dev/ https://trunkrs.dev/
jupp0r 5y ago
I see you have never worked on a C/C++ project.
- uhhhhhhhhhhhhhh 5y ago
  Yeah this appears to be more or less the essential complexity of build+link
  - mssundaram 5y ago
    Looks like you may be shadow banned - I vouched for this comment and see all your recent previous comments are dead
- Shorel 5y ago
  I have done both. C++ is miles better in comparison.
  - jupp0r 5y ago
    Maybe you can enlighten me how to easily add a dependency (the equivalent of "yarn add lodash") in a platform-independent way.
    - Shorel 5y ago
      I have used CMake. I added the dependency by writing about three CMake lines. And after that, it just works, for years. I may have to add from 2, to 5 dependencies for a project, instead of the myriad of dependencies in JS. And they don't become obsolete and need an update each week. It's a difference of some orders of magnitude, both in number and in upgrade frequency. This is a huge part of dependency management for me. And there are C++ package managers like Conan, which solve your requirement of adding a dependency by just using the command line. I will probably use Conan if I have to write C++ again.
      - jupp0r 5y ago
        CMake only finds the dependencies, how do they get to your computer? Do you link statically or dynamically? What compiler toolchains are these libraries built with, do they use the same standard library as your code or different ones? When you want to cross compile, how do you find libraries for your target architecture? Conan makes much of this easier, but is not really suited for large software projects with the problems mentioned above - in my experience.
brundolf 5y ago
> you also have your build code, oddly dictating the organization of your source code It... really doesn't? You generally have an entry point file - which can be any file, you just have to specify it to your build system - and import statements are followed from there on. If anything you could argue the JS build ecosystem is too flexible (which is one of the things esbuild is pushing back against). I've never heard someone criticize it for being too opinionated. > For extra fun, some libraries don't build with build system a, others require build system b I've literally never encountered this problem. Library authors virtually always ship least-common-denominator JS that will work without using a build system at all, and then build systems know how to handle lots of different variations of JS and converge them into a single representation. Compatibility is not an issue that exists in my experience. > The webdev ecosystem is so broken, it's no wonder so many websites deliver assets that are extremely suboptimally optimised, big unused blobs of assets /scripts slowing page load, optimising it all is actually made harder than coding it all. Now you're just airing your own personal beef which doesn't actually have anything to do with the original topic.
the_gipsy 5y ago
Then also make unit, integration, and e2e work with all the transpiling. Good luck with sourcemaps!
- Kaze404 5y ago
  You enable sourcemaps on Webpack with `devtool = "eval-source-map"` in your config, and I'm not sure how you expect transpiling to be a problem with testing considering your tests are also transpiled.
  - the_gipsy 5y ago
    Do you compile and run your unit tests with webpack?
    - Kaze404 5y ago
      In the case of code that needs to be transpiled, like Typescript, yes.
kall 5y ago
Have you seen the android build system? I mean what the hell is a gradle wrapper. At least js tools are configured in .json or .js files not in a special purpose programming language. I don‘t mean to discuss which system is too complicated and which is not just to point out a lot of real world build systems are on that level.
- netvl 5y ago
  Android apps are written in Kotlin, and Gradle config is also written in Kotlin. How come it is different from the JS situation? Even though Gradle can be configured in Groovy, and Android apps can be written in Java, it is still the same ecosystem - basically, the situation of TypeScript/PureScript/WhateverScript and JavaScript. Gradle wrapper is just a name for a script (automatically created by Gradle btw) which allows one not to have any kind of Gradle-related tooling installed on the machine (basically, to run build tasks you execute `./gradlew someTask`, and it takes care about downloading and running the appropriate Gradle version) - which I think is a clear benefit over the fact that you need to have `npm` installed system-wide or via a tool like NVM in order to build JS projects. Gradle has its own warts, and a lot of them, but at least there is only one major build system in this area, and it is simply impossible for a library published to a Maven repo to be dependent on the build system it is built with.
toddmorey 5y ago
I knew someone would bring this comment. Webdev can be broken, but doesn't have to be. I am currently having fun & feeling productive on both a large team project and some small personal projects.
- deleted 5y ago
  [deleted]
z3t4 5y ago
For personal projects I just use plain javaScript, ES5 even, without any compile steps, everything loads instantly and runs on every browser that supports JavaScript, and the development can be set up in any environment/OS without headaches. I do use minification for production but that is not really necessary if the browser supports loading JS-script tags async (all major browsers). The bundle gets very small without any frameworks attached. Debugging is easy with the browser built in dev-tools - with small error messages that always have the correct line (eg. no source maps). I'm currently working on a 100,000+ line JS project that uses the plugin pattern with script tags and it's very manageable, adding new features is fast and fun. There are of course trade-offs, I can't just "npm install react-x-y-z", but the browser API's are extensive, you can do just about anything on the front-end with just the native browser components and API's.
- IggleSniggle 5y ago
  I really love TypeScript. But I have always considered the end game of TypeScript to be that it’s inference engine (and third party libraries) become so good that you can just can write ECMAScript and get all the benefits of typescript. I wouldn’t give up all my structural type inference for the 1:1 you’re describing, but it is tempting.
qudat 5y ago
FE web developer is one of a kind and there are good reasons for that. I keep seeing the same responses pop up all the time so I decided to write my thoughts down on why FE web dev is a black swan in software development: https://erock.io/2021/03/27/my-love-letter-to-front-end-web-development.html https://erock.io/2021/03/27/my-love-letter-to-front-end-web-...
manigandham 5y ago
It's more the JS ecosystem than web, because of where it started and how it's evolved organically. It's rather surprising we got this far.

napsterbr 5y ago

> The webdev ecosystem is so broken Allow me to correct this statement: The Javascript ecosystem is so broken. Working with Clojurescript and Elm is an experience that will make most developers fall in love with web development again.

krapp 5y ago
Hate to break it to you but Clojurescript, Elm and the whole paradigm of "compile to JS" languages are part of what is broken about the javascript ecosystem. So much unnecessary complexity and energy wasted making javascript pretend to be something it isn't and to make it do things it was never meant to do, pressing a small, simple and powerful scripting language into the service of the profane eldritch abomination that is Enterprise Development.
- deergomoo 5y ago
  I dunno, I feel that’s like saying that Lisp and Haskell are part of what’s broken about the machine code ecosystem. ClojureScript and Elm aren’t compile-to-JS languages for the sake of doing something weird, there’s just literally nothing else that will run in a browser (except wasm but probably best not to get into that). Different programming languages exist for a multitude of valid reasons, the compiled output isn’t particularly important as long as it can express everything you need it to.
  - krapp 5y ago
    > I dunno, I feel that’s like saying that Lisp and Haskell are part of what’s broken about the machine code ecosystem. It would be if machine code were another high-level text-based language completely unrelated to either Lisp or Haskell with its own semantics, execution model and type system rather than a more directly machine-readable format of those languages themselves. Javascript is fundamentally different enough from a bytecode for any arbitrary language that, at least to me the distinction matters. I can accept that it works well enough that most people don't care, even though I suspect most of the use cases for doing so (error checking, type checking) could be better served with linters or editor tools for JS itself. But the decision to avoid actually writing javascript at all costs has contributed a great deal of complexity in the JS ecosystem, which translates into the bloat in the web that everyone complains about, because all of that javascript is wasting time and cycles simulating other languages.
    - zachrose 5y ago
      > But the decision to avoid actually writing javascript at all costs Who's JavaScript is it anyway? ES7? ES6? Internet Explorer 11's? How do you isolate things for the sake of unit tests and then bring them together into a performant build?
      - krapp 5y ago
        >Who's JavaScript is it anyway? ES7? ES6? Internet Explorer 11's? Cross-browser compatible Javascript was a solved problem when JQuery and shimming came along. >How do you isolate things for the sake of unit tests and then bring them together into a performant build? Use one of the many unit testing libraries and frameworks that already exist for Javascript.
- jupp0r 5y ago
  Hate to break it to you, but what you call "Enterprise Development" is really just "large software projects", for which many find the "simple and powerful scripting language" inadequate.
  - krapp 5y ago
    But those projects use that "simple and powerful scripting language" anyway, so clearly it is adequate.
    - jupp0r 5y ago
      Are you using JavaScript when you are using TypeScript? I guess so, to some degree. The additional tooling complexity is just not that significant compared to the gains of a language that compiles to JavaScript vs using vanilla JavaScript.
curun1r 5y ago
Also Trunk [0] for Rust-wasm web dev. It’s made me not hate doing the front end for my projects. I look forward to the Rust web ecosystem evolving to the point where I can recommend it in a work context. [0] https://trunkrs.dev/ https://trunkrs.dev/

jupp0r 5y ago

I see you have never worked on a C/C++ project.

uhhhhhhhhhhhhhh 5y ago
Yeah this appears to be more or less the essential complexity of build+link
- mssundaram 5y ago
  Looks like you may be shadow banned - I vouched for this comment and see all your recent previous comments are dead
Shorel 5y ago
I have done both. C++ is miles better in comparison.
- jupp0r 5y ago
  Maybe you can enlighten me how to easily add a dependency (the equivalent of "yarn add lodash") in a platform-independent way.
  - Shorel 5y ago
    I have used CMake. I added the dependency by writing about three CMake lines. And after that, it just works, for years. I may have to add from 2, to 5 dependencies for a project, instead of the myriad of dependencies in JS. And they don't become obsolete and need an update each week. It's a difference of some orders of magnitude, both in number and in upgrade frequency. This is a huge part of dependency management for me. And there are C++ package managers like Conan, which solve your requirement of adding a dependency by just using the command line. I will probably use Conan if I have to write C++ again.
    - jupp0r 5y ago
      CMake only finds the dependencies, how do they get to your computer? Do you link statically or dynamically? What compiler toolchains are these libraries built with, do they use the same standard library as your code or different ones? When you want to cross compile, how do you find libraries for your target architecture? Conan makes much of this easier, but is not really suited for large software projects with the problems mentioned above - in my experience.

brundolf 5y ago

> you also have your build code, oddly dictating the organization of your source code It... really doesn't? You generally have an entry point file - which can be any file, you just have to specify it to your build system - and import statements are followed from there on. If anything you could argue the JS build ecosystem is too flexible (which is one of the things esbuild is pushing back against). I've never heard someone criticize it for being too opinionated. > For extra fun, some libraries don't build with build system a, others require build system b I've literally never encountered this problem. Library authors virtually always ship least-common-denominator JS that will work without using a build system at all, and then build systems know how to handle lots of different variations of JS and converge them into a single representation. Compatibility is not an issue that exists in my experience. > The webdev ecosystem is so broken, it's no wonder so many websites deliver assets that are extremely suboptimally optimised, big unused blobs of assets /scripts slowing page load, optimising it all is actually made harder than coding it all. Now you're just airing your own personal beef which doesn't actually have anything to do with the original topic.

the_gipsy 5y ago

Then also make unit, integration, and e2e work with all the transpiling. Good luck with sourcemaps!

Kaze404 5y ago
You enable sourcemaps on Webpack with `devtool = "eval-source-map"` in your config, and I'm not sure how you expect transpiling to be a problem with testing considering your tests are also transpiled.
- the_gipsy 5y ago
  Do you compile and run your unit tests with webpack?
  - Kaze404 5y ago
    In the case of code that needs to be transpiled, like Typescript, yes.

kall 5y ago

Have you seen the android build system? I mean what the hell is a gradle wrapper. At least js tools are configured in .json or .js files not in a special purpose programming language. I don‘t mean to discuss which system is too complicated and which is not just to point out a lot of real world build systems are on that level.

netvl 5y ago
Android apps are written in Kotlin, and Gradle config is also written in Kotlin. How come it is different from the JS situation? Even though Gradle can be configured in Groovy, and Android apps can be written in Java, it is still the same ecosystem - basically, the situation of TypeScript/PureScript/WhateverScript and JavaScript. Gradle wrapper is just a name for a script (automatically created by Gradle btw) which allows one not to have any kind of Gradle-related tooling installed on the machine (basically, to run build tasks you execute `./gradlew someTask`, and it takes care about downloading and running the appropriate Gradle version) - which I think is a clear benefit over the fact that you need to have `npm` installed system-wide or via a tool like NVM in order to build JS projects. Gradle has its own warts, and a lot of them, but at least there is only one major build system in this area, and it is simply impossible for a library published to a Maven repo to be dependent on the build system it is built with.

toddmorey 5y ago

I knew someone would bring this comment. Webdev can be broken, but doesn't have to be. I am currently having fun & feeling productive on both a large team project and some small personal projects.

deleted 5y ago
[deleted]

z3t4 5y ago

For personal projects I just use plain javaScript, ES5 even, without any compile steps, everything loads instantly and runs on every browser that supports JavaScript, and the development can be set up in any environment/OS without headaches. I do use minification for production but that is not really necessary if the browser supports loading JS-script tags async (all major browsers). The bundle gets very small without any frameworks attached. Debugging is easy with the browser built in dev-tools - with small error messages that always have the correct line (eg. no source maps). I'm currently working on a 100,000+ line JS project that uses the plugin pattern with script tags and it's very manageable, adding new features is fast and fun. There are of course trade-offs, I can't just "npm install react-x-y-z", but the browser API's are extensive, you can do just about anything on the front-end with just the native browser components and API's.

IggleSniggle 5y ago
I really love TypeScript. But I have always considered the end game of TypeScript to be that it’s inference engine (and third party libraries) become so good that you can just can write ECMAScript and get all the benefits of typescript. I wouldn’t give up all my structural type inference for the 1:1 you’re describing, but it is tempting.

qudat 5y ago

FE web developer is one of a kind and there are good reasons for that. I keep seeing the same responses pop up all the time so I decided to write my thoughts down on why FE web dev is a black swan in software development: https://erock.io/2021/03/27/my-love-letter-to-front-end-web-development.html https://erock.io/2021/03/27/my-love-letter-to-front-end-web-...

manigandham 5y ago

It's more the JS ecosystem than web, because of where it started and how it's evolved organically. It's rather surprising we got this far.