Shacklz

> Stick to a few git commands

This was my approach for my first few years of git. I always tried to approach git via its commands, and I horribly failed - until I finally took a little bit of effort to understand how git actually works under the hood, which really made it click for me.

For anyone who has ever spent a modicum of time (e.g. while getting a CS degree) trying to understand datastructures, it's probably really straight-forward to "get git". The datastructure underneath is really quite simple. A branch is a pointer to a commit, a commit is a pointer to a tree, a tree is a list of pointers to other trees and files. That's already pretty much all there is to it.

Once the datastructure of git is understood, the commands start to "make sense" on their own - at least most of them. They still have tons of obscure options that one doesn't realistically need in a daily work flow, but the general idea what the commands do (and how to recover from screwups) was, at least for me, pretty simple after understanding the datastructure.

As someone who doesn't really often look at these sort of charts... traffic coming via chatGPT being higher than Bing was quite the surprise to me. Makes of course total sense, but still astonishing to see the actual numbers in comparison.

I wish there wasn't a need for a business-model to begin with for social media. Honestly, being business-driven is what turns them all to shit, as far as I'm concerned.

That being said, the lights need to be kept on somehow... some model similar to what Signal or wikipedia does might be a solution. Content-moderation is probably the big challenge though that they do not have to deal with to the same extent, so not quite sure how that could fly either...

As enthusiastic as I am about node's typescript-support, calling it "just works" is a bit of a stretch. Not entirely sure if it's still the case anymore on the latest versions but last I checked it was required to use `.ts`-suffixes for all the imports, something a standard typescript project will hardly ever have and needs to be specifically configured to be considered valid syntax (allowImportingTsExtensions:true).

But yeah, there's progress, and once this gets solid traction (which I'm sure it will) it might finally be the last drop in the bucket to convince TC39 to stop being so antagonistic to having some notion of type-support directly in Javascript.

Funny, I have exactly the opposite feelings.

I've worked on dynamically typed code-bases in the past, and also on code-bases without formatters like prettier... and I'm not going back there.

So many odd bugs can be avoided simply by taking a little bit of time and declaring some types. It doesn't have to be a super fancy type-system (I actually prefer if it isn't), but I really want to know whether something is expected to be a string or a number, or what properties an object can be expected to have, or what values a literal can accept, and so on. It's just so frustratingly time-consuming to figure out in hindsight. And all for some person's odd perception of simplicity.

Same for formatters - all the squabbling over some personal preferences on how code should be formatted. Hell no. Let's install some opinionated formatter and let it do its job, I want to tackle more interesting problems than yet another narrow-minded discussion about necessity of semicolons, placement of whitespace or line-length.

I'm at a point where I straight-up refuse to work with people who prefer to work that way; or at least require them to be a few departments away from me. They can be programming gods; if they can't be arsed to type their code so I can immediately grok it, they can program elsewhere.

What exactly are you referring to? Specifically typescript has zero dependencies.

Generally speaking, I agree, the npm-ecosystem still has this pervasive problem that pulling one package can result in many transitive dependencies, but a growing amount of well-known packages try to keep it as limited as possible. Looking at the transitive dependency graph is definitely good (necessary) hygiene when picking dependencies, and when done rigorously enough, there shouldn't be too many bad surprises, at least in my personal experience.

Great work, many thanks!

Out of curiosity, what do you see as next steps, and what possible futures do you see for typescript in the node- and overall JS-ecosystem?

> Why is taking out the part that actually checks the types at the developer's side a huge blessing?

Oh, no, certainly we want to keep type-checking in the pipeline, somewhere.

However, if the browser "understood" typescript, your codebase could have immediate hot-reload, without any transpilation in-between. The type-checking could then be (and already is when using something like esbuild/swc) an entirely separate process that happens independently.

Webpack's HMR is pretty good, but not having to modify the code at all to have it work in the browser, that'd be much much better :)

... the browser being able to typecheck (and reject violating code) itself is certainly something I'd love to see eventually, but fully agreed, this is not happening anytime soon.

Taking one link out of the toolchain (tsc) would already be a huge blessing.

And naive me hopes for a future where in my web-app I can set a policy that any non-ts, type-incompliant code is not allowed to run.

The amount of exceptions I get in the console from terrible garbage-code outside of my control but that I have to include because enterprise is staggering. Would love to have a meta-setting which would just kill them if they can't be arsed to even have a modicum of code-hygiene (sorry for the rant)

In our codebase we started to disallow enums in favour of string literal types, and once folks get over the ingrained "this needs to be an enum" (coming mostly from other languages like Java), it's not much missed.

Enums are one of the very few things in typescript that seem to not have turned out that well, but it's relatively easy to work without them with string-literable types and such, derived from some const in case they're also needed at runtime.

I'm honestly giddy. This could be the (slow) beginning of a new era, where "JS with types" is finally a native thing.

I'm even willing to forgive all the mess that CJS vs. ESM is if they manage to pull this off.

I hope this sees widespread adoption/usage, which might finally cause some movement to integrate TS into ecmascript after all. Some dynamically-typed language fanatics (which are, in my opinion, completely detached from the reality that static types are what the vast majority of devs want) still have an iron grip on TC39, this might be the start of their end. And good riddance.

If I understood correctly they use a wrapper around swc to strip types, without any type-check being performed.

Which makes perfect sense to start out with; as typechecking with tsc is rather slow and can easily be delegated to the consumer.

> All of that is something that I consider to be platform-level

I agree with this, but the whole point of the blog-post is that the "platform" currently handles this rather poorly.

I have yet to see a frontend-project that was bigger than some three-person-garage-hobby that didn't occasionally run into CJS versus ESM issues. Maybe not something that pops up on the radar of all the devs in the project but at least at the level of folks who take care of the setup and whatnot, it often pops up in rather painful fashion. Case in point; a few angular-versions back, umd-bundles were dropped, which at least for the project I worked on caused me quite a lot of headache as some of our tool-chain (most notably our testing-setup) relied on angular shipping commonJS-compatible modules.

It's currently also a major pain for anyone publishing an npm-package, even if it's primarily intended to be run on node. The kind of incantations one has to do are just insane (especially if you dared to import from node:crypto or want to support more than just the latest lts); I've just stopped bothering after tearing my hair out for a weekend to no avail, even though I really wanted to support ESM as well.

> OSX sucks with 3 monitors and switches the output randomly when coming back from sleep/rebooting

This drives me nuts with my Mac at my workplace. It's mostly an awesome workhorse, but when I switched to Mac I was flabbergasted that this can be an issue.

The window-management I find also rather awful. When I asked the Mac-nerds I knew they all had their custom setup that includes some third-party-tooling, the built-in mission-control or whatever they call it didn't exactly receive favorable remarks...

Maybe this is disabled for free customers but at least for me there are settings to enable/disables what I kind of informations I'd like to receive from them.

Gmail in that regard I've always perceived as worse - every few months or so they update their policy, linking to some gargantuan document that I can't be bothered to read, each time wondering how much of my soul I've sold this time around...

There are some serious anti-proton-vibes in this thread, so just my 2 cents as a paying customer: I'm rather happy with their service. I pay them money, they make sure that Joe in Marketing won't be able to harvest data from my emails. I'm also fairly optimistic that they take security serious enough that the blast radius of some dataleak is hopefully very limited.

I have zero delusions however that they can protect me from state agents, let alone state agents with malicious intent. And I don't think it's realistic to expect that for the amount of money they cost. But that's fine with me - it's Joe from Marketing I'm scared about, and so far they seem to do a good job keeping Joe at bay :)

If there's a small team, individual freedom can be perfectly fine, as everybody knows everyone and it's easy to talk with each other in case there are discrepancies.

For larger projects however, not having tooling set up that enforces certain consistency is an absolute showstopper for me. I'll either introduce it or I'll quit; I simply do not want to waste my time with developers squabbling over arbitrary formatting-choices or irrelevant coding-style-details that can easily be enforced by some tooling.

Of course, developer-experience is paramount. Meaning, the tooling must be easy-to-use and generally not stand in the way. Otherwise it can indeed create a lot of friction which will annoy everybody. But once this has been set up (properly!), it will make a lot of silly discussions and choices obsolete.

It's not a bot but formatters like prettier for example make it very easy to set them up as git-hooks, where the formatter is applied on commit. Meaning, unless you specifically commit without hooks, all committed code should comply with the formatter.

For linting (e.g. eslint in the JS-space), this is also possible, however, most linting-processes tend to run just long enough to be annoying when run on every commit. In the monorepo I work on we created a command "prep-pr" which specifically addresses this issue - run it before creating a PR, and the CI-pipeline will mostly be green, at least in terms of linting/unit-testing.

There have already been a lot of points by other commenters, one point that I'd like to add:

It allows to solve "problems of scale" with technical solutions rather than process solutions.

For example: Let's say there's application app-A and app-B, and they decide they want a library lib-1 that they can share.

If they are in separate repositories, this means multiple pull-requests, it means separate pipelines where the pipeline of lib-1 likely won't include the tests of the applications, it means there will be pull-requests to the library which won't immediately be integrated into the applications so that some poor sod has to take care of breaking changes down the road, etc.

If they are in a monorepo, each application can set up tests that need to be fine with the library-code "as is", so any change to the library needs to work against existing application-tests. The price one pays however are pipelines that perform well - nobody wants to wait hours to get pipeline-feedback and such. A monorepo also allows ambitious folks to shine - it's easy to touch many things at once, or to touch things used by everyone, on a pull-request with high visibility, which is an easy platform to get "street creds" as an ambitious engineer.

> “Populist anger” might be justified if people have a hard time paying their bills.

If the costs of current living standard wasn't externalized to future generations (to the detriment of the environment), they couldn't afford those bills to begin with.

Unfortunately, it's very hard to reduce people's living standards once they got used to it. So yes, the end result is what you're saying - however, I think it's a very important nuance. It was always a card house; we just chose to ignore the issue and continued to build on top of it.

> But its design is far, very far from the most important software design principle (KISS)

My suggestion was more to look at the underlying data-model, which really isn't that much harder to grasp than what your average undergrad datastructure course teaches. Git really does solve a rather complex problem in a quite elegant way - it just so happens that the packaging around it (the cli) is indeed a bit more controversial.

I can only speak for myself but once I started to look at git less like "a tool" and rather from a perspective of datastructure/algorithms etc. (which are inherently agnostic to how they're implemented), it started to make sense to me rather quick (a matter of hours actually, which is nothing compared to the countless of hours I've already wasted trying to find the right cheat-sheet-incantation before).

I had the same experience for a long time and then I took a bit of time to have a deeper look behind the curtain and I have to say, once you grasp the data-model of git itself (a branch is a pointer to a commit, a commit is a pointer with metadata to a tree, a tree is...), many of the commands start to make sense all of a sudden, or at the very least "stop looking dangerous".

As it's one of those rare tools that's probably meant to stay for quite some time and we interact with quite frequently, it was time well spent for me, and it turns out it's really not as hard as the scary-looking commands imply.

I understand your sentiment but git is really not all that hard. And knowing a few things that go beyond bog-standard checkout/commit/push, especially history-rewriting activities, will greatly improve quality of commit-history - which might not be of much use for you but might help other engineers working on your project to make easier sense of what's going on.

And on another note, git is probably one of the longer-lasting constants in our industry. Technologies develop and change all the time, but for git, it looks like it's here to stay for a while, and it's probably one of the tools we interact with most in day-to-day dev-work. Might be worth having a bit of a look at :)

> Most European citizens do not know the name of the EU president.

Probably a bit controversial but to some degree, that is a good thing. It prevents personality cult and allows to pursue agendas that think in longer terms.

In Switzerland, quite a big part of the population could probably not name the current seven members of the federal council - they can actually get work done, without having to appease the public at every corner.

There's a difference between 'having more capital' and 'having absolutely absurd amounts of capitals'.

If you look at income distribution graphs of the last few decades and the political influence those in the highest percentiles wielded, it's not entirely unfair to question whether this might make the life of the average citizen "worse".

> but I find the tyranny of "it works for me so you're doing it wrong" very real

One could also talk about the tyranny of people living their freedom of personal choice to the maximum.

"My solution works for me but will never scale to work for the entire humanity as we're simply too many on this planet for that and also totally screws the environment for future generations, but hey, it works for me!"

> right to a personal life unscrutinized by an overreaching state.

If it was just the state, then I might even be able to live with it, as my trust in my government is rather high, even if I do agree with your second paragraph on principle.

The problem though is that lax/non-existent privacy laws also allow Joe in marketing and his friends to do all kinds of creepy privacy-invading things, which I worry about much more. It fosters a mentality and culture around how to get the easiest to those who are most susceptible to whatever it is your peddling, and in today's day and age of social media I think it's fair to say that it's increasingly clear that that kind of culture isn't exactly a net favor for humanity as a whole.

It's probably naive from me but I'm honestly much more worried about big tech and their nonchalant approach to privacy than I am about dangers of my government going full surveillance state. The two issues are of course not entirely separate either, they're very much intertwined.

I always find it fascinating that we don't "anti-celebrate" such obvious failures in history more. I remember reading the original article of the author (linked in another comment in here) in German and I haven't ever heard of Bircher before.

Peddling nonsense against better knowledge that causes this amount of suffering deserves ridicule in posterity. We shouldn't just celebrate those who do great things for humanity, but also "anti-celebrate" those who do great harm.

Couldn't agree more. Love the frontend-space, love the ecosystem, but hate the whole ESM vs. CJS fiasco with a passion.

To some degree, I think the typescript-team itself also has to take some blame here. I understand their point that they do not want to do any rewrites, and to some degree it makes sense, but if the ecosystem as a whole really wants to move forward to a common understanding of how it should work, someone needs to do the heavy lifting for dev-experience, and right now they're best-equipped to actually solve the problem, or at the very least help us a lot in doing so.

Their dogmatic approach makes sense for the scope they set out with when starting with typescript but in my eyes refuses a bit the reality the ecosystem currently finds itself in. And I'm saying this as an absolute ts-fanboy; it's one of the very few things about typescript that I take an issue with.

> a naive fantasy.

Is it so naive to believe that eventually, we as humans can eventually overcome our stone age instincts and stop slaughtering each other on a big enough scale to necessitate some amount of militarism?

I for one would be greatly disappointed if we could not achieve that eventually. In today's age, I agree that it's hardly possible, there are simply too many parts of the world without sufficient education or still in the grip of authoritarianism or religious fanatics, but once we've overcome that, it should surely be possible eventually?

... eh, maybe I'm just naive. But as MLK so nicely put it, the arc of the moral universe is long, but it bends towards justice, and I'd really like to believe that.