Content is what the site visitor needs so it gets top priority.
Markup structures the content so it's next in line.
Visual style can visually rearrange content to make it more effective for the visitor.
Last, interactivity is layered on top of it all.
With HTML forms the site visitor already has the capability to interact with the server-side application via the markup. So JavaScript-based interactivity was seen as non-essential.
It was more important to deliver 1, 2, and 3 to the site visitor and not have a poorly authored script (4) deny the visitor access to the content. That is why it is preferable to have a defective script fail silently rather than errors and exceptions obscuring the visitor's access to the content.
Now client-side script quality is absolutely critical and needs to be held to the highest possible standards.
you are being productive and permissive to crashes until discovered even in production.
This advocates unleashing prototype-grade software into the wild (which seems to be a common attitude in web development) for the sake of "developer productivity" - in terms of software engineering practices it's the worst kind of corner cutting and prioritizes developer concerns over user concerns.
"If a trade-off needs to be made, always put user needs above all."
the purpose of coding is to write code that doesn't crash regardless if it fulfils any business need.
It's impossible to write code that doesn't crash—that would require absolute control.
The issue is that a lot of code doesn't even deal with failures that need to be reasonably expected like an API returning an empty data set or being offline entirely. That's simply incomplete functionality—a defect.
TypeScript ? a burden for most of web project.
TypeScript is far from perfect and at times doesn't offer a lot of value for the required effort. But so far there have been no arguments in any direction to convince those who are enamoured with intellisense to kick their habit (for which most notably library authors have to foot the bill).
If you want to write highly safe web-apps, stick with Java, or follow some edgy tech like .net SAFE stack, or go for Haskell or some web hacking.
This falls into the same trap as TypeScript proponents. That languages can guarantee "safety"—some may make it easier than others but ultimately bad code can be written in any language. And just like TypeScript, Java's type system is unsound.
Conversely, what do you think of JSON, Rest, and NoSQL, all are for the web, and all are not typed kind of programming.
Runtime data can always comply with design time types (e.g. JSON Schema, XML Schema). Specifying the types inline with runtime data would be redundant.
So all this just comes across as a rant from someone who feels inconvenienced by the demands of TypeScript against those who treasure their convenience of intellisense.
Adoption of TypeScript for the sake of types, static typing and safely is largely a rhetoric for the sake of preserving the convenience of authoring in VS Code and the like. There are better tools out there in terms of static typing but those are more inconvenient.
I think "thinking in types" and type driven design is far more important and independent of the implementation language; it can be practiced with dynamically typed languages but doesn't automagically manifest when a statically typed language is adopted.
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 misrepresents the web's approach to resilience. It prioritizes:
i.e.
With HTML forms the site visitor already has the capability to interact with the server-side application via the markup. So JavaScript-based interactivity was seen as non-essential.
It was more important to deliver 1, 2, and 3 to the site visitor and not have a poorly authored script (4) deny the visitor access to the content. That is why it is preferable to have a defective script fail silently rather than errors and exceptions obscuring the visitor's access to the content.
All this changed with client-side rendering. All of a sudden the least important aspect (JavaScript) became the most important aspect without which the visitor would not get access to the content.
Now client-side script quality is absolutely critical and needs to be held to the highest possible standards.
This advocates unleashing prototype-grade software into the wild (which seems to be a common attitude in web development) for the sake of "developer productivity" - in terms of software engineering practices it's the worst kind of corner cutting and prioritizes developer concerns over user concerns.
W3C - Web Platform Design Principles: Priority of Constituencies
"If a trade-off needs to be made, always put user needs above all."
It's impossible to write code that doesn't crash—that would require absolute control.
The issue is that a lot of code doesn't even deal with failures that need to be reasonably expected like an API returning an empty data set or being offline entirely. That's simply incomplete functionality—a defect.
TypeScript is far from perfect and at times doesn't offer a lot of value for the required effort. But so far there have been no arguments in any direction to convince those who are enamoured with intellisense to kick their habit (for which most notably library authors have to foot the bill).
This falls into the same trap as TypeScript proponents. That languages can guarantee "safety"—some may make it easier than others but ultimately bad code can be written in any language. And just like TypeScript, Java's type system is unsound.
Runtime data can always comply with design time types (e.g. JSON Schema, XML Schema). Specifying the types inline with runtime data would be redundant.
So all this just comes across as a rant from someone who feels inconvenienced by the demands of TypeScript against those who treasure their convenience of intellisense.
Adoption of TypeScript for the sake of types, static typing and safely is largely a rhetoric for the sake of preserving the convenience of authoring in VS Code and the like. There are better tools out there in terms of static typing but those are more inconvenient.
I think "thinking in types" and type driven design is far more important and independent of the implementation language; it can be practiced with dynamically typed languages but doesn't automagically manifest when a statically typed language is adopted.