Comment by inopinatus | Hacker News Reader

Comment by inopinatus | Hacker News Reader

Parent Full thread

If you’ve mainly worked in TS then it explains the blind spot, because JavaScript is chock full of awful missteps built up over the years. There’s a reason my copy of “JavaScript: The Good Parts” is extremely slim next to its sibling, “JavaScript: The Definitive Guide”.

So you’ve come to it at a time when the syntax and capabilities have a popular subset that actually starts to fulfil the early promise. And yet, despite the article above, one may still be enormously critical of the anemic and inconsistent standard library, and don’t even get me started on the horrifying dependency shitshow of the node ecosystem that cripples maintainability of anything over 18 months old.

Just because we’re all holed up in the throne room, doesn’t mean there aren’t monsters still roaming the sewers, just a few levels down.

As for isomorphic code, I strongly encourage my competitors to write backend code in the same fashion and the same breath as the front-end, because the resulting tight coupling and special-case-driven technical debt makes them easy to outmanoeuvre when markets shift. And if they’re reading this then please also consider microservices, graphql, and nosql data stores whilst you’re at it, for the same great reasons.

> There’s a reason my copy of “JavaScript: The Good Parts” is extremely slim next to its sibling, “JavaScript: The Definitive Guide”.

The reason is that these two books don't fulfill the same goal. The Good Parts is a rather short walk through the language and reads more like a "get started quickly" guide. The other goes into much more detail. That doesn't mean the latter's size os due to it covering all the bad stuff whereas the former doesn't. It's just a clever title but it's an apples and oranges comparison and I'd suggest not using it as some sort of supporting argument.

Whether JavaScript is good or bad as a whole is a different question (I think it is), I'm simply taking issue with that meme (that originally popped up in picture form, the two books side by side, rather than text).

I have also stopped trying to discourage people from cargo culting facebook’s stack for their 3-person teams or even solo. If someone insists on 10x the complexity and 100x the work, let them.

JavaScript is becoming bearable but still too painful for anyone who has touched ruby for example.

Meanwhile I’m learning closure and loving every second of it.

Haha ruby of all things. The language where they create aliases in standard library to make the code "read like natural language"... With a framework that promotes mixins as a service layer/code sharing abstraction and fat models/controllers.

I get not wanting to start with a super complex stack, but Ruby and Rails are the worst mainstream framework maintainability wise it's obvious why it fell out of favour.

I've heard someone describe Ruby On Rails as: "lots of great magical wands that make great palaces appear out of thin air but always ends up spawning dragons you have to fight"

I will pipe up for client-side TypeScript in conjunction with Ruby-based services. I’ve been contributing PRs for Hotwire and it is the first time in 25 years I didn’t actively resent working in JS of any dialect.

Thank you for your contributions. I am super excited about Hotwire - and spending less time doing more.

I find the Facebook stack to have a lot of boilerplate, but overall it's very simple rather than complex.

You always know exactly how to implement what you want, without having to think very hard.

You can do something small by yourself by writing less code, but using less code makes it more complex since you have to think a lot harder to understand the code when you come back to it in a few years

Reminds me of this talk https://youtu.be/gfh-VCTwMw8

> There’s a reason my copy of “JavaScript: The Good Parts” is extremely slim next to its sibling, “JavaScript: The Definitive Guide”.

Because one's a style guide and one's a complete API reference?

Even as a style guide, it's unnecessarily terse in some cases. IIRC, there's a line that says (paraphrasing):

> Don't use continue. I've never seen a loop with a continue that wouldn't be better without it.

And that's it. No examples, no objective criteria, we're just supposed to take the man at his word on this. Whether or not I agree with this particular case, I don't enjoy argument from authority in most forms, especially not in one where you are supposed to learn about a better style of programming.

Reply on news.ycombinator.com