Comment by iSnow | Hacker News Reader

Comment by iSnow | Hacker News Reader

Parent Full thread

There's a bit of hyperbole in the article, but it strikes a nerve.

I originally came from Java and was so fed up with the hulking class lib and the arcane build systems sprinkled with Ant snippets and XML galore, so JS felt like a fresh breeze.

AngularJS was a bit convoluted and the syntax was not nice. But OK, data binding was nice. Bit like dependency injection on the Java side made the code much harder to reason about but helped build certain classes of applications.

Angular 4 was just WTF. Somewhat cleaner module system but now with a clunky OOP language instead of the elegant functional expressions that JS had and Java finally adopted. For which reason exactly?

And I tried Vue which is a much lighter framework but like Angular, the build system is just retarded. Instead of many dozens of JARs with dozens of sub-dependencies, modern JS goes for the kill and literally imports several hundred of npm package with thousands of dependencies.

And in the end, I end up having to use "browserify" to have JS running in a browser. It's a clowns world in IT, but modern JS really takes the cake. I'm back in backend, solving real problems instead of wrangling my build chain.

If you like functional JS then you should be using React. This is exactly why it's still the most popular JS framework. If you want a simpler build system then you should try esbuild. It's a single Go binary.

You can use Vue.js 2 without build system by just loading into the browser.

Can confirm. I built 2 VueJS apps that are 100% static, and it was not a problem at all.

A 100% static site doesn’t run any JS, right? What did you need Vue for, then?

A static site may use JS, but doesn't require server-side logic (PHP, databases, or any other type of dynamic content). In this case OP implies that it doesn't even require a build (because you may create a static site through a build process -like Jekyll does, for example-).

Static from the server perspective. It only serves files in a directory without any parsing or processing.

You can still do this with Vue 3! The CodePen embeds they use in their "Getting Started" docs are all still just loading in an external library and making use of it with vanilla JS.

https://codepen.io/team/Vue/pen/KKpRVvJ

Sure you can, but then the moment you want to use an external library with it, it's basically a coin flip whether they ship it in the correct format for that. If they don't, you have to import it - but you can only import from modules. So you modify your page to load your code as a module instead, but now you can't access the global state. So you refractor everything and realize, that your page takes a minute to load because each of those modules contains like a 100 dependencies and half of them overlap.

TL;DR: it's there, but it's really only usable in like 5% of scenarios

I don't understand why so many devs seem to want to use Functional programming.

It's the exact same thing to me as what this article is complaining about. Everyone jumping on the latest and greatest bandwagon.

Angular is easy, and OOP is very easy to work with for business needs.

OOP is very easy to misuse where it hurts the most - on architectural level. It's very possible to write bad, unreadable FP code, but worst case isn't as bad or far reaching as with OOP.

I suppose so, I've seen that myself. I always take the time to design anything I do thoroughly though so it's all clear and concise.

Also the only time I used FP it was a seemingly awful implementation.

Perhaps I'll mess around with F# or something some time to see how I feel about it more.

In the case of React, I find functional programming excellent when it comes to mapping views from state. For state management, functional programming just seems like a massive time sink and a convoluted way of achieving the same things that OOP just gives you.

> For state management, functional programming just seems like a massive time sink and a convoluted way of achieving the same things that OOP just gives you.

Huh? function(state(A)) = state(B), always.

Right, I don't know much about React myself, but that must be why Redux was created right?

On the bright side, with native web components and web assembly gaining traction things may be looking up in the future, as a lot of these ideas get rolled into the browser natively.

yeah, web components gaining tractions since 2011...

lol. web components are a waste of time unless someone wants to write a widget with ShadowDOM. Its clear. Svelte has won and is the last thing web can give us. Lets all go home

What's wrong with the regular DOM?

Shadow DOM having better performance is a myth.

Google it.

There is no „wrangling the build-chain“ if you use the available clis all frameworks come with in advance.

Well since there's a plural in "CLIs", that goes into the "wrangling" category for me. If the dev/dep process involves more than one bespoke tool (looking at you js/Node monstrosities) and learning the arcana of their interactions, I'm out.

Well, I guess you‘re out of programming as a whole then, no? Most languages and dev process involve a lot of configuration or „bespoke tools“ and learning the arcane of their interactions.

Java? Gradle. JUnit. Maven. JavaDoc. etc.

C/CPP? Make. CMake. Various dependency management tools. Maybe your OS native dependency manager

Your OS? Brew / Yay / pacman / app-get / vim config / IDE configuration / environment tools / ...

Deployment? Docker. Jenkins. Travis. Kubernetes.

Coming back to „js monstrosities“, if you ever had the fun to poke around in the literal arcane magicks that are C++ dependency management systems and giant CMAKE files, you‘d love node. In fact, most cli tools are just for templating projects or generating boilerplate for components. They aren‘t arcane or complicated at all.

Configuration is half of programming or dev ops. If you don‘t like it, maybe it just isn‘t for you.

I understand what you mean but disagree. I merely appreciate tools that make some effort to standardise their UX. Of course configuration is going to be a major part of the system; however that doesn't mean I must use fragmented tools to manage them.

For instance, I avoid touching those Java tools you mention (or Javascript), preferring leiningen et al. from the Clojure ecosystem. If I don't want to deal with CMAKE or whatever the hell php or perl or erlang or go use, I can use my distro's package manager (coincidentally, yay) to abstract them away. If something goes wrong (which rarely happens these days!) it's even money that the problem comes from some Node/JS intermediate abomination which doesn't even show you the curtesy of being tractable in its scope or mode of operation.

And your last line is uncalled for. I'm happy you like the current state of affairs, but my very subjective view is that I'm not affected by the JS-land Stockholm syndrome. Doesn't mean I don't enjoy dealing with the domain problems :)

It's like you've never seen a webpack "config file"...

I have. Compared to what most back-end languages have to offer (CMake and the like), it‘s a joy to use, pretty straightforward and well documented.

C/C++ != "most backend languages". Python, Ruby, Go and, Rust are much more commonly used on the backend and none of them have build systems as ugly as C nor as over-engineered and messy as JS.

> Python, Ruby, Go and, Rust are much more commonly used on the backend

Uhhh. They are popular nowadays, but the sheer volume of old CRUD backends in Java or C++ still outweighs these systems. If not, they are at least equal I'd wager.

However, they may be overengineered or not. We don't know, because they had enough time to mature and decide on industry standards. In fact, the newer JS buildsystems are, the less surface level APIs they expose. Take the newer CRA versions for example. Like cargo or pip, most of the complicated things are abstracted away.

I also don't think they are over engineered. When building software for browsers, you need to adress many different things at once. Most build systems compile some form of templating, CSS syntax and JavaScript flavours. They need to target different browsers and their versions for example. Furthermore, you can't build JS and output it into an universally understood binary format. You have to care for different browsers, their level of ECMAScript they support, if or if not they support specific CSS syntax, bundle size, how images are imported, how SVSs are imported, more assets management and so on. For most backend things, you just pack things into one huge binary and its fine.

I'm not saying modern JS bundlers and build systems are the best we can do. I'm just saying what's there works for the majority, and we're getting there eventually.

Do people not re-use previous configs as a starting point for new projects?

Webpack is difficult to figure out at first, but if you have an existing config it should be a lot easier.

It's not always that easy. Most of the pain around webpack configs comes from dealing with them later, not when starting the project. It might've been written by someone before you and modified by multiple people. Now you have to figure out how to add something new, intended for a different pipeline, into your existing pipeline, which has years of changes you probably don't understand in it.

Reply on news.ycombinator.com