eleclady

Personal preference is valid only to an extent. At a certain point, with enough scale/team size/complexity TypeScript becomes invaluable. I've worked on projects that would have been intractable without TypeScript.

This is a huge problem with front-end. Too many people who don't know what they don't know, and think their use case is the only one.

Unsure if mentioned already, but I keep a repository of all my Linux configuration files. I have scripts that link them all out to the correct places. Then for almost any tweak I make, I script it into a massive install.sh script I maintain. Now I'm at a point where I can set up a 98% perfectly customized machine with a sequence of `./install.sh some_scripted_setting` calls. All this takes effort and care, but well worth it to me. And since it's all my scripting, I know exactly what's going on.

It's quite tough to do that for Windows (which I partially do). Ultimately I keep a list of the stuff I need to do and manually do a lot of it.

An alternative which I have dabbled with is basing your config in VMs. Keep stable backups of them. That way the host OS is not important, and just re-use the VMs if you switch hosts. QubesOS is what really opened my eyes to this. Of course this is really only useful for particular workflows probably more development oriented, and at some point you'll want to update them/start fresh.

Except the elite won't suffer.

I found Stripe usage quite complicated. It felt like they were handling very complex use cases at the expense of simpler ones (which are probably the majority).

It's one of those things where once you're already "in the know", the simple use cases are in fact simple to implement. But sifting through the massive and complex API set, with outdated and partial documentation/examples all over the internet, it's very difficult to get into. Every single example starts with "this is not production ready..." And the official docs are difficult to piece together into an "E2E best practices" setup.

Not saying there is a better solution, just that as a competent dev with a simple use case, I found Stripe overly complex.

There are so many smaller open source projects I would love to donate to but don't accept donations. I would even pay subscription to them if it ensures their continued development.

Agree with you fully. People take these blanket generalizations and make them rules and then use them to ignorantly judge someone's decisions. I've worked on projects where performance needed to be addressed up front or else it just wasn't viable.

On the flip side, after using CSS in large projects for years with many, many third party libraries, I've never once felt this urge... Rarely had any problems. At least none that the effort of styling everything in JS would merit!

He forges art, nets 100m+ euros, goes to prison for 3 years. I spend 40 years at a job I'd rather not be at, lucky to retire with 1m+ euros. Leaves a sour taste.

Yes, that's what I'm saying. The difficulty people have is that the thought process (solution) is still procedural but the query is expressed declaratively. Once you learn how to navigate that gap you get good at SQL.

Not trying to play word games, but what is the difference between answering a question and processing data? Aren't they effectively the same?

Using another tool for processing data often results in recreating SQL mechanics at application level. E.g. select this data, retrieve it, loop and if this, then set that, etc. SQL does it way better, guaranteed.

Of course that's often required for technical reasons (scalability etc.) or processing that's too complex to implement at data layer, or just for cleaner design.

But SQL is amazing at processing data!

I used to think this too, and wondered what magical SQL perspective my brain was missing. I'd see these elegant but seemingly impenetrable queries and wonder why my brain wasn't in the "SQL dimension" yet.

But over time, and very heavy SQL reporting, I realized the procedural mindset still applies, it's just not expressed as such.

You need to think through the steps of how you want to retrieve, transform, aggregate etc. the data and build up the query to accomplish those steps. The resulting query doesn't look procedural, but the thought process was. Of course you need to know the sometimes opaque constructs/tricks/syntax to express the steps, which again, look like magic at face value or just reading docs.

I think this is why people struggle with understanding SQL. The thought process is still procedural, but the query isn't. You need to translate the query back into procedural terms for your own understanding, which is a PITA.

Bootstrap sets a solid foundation for enterprise projects, where there are often many disparate projects, many developers, many deadlines, more concern with function vs. style/brand.

"because that is what they know and don’t bother picking up the new standards"

That's just an unnecessary comment and plain wrong.

> I've actually never seen a proper codebase in Typescript.

That's the problem then. I have, and have clearly seen in the real world why it's superior. ES6/Coffeescript can obviously be done correctly, but chaos tends to ensue as the flexibility is abused. Over time it makes debugging/understanding difficult. TypeScript makes changing/navigating large codebases a breeze. In other words, it's much easier to do correctly than ES6/Coffeescript.