Biggest advantage I've seen from using it, is the ability to quickly get into old code. Sure, well I'm writing it. I have a mental understanding of all the different types, but I don't two years down the line.
Also, when multiple people are working on the same code, it's nice that they all are forced to spell things the same way...
For my little site I needed an input element with type=file.
So I was getting started, with TypeScript and all, like the swaggest of web developers.
Came the moment for the actual file input:
TypeScript REFUSED to accept the input element's type as "HTMLInputElement" when that is literally its type.
After TypeScript eating up about 1 hour or so of my time, I decided to get rid of that piece of sh*t for squiggly underlining all my code in Red simply because it's too retarded to understand it.
Any of the TypeScript lovers care to explain?
Needless to say, I ultimately went about doing what I wanted in 5 minutes in VanillaJS and was happy ever after.
Call me again when TypeScript does its job correctly.
So you formed your strong opinion, based on one hour of trying it. Gotcha.
As to your problem:
Use ˋ... as HTMLInputElementˋ if Typescript wasn't able to narrow your type sufficiently, or you believe that the value of typing this case isn't worth the effort. This should be somewhat rare.
Use ˋ... as unknown as HTMLInputElementˋ, if your idea of the variable is completely different from Typescript. But at that point you likely _have_ made a mistake somewhere.
Use ˋ...: anyˋ if you want to completely turn off checking. In most projects, this has to be explicitly specified for each parameter and declaration.
It gets more verbose, the more unsafe your code is.
It's impossible to try to debug your problem with so little to go on. Maybe the type was unioned with something incompatible. At some points, you need to resort to runtime type checking: `if (x instanceof HTMLInputElement) { // TS will know it's a HTMLInputElement at this point } `
Enabling Typescript on an existing, untyped project is going to be rough to start. You'll need to gradually increase the strictness levels and perhaps work on typing one module at a time. With an entirely new project, start with maximum strictness, and things will come together much easier. You might need to learn to do things in new ways to make it easier to work with TS, but that doesn't mean it's wrong.
Certainly, 1 hour to attempt to use any new technology is way too little time. I'd say a minimum of a week of honest effort with a new toy project is warranted before deciding whether it's not for you.
(e: Event) => {
let t: EventTarget | null = e.target;
// here "t as HTMLInputElement" did not work
if (t instanceof HTMLInputElement && t.files && t.files[0]) {
const file = t.files[0];
if (file) {
(myImageElem! as HTMLImageElement).src = URL.createObjectURL(file);
}
}
}
TS wouldn't accept it. My guess is it's not cluttered enough.
My final vanilla version OTOH:
(e) => {
const t = e.target;
if (t.files) {
const file = t.files[0];
myImageElem.src = URL.createObjectURL(file);
}
}
How is the latter not a million times more elegant?
Why do I need to clutter everything with types that I won't even think twice about?
That second version is literally 100% verified and valid Typescript.
`e` is inferred from `HTMLProps<HTMLInputElement>['onChange']`
`t` is inferred from `e`
`files` is inferred from `t`
No halfway experienced TS developer would write any of these annotations.
If you got the myImageElem from a ref, you may need to add a !, because yes, it's not technically guaranteed that the ref is set by the time the callback is called.
Well I haven't ever used next.js in particular, but if I go open a .tsx file and add <input type="file" onChange={[final vanilla version code]} />, it works fine.
t gets inferred as `EventTarget & HTMLInputElement`
The only error is that "myImageElem" isn't defined by the snippet, which is to be expected.
If I insert your first snippet, it complains that (e:Event) isn't the right type, but (e) or (e:any) makes the whole thing happy (except "myImageElem").
If I remove the imprecise "Event" typing on e, then your first snippet can be simplified to:
let t = e.target;
if (t.files && t.files[0]) {
If I keep (e: Event), then the code with "instanceof" works, as does:
let t = e.target as HTMLInputElement;
if (t.files && t.files[0]) {
> highly opinionated solutions as something definite even though it has a narrow focus on what the author cares about
Most users either don't have such strong opinions about their scroll bars, or would prefer it looks coherent with the application, or OS-native (your preference). But I can almost guarantee the larger group of non-technical users will have never thought about the styling of their scrollbars for more than a few seconds.
Also in terms of accessibility, so long as they're doing CSS-only changes, and the bar is sized compliant and has proper focus states, assistive technology won't care.
But I can almost guarantee the larger group of non-technical users will have never thought about the styling of their scrollbars for more than a few seconds.
I think you're saying that this means it doesn't matter, but it actually increases the importance of respecting the users choices. Anyone who has changed their scrollbar has done so because it's important enough to them to bother. They've put effort in. That means there is far more likely to be a good reason not to override their preferred styling.
> But I can almost guarantee the larger group of non-technical users will have never thought about the styling of their scrollbars for more than a few seconds.
So you argument in favor of breaking the UIs of the non-technical users - who don't know that it is not their computer working wrong, but rather the site operator deliberately making things inaccessible - is users don't know that it is you breaking things? Sounds rather horrible.
> Also in terms of accessibility, so long as they're doing CSS-only changes, and the bar is sized compliant and has proper focus states, assistive technology won't care.
Eh, it depends on your audience. My father has very poor eyesight. He doesn't use any assistive tools (e.g. screen readers or magnifiers), but he does need his computer-reading glasses. Accessibility isn't just ADA compliance and/or screen reader support.
Same argument for why we should use tabs over space when accessibility seems squarely focused on the blind and screen readers when visual impairment is a broad spectrum. My eyesight isn’t ‘bad’, but it isn’t what it used to be and with so many code bases using 2-space indentation, I wonder why this isn’t configurable as I have a lot of difficulty discerning the contrast when it’s so shallow.
Just because most users don't think about it doesn't mean it doesn't impact them and that they should be ignored. The very fact that they can't fight for the solution that best benefits them means the onus is on us as designers and programmers to do that for them, instead of handwaving their needs away.
Considering the trend now is to straight up remove scroll bars (why the fuck...), I expect conversations like this will become moot in the not so distant future.
I largely agree with you, however Superhot is the closest thing I've experienced to the "can't do it outside VR" games. I did previously play the browser version of the same game, and it was fantastic still, but there's something different about moving around in space like that.
HL:Alyx got close to the "only in VR" sort of mechanics, but change 2-3 big set pieces, and it could very much be done on a 2D screen.
Well, it doesn't only have to be "only in VR" mechanics, it also has to be a really really fun game compared to almost all the other games you could at the moment purchase and play on your normal PC with a normal monitor and no extra $1000 investment in hardware..
I've tested VR sporadically ever since the first Oculus Rift came out, and I just get a headache after 15 minutes and that kind of has ruined it for me forever I guess as I now associate VR with motion sickness, bad ergonomics etc. That's very personal of course, I know there are others who can run around in VR fine for a whole day without these reactions.
Anyway... the game has to be outrageously good for me at least to use a VR version instead of just sitting on my chair staring on the screen with a cup of tea next to me.
You can get back into it. I get motion sick too with some stupid games (like X-Plane that has this really annoying opposite movement when it's loading, GRR). But just do it slowly and don't keep going the moment you get even a hint of sickness. Soon you'll be running aroudn with no issue.
I tried Alyx and it was just not fun. Not for the game or anything, but I was really just uncomfortable being in a virtual reality environment where I was hunting/being-hunted by aliens. That's really not my idea of a good time - more like a nightmare.
VR needs some less intense and some more fun, low-stress gaming experiences to draw in the casuals like me.
Yes they exist, with laughably meager budgets compared to “mainstream” games.
I’ll concede animal crossing is a good exception to the rule, but this only serves to prove our original point that there’s room for AAA-grade games in this market segment.
> VR needs some less intense and some more fun, low-stress gaming experiences to draw in the casuals like me.
You’re in luck because those types of titles form the majority of VR titles today. The more common complaint is the lack of AAA content like Alyx which is due to the lack of users
The security implications of "find me another device on this network who has gone to a specific page" are immense.
Not to mention accessing account-related information due to improper no-cache headers on the website.
There are lots of grade schools with slow internet, and when OS updates come out, all the kids open their school laptops and get prompted to update, which basically ends the class immediately because the slow pipe can't service 25 identical hundred-megabyte downloads quickly.
there are plenty of more plausible misconfiguration risks that we accept, or consider the operators responsible. i'm not sure why you would take issue with this one.
additionally, content-addressing provides another layer of security beyond location addressing. even improperly cached information is as secure as your hashing algorithm.
Paywalled articles are allowed on HN, from the FAQ[0]:
Are paywalls ok?
It's ok to post stories from sites with paywalls that have workarounds.
In comments, it's ok to ask how to read an article and to help other users do so. But please don't post complaints about paywalls. Those are off topic. More here.
Because they likely use the same API for their website/app/Alexa/etc. platforms, since so long as the same calls need to be made, it makes sense to reuse the work you've already done.
So long as they have reasonable rate limits & security in place, it makes sense to allow anyone to use it to order pizzas from whatever platform they want, because it's still money in their pockets -- not to mention free press from articles like "how to order pizza from vim"
For sale of argument, let's say you were paid half what you currently are, same company/manager/etc.; would you still put in as much effort?
One unfortunate reality is that programmers or other programmer-adjacent jobs tend to be paid quite well, and as such the "work equal to pay" mindset is a bit strange compared to normal office jobs. I've personally known someone at my job, which paid me let's say $X, and paid them $⅓X for us both working on the same project. Surprise surprise, that person put in minimum effort necessary to get the job done, and has since left the company for another that is paying them closer to $½X.
You never "own" a domain. You just rent it from a registrar, who had permission from ICANN to let you rent it. There is no "good" that you can take with you when you give a registrar money for a domain.
The whole point of Mermaid is _not_ having to embed .png's into your Markdown files.
By using the built-in codeblocks functionality of Markdown, Mermaid allows you to source-control the same exact graphs that you would have normally put in as images.
That was a piece of information I missed, then! Definitely a nice usecase to keep in mind.
For me, I'm often either (1) sharing diagrams outside of github (e.g. email), as well as (2) generating a bunch of diagrams based on code or whatever, rather than defining a diagram in a markdown file. There may be better tools for those usecases. Those were what I was trying to do last weekend, too.
But I've definitely passed on adding diagrams to my .md files, or sighed at needing to add yet another imgs/ dir and files to a repo folder. My toolbelt now has another thing hanging off it!
Also, when multiple people are working on the same code, it's nice that they all are forced to spell things the same way...