Are you torn between JavaScript and TypeScript for your next web development project? You're not alone! As we dive into 2024, the debate between th...
For further actions, you may consider blocking this person and/or reporting abuse
I do NOT see "real-world" problem being solved by using TypeScript.
All I see are silly examples of a "function that adds or divides 2 numbers' to justify "type checking". e.g., Who writes a function just to do basic math????
Next, developers are testing (aka runtime) their code LINE-BY-LINE anyway, so "compile-time" checking isn't all that beneficial in saving a developer time coding.
In other words, TypeScript adds a layer of complexity that doesn't have that much benefit to JavaScript world.
NEWS FLASH:
And Interfaces and "advanced OOP features" like access modifiers and GENERICS? They are rarely used and they themselves add complexity when they are supposed to reduce complexity via the supposed "reusability." And was NOT needed for at least 5-7 years after C# was introduced back in 1999. In other words, C# grew as a language and adoption and did just fine WITHOUT Generics for many years.
SUMMARY:
So the TOP FEATURE of TypeScript, "type checking" (the name of the language itself), saves no time in the real world and certainly saves no time when programming "CLIENT-SIDE" as you are going to hit the RUN (F5) button anyway.
Strongly disagreed =)))
Nah, I'm working with JSON everyday =)))))
That's not mean you can always remember that reason, typescript there to remind you every time you read that code
Nope, I more often use type and interface to structure my JSON data like
And last of all
Lucky me, it saves me a lot of time for just its typehint e.g. with ObjectA above
Funny JSON is a readable textual representation of data. So JSON is indeed a string.
What is the result of JavaScript (not TypeScript) statement below?
And JavaScript Object Notation is indeed a string :))) yeah of course it is
Maybe read JSON.org. JSON is used for data exchange. Hence JSON.parse and JSON.stringify. Your example is just a Plain Old Javascript Object so yeah that's not a string. Semantics do matter.
Okay, and you handle JSON data as string instead of Plain Old JavaScript Object in JavaScript? I mean when you receive a “{}” you gonna not JSON.parse and handle it as it is? Context of argument is also important too. All I just wanna say is, not “most of” the data on the client should be handled as string like the top comment of this thread said and typescript help me handle JSON data as JavaScript Object a lot easier.
TypeScript? Nah fam, pure JavaScript is the real MVP!
Yo coders, wake up and smell the coffee! TypeScript's just extra baggage we don't need on top of our lit JavaScript. ES6 already gives us all the sauce.
TypeScript's just a tool for big corps to micromanage your code. Keep your code free and flexy with pure JavaScript!
JavaScriptFTW #TypeScriptIsMid #ES6IsTheGoat
Personally, after many years resisting learning TypeScript and finally learning it to a high level, there's no way I'd make anything with just JS.
The advantages of TypeScript are too great to pass up, even on small applications. My main reason for that is it enables me to think like a software developer. TS leads me to as "what am I trying to achieve?" and "how can I best structure my code to make it a reality?"
You can sketch out an entire application structure by just writing the TS interfaces and types out, seeing how they all fit together and then writing the functionality. TS is arguably the best thing to happen to JS, although ES6 is up there too!
MULTIPLE CHOICE QUESTION FOR TYPESCRIPT USERS
Which Variable Name does TypeScript Solve?
Which Variable NAME does TypeScript Solve?
A: mEvent_Date
B: mEvent_Date_of_NameOfEvent
C: mEvent_GuessMyType
D: mEvent_LetsKeepItASecretType
E: mEvent_LetsGiveThisaVagueName2JustifyTypeScript
for many years I was reluctant to switch. Then I tried TS ona project or two and had mixed feelings ... really good autocomplete was a huge plus. Also, less bugs were created, A LOT less. So, basicaly, when my (new) code passes all checks, in 90% of cases Im done and it works. Before this, i would ping pong often between fixing a line of code, running, finding error, going back, and then cycle the same thing arround. This was "normal". Now I need only one or two iterations. But, ... downside was that often even for sinple functions I'd spend 5x more time to type it correctly, especially in some edge cases. So was wasting time there, insted of wasting time debugging. Hm.
After a year or two, downside is gone. Ive learned TS well enough to write it as fast as pure JS. And then more tools pushed me to next level, like Zod, or Drizzle which "automatically" gives you types (thus also autocompletion and intellisense) for your database. Then tRPC that automates types in backend API responses to frontend.
In short, no way to go back. Faster to write code, less bugs that cause debug/rerun cycles during devrlopment, better UX.
Personally, I believe anybody who learns TS good enough will never go back. Only knowledge/experiance can cause the difference in opinions here. No posts, analisys or online arguments will help you. If you have time to leatn it, just do it and be cosistant on a few projects, then make your own decission.
TS can cause a false sense of security because if you write a webcomponent in TS and its interface is guarded with TS then it is only safe to use with TS. Seen this numerous times and people still say but that is its interface/contract.
My take? Nonsense, everything has a sensible initial state but somehow that is something devs do not like or find difficult.
JavaScript remains a go-to for quick, flexible web development, while TypeScript gains popularity in 2024 for its type safety and scalability. Developers favor TypeScript for larger projects due to better tooling and error prevention. Whether you're building a startup app or a civil id inquiry system, choosing depends on your team's size, experience, and long-term goals.
Personally I've used both and JavaScript just works. Typescript just seems a little extra baggage to carry along that you could just as easily have left behind. I mean sure it does make it easier to read the code in some scenarios but in many ways it also makes it a lot more confusing.
We can assume 70-80% of our data is some or the other way a string entity; that includes JSON objects so it Typescript does not really solve a lot. Again I'm not saying it is bad. It is good in many ways but for me I feel that plain JavaScript just works and personally it is a lot easier to create JS modules
I dislike build chain in daily life, but strong typing is very useful.
Meanwhile, you can have both of JavaScript and and Typescript,
Simply write JavaScript with JSDoc type comments,
and check it with Typescript compiler.
You can also write Typescript definition and import them into JSDOC.
So your code can be directly sourced to your browser, without compilation,
but your editor show you type errors, and you can type check your whole project.
I think that should be the next web coding standard.
Hi Vishal Yadav,
Top, very nice and helpful !
Thanks for sharing.
Great breakdown of JavaScript and TypeScript! Do you have any recommendations for resources or learning paths for someone new to TypeScript?
I'd start studying this content from Matt Pocock, which is his entire book on TS.
totaltypescript.com/books/total-ty...
You can get some great resources on YouTube as well. freeCodeCamp has an excellent resource for beginners: youtu.be/SpwzRDUQ1GI?si=9dlCjnYo__...
Great article. I like that learning one can make you better at the other and that they do not have to be mutually exclusive.
TypeScript because of its creative error handling features.
Great read!!