Is that really the case? Because you can still see all the songs and a basic set of chords without an account/payment.
Is that really the case? Because you can still see all the songs and a basic set of chords without an account/payment.
Ultimate Guitar Tabs. After spending years getting a community to contribute to one of the best music resources on the web, they turn around and lock all but the most basic features behind a pay wall.
I interpreted this as a criticism of the sort of people who make posts for the ‘brain crack’ of maybe learning to code one day in place of putting the actual work in to learn.
Typically when creating API interfaces you’d be better off marking the inputs as unknown, and then using something like Zod to validate the types
I love how Gemini is so sorry that it can’t help you kill children
Haha well that’s fair enough then!
I think that’s fine if that’s how you like to work on your own, but I’d challenge anyone to do that and write better documentation while also getting a team or whole business to do the same. A huge strength of TS is that it gives people no choice but to document their work.
For what? If they took it away, the source code would still be there if someone wanted to fork it. Not to mention removing TypeScript from an application is relatively trivial.
I can understand that. Does it’s open source status not change anything for you?
I wasn’t going to say it, but yes, 100% 😂
It’s very typical to import code from other files, but it’s also typical to have a minification step that essentially performs what you’re saying, compressing the files down into something more optimal. In fact more advanced solutions essentially stream the minium amount to users as needed, and compute as much as possible in the server side.
To be honest, I’d bet a lot than by not utilising larger libraries and their standardised functions, your code has a good chance of running slower. Besides, for the typical computer and network capabilities today, there’s a lot of wiggling room.
That said, for absolute tip top of performance (where experience is a trade off) you can find fun things like this, where groups do have to push for the upmost performance.
RoR will always have a special place in my heart, but yeah… DHH sure does have opinions. What possible justification is there for removing it when it’s already there? Guess someone could just shift the types out to DT.
Edit: So I read his blog post about it. He’s dropping it because he just doesn’t like it and he’s allowed to not like it. Okay then 🤷
Even alone I find it indespensible. I find it’s mainly useful for writing code correctly the first time around.
What Typescript drama is there? It’s fantastic. It’s been an industry standard for years. In my anecdotal experience the only people that hate it are juniors who did pure JS at their bootcamp and seniors that have refused to learn anything for the last 5 years.
You do you, but no ECMA6 stuff? I don’t use a lot of ECMA6 either because JS is at ECMA14 and continues to change. I can’t imagine reinplementing stuff on every project you work on, though perhaps your work is very different to mine. That said, treeshaking has really brought down the cost of imports and there are few occasions where using a custom solution over a reliable third party library is a good option. Curious to hear your thoughts.
Couldn’t agree more with this comment and the thread in general, it’s a relief to see. I get so frustrated as so many of my colleagues seem to cling to this very old concept of the testing pyramid and associated definitions. It’s completely meaningless in a modern setting. We should mock as little and as far back as possible, yet others seem to delight in locking huge chunks of functionally out of the test base just ‘because’.
We need to know! Using GitHub at the moment and this is driving me fucking wild.