Hacker News Reader

Comment by MintsJohn | Hacker News Reader

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.

View on HN

> 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.

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.

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.

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.

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.

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

Yeah this appears to be more or less the essential complexity of build+link

Looks like you may be shadow banned - I vouched for this comment and see all your recent previous comments are dead

I have done both. C++ is miles better in comparison.

Maybe you can enlighten me how to easily add a dependency (the equivalent of "yarn add lodash") in a platform-independent way.

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.

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.

Well, I don't cross compile. If I need to test a new OS, then I get the VM and compile it there.

About dependencies, if they can be found in the package manager then it goes that way. Else, they are a git submodule.

The most problematic has indeed been the C++ MySQL connector, because it has changed a bit over the last five years, so I had to edit the #include lines in the source code files.

Chrome for example does not currently compile on darwin-arm64, cross compiling from darwin-x64 is the only way to build that target.

When you are using git submodules as package manager, what do you do if the dependency doesn’t come with CMake files, but with autotools for example?

I think bazel is becoming a great solution for these problems if you align with their philosophy.

> 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.

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.

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.

> 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.

> 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?

>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.

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.

But those projects use that "simple and powerful scripting language" anyway, so clearly it is adequate.

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.

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/

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

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.

Do you compile and run your unit tests with webpack?

In the case of code that needs to be transpiled, like Typescript, yes.

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-...

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.

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.

Reply on news.ycombinator.com