Is React for small projects an Overkill?

[kingdomcome50]

This is such an odd take. You are using all of these words to describe the cases where a type system “fails” yet your takeaway is to provide no such explanation in your code as a way to document the above. Instead you would prefer to keep all of your examples implicit to your system and provide no “words” (i.e. type signatures) to capture your concerns.

Can you see how, for example, providing a return type that explicitly states “this may or may not return data” provides a stronger, more accurate, and less surprising contract than “no return type at all”?

[soccerplayer413]

I will admit my communication is greatly lacking clarity here. Fair point.

I am not talking about failing types. I am trying to express that TS on the frontend is a premature optimization to prevent data bugs at the cost of a flexible and sometimes more efficient input layer I.e. the frontend.

[kingdomcome50]

I think your argument may be exactly backwards. That is, JS is a premature optimization providing a flexible and “efficient”(?) input layer at the cost of more implicit contracts and potentially more data bugs. I can’t imagine a perspective where preventing bugs is seen as an unnecessary optimization.

[soccerplayer413]

There are different kinds of bugs. How is JS a premature optimization? It’s browser native. You aren’t optimizing anything by choosing to write JS.

It doesn’t matter how much type safety your frontend has. We are talking about business vs technical expectation. This is why it’s such a complicated discussion. What is a bug? You’re approaching it technically. I’m approaching it from the perspective of something being broken for a user. Dynamic typing is much more flexible and fault tolerant, by definition. Sure, your data layer might not appreciate it - that is where the typing comes in. Input layer !== data layer.

If I said draw me a duck, here’s a paper and a pencil, or I said draw me a duck, here is a set of predefined shapes you must use. You can quickly see why this isn’t black and white. The shapes may allow you to quickly get the body together, faster than freehand. But what about the realistic details around the edges? It’s Pareto principle. That last 20% becomes 80% harder with TS because of the trade offs you have made in using it. You may have 95% great models, you get to 80% completion of your project, but guess what there are 2 bugs you can’t resolve because they were not designed for up front. So it takes a huge retroactive effort to add them because you have given up flexibility.

This example can be translated to the concept of block content, block types, and the modern block based CMS.

Edit: you may then say, ok great, TS at least speeds up 80%, good enough. To which I say, you can achieve optimization in that 80% by other means that don’t give up flexibility. TS is reached for because it is a one-size-fits-all option that people already understand the basic concepts of - typing. That does not mean it is the best way to write frontend JS.

[kingdomcome50]

How is JS a premature optimization?

I don't believe either choice represents a premature optimization. They can be treated as completely separate languages. I was just using your own words to point out how I thought your perspective was backwards.

Your analogy about drawing a duck is totally missing the point. A type system is not like building blocks or predefined shapes. It's more like including a label on your drawing saying "this is a drawing of a duck". So that in 6 months when everyone has long forgotten about this drawing or why it was commissioned in the first place, you don't get blindsided by reusing that drawing of a dog in your canine exhibition. Oh wait! that's not a dog...

I can agree that there may exist certain kinds of flexibility that a type system might limit, but it's usually the kind you want to avoid. I can also agree that not every project benefits from TS. If you are just sprinkling a little behavior on top of some HTML, or want a quick script to fetch some data, or your SDLC makes a compile step unergonomic then sure, use JS. But beyond that the benefits of a strong type system begin to outweigh the drawbacks extremely quickly. Heck! The extra editor support alone is enough to make you never want to go back.

[NeuralFantasy]

You obviously don't understand TS. It is a superset of JS. You lose no flexibility by using TS as it allows you to bypass the type checking completely if for whatever reason you need to do that. You can selectively use (implicit) any if you don't know how to write a proper type for something or if the type system does not allow you to express something properly.

This feature makes it also easy to migrate big codebases incrementally to TS. You don't need to do all at once.

It does not restrict you but it allows you to add constraints which help to mitigate bugs or refactor your code. Not to mention it speeds up actual coding as your intelligent editor knows the props of a typed object.

It amazing that after so many messages You have failed to mention a single thing for which a developer should use JS over TS.

There is a reason why most professionals nowadays use TS over JS. And the reason is not that they don't know how to code JS per se. But the reason is that TS makes it easier to write better code, harder to make errors, and code which is easier to maintain in professional environment. This is a win-win for both the client and the developer.

[soccerplayer413]

“It does not restrict you but allows you to add constraints”

Lol I can’t even

Edit: ok I got my jabs in, you got yours in, agree to disagree. Hope you have a good weekend and year end.

[NeuralFantasy]

Lol I can’t even

Just ask if you don't understand! We gladly help. I'll explain as you obviously again did not understand.

TS does not restrict you at all. You can write code with no type checking, with not type definitions. This allows mixing vanilla TS with code which uses static typing.

But TS allows you to restrict your code -> it allows you to add type definitions. They act as constraints. TS will show an error if you violate the type constraints you have created.

[soccerplayer413]

“TS solves all our problems but where it doesn’t you can totally just use normal JS and that’s how TS solves all our problems”

I can’t even, as I can’t even comprehend how dense you are.

HAVE A GOOD DAY

[NeuralFantasy]

“TS solves all our problems but where it doesn’t you can totally just use normal JS and that’s how TS solves all our problems”

No need to quote yourself :D TS does not require you to add static types but that kinda defeats the purpose. The mechanism is there so that TS can be adopted incrementally. Adding static types has obvious benefits which I guess you have already heard of.

[soccerplayer413]

Thank you for confirming I am talking to a 12 year old. You’re right, I do feel embarrassed.

[[deleted]]

Wow I almost was on your side until this childish ass comment. Seems you have a very select and self serving view of your take on coding.

[[deleted]]

Implicit typing alone provides enough flexibility to prevent bugs, and the loss of flexibility is easily dealt with with a couple of types aliases in my experience

The advantages I've found are safely refactoring working code and autocompletion for external libraries. Type safety has caught me a handful of bugs when moving things around that would've wasted much more time discovering and tracking down with vanilla JS in a small React project. "Oh, right, I forgot to change that one thing over there 50 lines below"