pmichalina

People using it would beg to differ. Just don’t use their service.

Even just one poorly designed library can cause serious memory issues and trigger a ton of events. Usually it’s the marketing and ad people that throw around this “but they are async loaded”. That’s true, but doesn’t change the the fact that 40 trackers and their dependencies that come with it are slowing down and infringing on the users privacy. Let’s be real.

Tests are good of course, but that assumes the tests are valid. I’d rather trust compiler to ensure runtime safety.

Throwing is a side effect breaking flow of control for no good reason. It’s takes you down the same path as all other spaghetti code.

Not as much elegance as it is about purity. Minimizing side effects is the number one way to reduce bugs.

It should be the number one guiding principle when creating out reliable software. Which means, you simply cannot use the primitive try catch or similar construct. Don’t break flow of control. Guide it to a terminal value instead.

These days, when I see try-catch and if-else constructs (which is in most codebases) it’s clear there will be bugs over the life of the application.

It’s fine, use them, but there is a world of greatness when you ditch these faulty constructs. Just like ditching OOP constructs. All built on false premises.

Assertions, throws, and try-catch are code smells. Really bad design choice considering we have more elegant solutions like monads.

Isn’t this how the web was supposed to work?

“Treating something like a disease” encourages one to not take ownership of the issue but instead provides a mechanism to play victim and give up. It’s victim mentality, denies the concept of freewill, and sets the stage for all sorts of slippery arguments.

I suppose it’s collapsing up since 2009?

Why not both?

Typical statist mindset.

lodash and moment are poor choices to showcase. lodash is mostly moot with ES6 and beyond. date-fns is a cleaner version of moment.