2vue.runtime.esm.js:1887 TypeError: Cannot read property 'members' of undefined
at e.r (about.js:259)
at e.value (siema.min.js:1)
at s.next (about.js:111)
at click (about.vue?1da6:1)
at nt (vue.runtime.esm.js:1854)
at HTMLImageElement.n (vue.runtime.esm.js:2178)
at HTMLImageElement.Yi.a._wrapper (vue.runtime.esm.js:6876)
it @ vue.runtime.esm.js:1887
rt @ vue.runtime.esm.js:1878
tt @ vue.runtime.esm.js:1839
nt @ vue.runtime.esm.js:1861
n @ vue.runtime.esm.js:2178
Yi.a._wrapper @ vue.runtime.esm.js:6876
about.js:259 Uncaught TypeError: Cannot read property 'members' of undefined
at e.r (about.js:259)
at e.value (siema.min.js:1)
at about.js:76
This is from your site.
If members had type Member[]? this would have been caught by typescript, and you'd be forced to check whether it was defined.
It only took me a minute on your site to find that, what else do you suppose is lurking in there that could've easily been caught pre-runtime?
Thanks Nikola for sharing your view, I really understand what you're saying.
My point of view about TS is that it adds extra code... and from my experience: extra code = more work and more time consumed (no matter how it is).
I always see the LOC as a liability, not an asset.
I don't know why you think I'm just assuming it - I actually have experience working with a bigger code base written in JavaScript and TypeScript
I saw your GitHub has 17 contributions in the last year (and mostly on non JS code), it's something you might want to change... cuz people do judge on that (sorry for judging too fast).
I'm not saying that just using JavaScript will bring you the problem
You just laid your hands on the blind spot that I saw in this whole discussion (from other devs in this topic).
Which is (dynamic vs static) typing langs will solve the problem, it's not.
I believe the whole discussion should be about the architectural & design decisions and the developer expertise.
Yes, you're absolutely right about how TS introduces better design decisions.
I faced exactly the same experience when using C# then Python. I said C# (and ASP Core) tells you exactly how to do things, but Python gives you all the flexibility and power to do things in anyway.
In time, I realized that I finish my projects in Python on time much more faster that what I did on C#!
Why? cuz I transferred that knowledge (of doing things the right way) from C# into a language that allows me to do me doing things in anyway.
And that is ultimate power, and the only catch is as you know:
“It only took me a minute on your site to find that, what else do you suppose is lurking in there that could've easily been caught pre-runtime?”
Hahahahahahaha hahahaha hahaha 😂 these fools with their “TypeScript is not helpful” crap. 💩I can just imagine how hard it would be to understand their codebase.
...undefined objects during runtime aren't necessarily going to be caught by your static type checker. if the api changes and leaves out that key object, what good did your type system do?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is from your site.
If members had type
Member[]?this would have been caught by typescript, and you'd be forced to check whether it was defined.It only took me a minute on your site to find that, what else do you suppose is lurking in there that could've easily been caught pre-runtime?
Thanks Nikola for sharing your view, I really understand what you're saying.
My point of view about TS is that it adds extra code... and from my experience: extra code = more work and more time consumed (no matter how it is).
I always see the LOC as a liability, not an asset.
I saw your GitHub has 17 contributions in the last year (and mostly on non JS code), it's something you might want to change... cuz people do judge on that (sorry for judging too fast).
You just laid your hands on the blind spot that I saw in this whole discussion (from other devs in this topic).
Which is (dynamic vs static) typing langs will solve the problem, it's not.
I believe the whole discussion should be about the architectural & design decisions and the developer expertise.
Yes, you're absolutely right about how TS introduces better design decisions.
I faced exactly the same experience when using C# then Python. I said C# (and ASP Core) tells you exactly how to do things, but Python gives you all the flexibility and power to do things in anyway.
In time, I realized that I finish my projects in Python on time much more faster that what I did on C#!
Why? cuz I transferred that knowledge (of doing things the right way) from C# into a language that allows me to do me doing things in anyway.
And that is ultimate power, and the only catch is as you know:
@maxinertia
Does that affect the end-user in any way (would he see any unexpected result)? NO
Then, do I care? NO
Yaser,
Just because something doesn't affect the user now, doesn't mean it won't affect it later or cause another, seemingly unrelated error.
That was hilarious, you caught him off guard with that bug.
“It only took me a minute on your site to find that, what else do you suppose is lurking in there that could've easily been caught pre-runtime?”
Hahahahahahaha hahahaha hahaha 😂 these fools with their “TypeScript is not helpful” crap. 💩I can just imagine how hard it would be to understand their codebase.
...undefined objects during runtime aren't necessarily going to be caught by your static type checker. if the api changes and leaves out that key object, what good did your type system do?