221–230 of 299 posts
Earlier quoted context omitted.
Amazing how many JS devs I meet (or work with) that are against the very idea of Typescript.
I get CoffeeScript vibes from TypeScript, and look at where CoffeScript is now.
Remember when some people advocated not using semicolons to end statements? Good times... https://javascript.info/structure
I used to be on the "always use semicolons" side of this argument. Having shipped multiple projects using both methods my verdict is clear: It doesn't matter. Why it doesn't matter you ask? Because 1) I am enforcing either decision with eslint rules and 2) i write unit tests 3) code is transpiled (thus semicolons are handled perfectly at the output). Having these three in place, I have yet to encounter a single "gotc…
keyword "yet". It seems like such a insignificant win, with the downside being some very hard to debug runtime error because one element of your build chain has a bug or misses an edge case.
I honestly don't see the logic.
Earlier quoted context omitted.
You could add that "I'm asking because the process of typing an off-topic comment on a forum and waiting for replies strikes me as an inefficient way to get an answer to this question, and I'm genuinely trying to understand that thought process." I highly doubt it would have performed worse than your strategy, which at best resulted in a derail about tone, and at worst scared off the person you were asking and others…
> It seems clear that you find niceties and pleasantries to be not genuine or unnecessary Wrong. It seems clear you all like making assumptions and treating them as unshakeable truth. I scarcely think that your suggested wording (your second attempt, keep in mind) would have satisfied even you without this conversational backdrop providing context. > I highly doubt it would have performed worse than your strategy, Th…
Can you explain, then, why 1) your original post was devoid of any such language, and 2) you dismissed my suggestion, which added some, as being likely to cynically have the opposite effect of what was intended?
I get what you're saying. People often do couch cynicism and trolling in pleasantries. Which makes it difficult to appear genuine when asking a tough question like that. But that means you have to try extra hard if you want results, not give up entirely and go full autism on someone that clearly isn't going to respond well to that.
Earlier quoted context omitted.
I used to be on the "always use semicolons" side of this argument. Having shipped multiple projects using both methods my verdict is clear: It doesn't matter. Why it doesn't matter you ask? Because 1) I am enforcing either decision with eslint rules and 2) i write unit tests 3) code is transpiled (thus semicolons are handled perfectly at the output). Having these three in place, I have yet to encounter a single "gotc…
>I have yet to encounter a single "gotcha" out of omitting semicolons. keyword "yet". It seems like such a insignificant win, with the downside being some very hard to debug runtime error because one element of your build chain has a bug or misses an edge case. I honestly don't see the logic.
Earlier quoted context omitted.
> The default way promises are used is now async/await. `.then()` should not be introduced as anything more than 'you may find this in older codebases'. No, because you might have to write explicit promises in the browser with async API that are callback based. You need to understand how promises work to use async/await at first place anyway. Just like it's better to understand how prototypal inheritance works in JS…
Yes because you can and should promisify old libraries.
Earlier quoted context omitted.
>I have yet to encounter a single "gotcha" out of omitting semicolons. keyword "yet". It seems like such a insignificant win, with the downside being some very hard to debug runtime error because one element of your build chain has a bug or misses an edge case. I honestly don't see the logic.
It just makes the code slightly easier to read. The semicolon is just noise.
Remember when some people advocated not using semicolons to end statements? Good times... https://javascript.info/structure
https://news.ycombinator.com/item?id=2024328 Here’s an example great bike shed discussion from ~10y ago about whether or not to use semicolons with JavaScript. “If you don’t understand how statements in JavaScript are terminated, then you just don’t know JavaScript very well, and shouldn’t write JavaScript programs professionally without supervision, and you definitely should not tell anyone else how to write their J…
Just about anyone who's ever written JS probably knows about the heavy lean towards "always use `===`". And it's not without good reason, because there are more than handful of not-entirely-intuitive implicit coercions/comparison corners associated with `==`. Personally, I think it's OK to use it, but I understand that it requires knowing the rules associated with use and most of all comes with the overhead of keeping them in mind when you do so. Most of the time it will be OK if you know even most of the rules. Sometimes it will not be OK. More often the overhead will cost you attention to other things. Some people have made the call "wouldn't it be simpler if we just did strict comparison and saved our attention for other things?" and while it's not my first choice, I can understand and respect it.
The statement termination thing strikes me as pretty much the same. Sure, if you know the rules, you can do it freely. But it takes something explicit that you don't have to think about and turns it into something implicit that you do. It isn't going to be a problem most of the time, but sometimes it will not be OK. A little more often the overhead will cost you attention to other things. Following the rule that semicolons terminate statements hasn't ever cost me anything.
The weird thing in my experience was the frequent overlap between antisemicolonists and always===ists. My theory is that mostly these people came from Ruby and Python, liked less punctuation for subjective aesthetic reasons, and didn't actually know the coercion rules well or particularly like JS, but that's speculation.
Earlier quoted context omitted.
Amazing how many JS devs I meet (or work with) that are against the very idea of Typescript.
Pretty annoyed with Typescript too. Mostly because of its popularity. Before Typescript most compile-to-js languages existed in their own world. You might have not liked them. But you'd never have to deal with them. Typescript has become so popular that many top javascript libraries use it too. Whatever you think of it, sooner or later you'll be working with Typescript code.
Earlier quoted context omitted.
I get CoffeeScript vibes from TypeScript, and look at where CoffeScript is now.
I don't get this. What do you mean by coffeescript vibes? They are super different languages...
Earlier quoted context omitted.
I don't get this. What do you mean by coffeescript vibes? They are super different languages...
In that JavaScript only needs to adopt a few of its features for the benefits of welding yet another compiles-to-JS toolchain on to projects to dwindle in comparison to writing ES8+.
Even if TS's type annotations would be added to the language (like it practically almost has been, through Babel supporting it), you'd still want to run a tool as you write it to actually check that those annotations are adhered to, rather than having your code crash on the user when they are not. TypeScript is that tool.