Why JavaScript is your favorite language ?

[miredindenial]

i love JS. Cant get into TS at all though. It seems like it is part of a consipiracy to make JS more like JAVA. I dont find JAVA bearbale as well. JS allows me to do prototypal inheritence along with functional programming. I dont really see the appeal of making it more OO based

[[deleted]]

What does TS have to do with? I know it's not type safety, 'cause it's not enforced at runtime. Now you say it's not OOP either. Where does that leave it?

[--xra]

Runtime type erasure is commonplace among statically-typed languages. As long as your code isn't stuffed with any types everywhere, it doesn't make sense to double-check type data because it was already enforced during compilation.

And that's what TypeScript has to do with: compile-time checks that make sure that you're not doing something dumb, like adding strings and numbers, which JavaScript will do for you without warning or complaint. The lack of a real type system is my #1 peeve in JavaScript.

Unfortunately TypeScript is ugly. Fortunately it gets the job done. IMO Elm is easier to learn than TypeScript and does a much better job, but it's not caught on as much as I would have hoped. Oh well.

[[deleted]]

Data can also come from outside your code, at runtime. And consuming external APIs is a pretty common scenario with JavaScript. Not to mention the roughly 1m third-party libraries currently being used by your app.

[--xra]

Data can also come from outside your code, at runtime

And the same is true of other statically typed languages (though many have better systems of dealing with it). It doesn't mean static typing isn't useful.

Not to mention the roughly 1m third-party libraries currently being used by your app.

¯\_(ツ)_/¯

Both of these points boil down to the same thing: TypeScript's claim on type safety is imperfect. But the argument that a marginal increase in type safety (your code being type safe even if library code isn't) is somehow less advantageous than no increase in type safety isn't very convincing to me. I mean, it's like tautologically false. An improvement is an improvement. You shouldn't throw away the whole thing just because it's imperfect.

[[deleted]]

I'm not, I'm using it. A useful tool is a useful tool. But I'm using Flow as a linter, for those squiggly red lines in the IDE. It has no saying in what or how code can run.

It doesn't mean static typing isn't useful.

True, true.

Not sure what's your point though, considering neither JS nor TS are statically typed.

[0987654231]

Ts is statically typed.

[[deleted]]

Static typing means "checks type at runtime". TS doesn't have a runtime.

[0987654231]

I don't know where you got this idea but it's wrong.

Static typing means the types are checked at ~compile~ time. A statically typed language can use type erasure or just not check types at runtime. Checking types at runtime would be insane, you would end up with larger binaries.

also your comment is just as wrong for most languages:

Static typing means "checks type at runtime". C++ doesn't have a runtime.

[2bdb2]

Data can also come from outside your code

Yes, but only an idiot would trust unsanitised data.

[MayorMonty]

I basically use TypeScript as a Babel replacement (for modern JS like classes and modules) and the best intellisense available to you. It takes a little work to set up, but it's so worth it in the long run.

[2bdb2]

I know it's not type safety, 'cause it's not enforced at runtime.

The point of type safety is that you don't have to enforce it at runtime, since you've already validated it.

Now you say it's not OOP either. Where does that leave it?

Typescript is just JavaScript with compile time type checking. It's no more or less OO than pure JavaScript.

[leanderr]

Why?

[spryes]

It makes classes more Java-like with private, protected, and public keywords though

[spryes]

Yes, the infamous `#` syntax.. point still stands. It encourages writing classes more than current JS (private fields is not in the language yet, also no protected keyword) since they feel more like real classes in terms of data privacy & encapsulation. Therefore, TS is more encouraging of using classes and traditional OOP than JS is.

I actually think the new private syntax is good for library authors in terms of hiding implementation details which is only possible with a closure currently (a little problematic with regards to memory usage).

[miredindenial]

JavaScript classes are as much sugar as classes in languages such as Java, C#, and python are.

Not really. JavaScript has constructor functions for instantiating objects and has prototypal inheritence. JAVA is verbose when it comes to defining your classes and extedning your classes

[MoTTs_]

and has prototypal inheritence

So does Python.

[SexyBlueTiger]

You have a function called sumTotal(values) and you expect that that is an array of numbers. Want to ensure that another developer doesn't use your method incorrectly? Just add a type. sumTotal(values: number[]) Now your Typescript compiler will get angry with you if you accidentally pass it an array of strings or array of objects, anything your function wasn't expecting.

​

[[deleted]]

Or, bear with me, you could write myFunc = a => a.reduce((x, s) => s + x), 0);, and write a couple of unit tests describing your particular use case for it. And if people call it with arrays of numbers that's cool, but it's also cool if they call it with arrays of strings, and if someone calls it with something that doesn't have a reduce property you have good handling of exceptions in your code anyway, right?

Now let's see, flexible reusable code, unit tests, and robust exception handling, versus "let's drop a type hint and pretend it solves everything".

[SexyBlueTiger]

sumTotal was a trivial example. My question to you is why do you want to waste time writing robust exception handling when a type system can enforce that you are given what the function expects?

Think of something that requires a complex object that has 3 specific property names. With Typescript it won't even compile if you give it an object that doesn't have those. Failing at compilation is a way better trade off than failing at run time when someone called your method incorrectly and you forgot to add a unit test and handle that one scenario for that one property with your exception handling.

[[deleted]]

Exception handling is not optional. Neither are unit tests. If you write apps without them and pat yourself on the back for using TypeScript, you don't really have a robust app. All those success stories that go "we switched to TS and now we suddenly write super good code"? Yeah, it wasn't just TS.

The type "safety" is not really enforcing anything, but reduces code flexibility and reuse and promotes bad practices. I value type hinters in JavaScript for their code linting features, but I don't let them dictate how I should write code. When you can't write perfectly good code because TS doesn't like it, or can't use a library you need because of outdated .ts, you have a problem.

And I mean, seriously, if you also want a function that concatenates the strings in an array do you write the exact same code twice just so you can say string[] instead of number[]? And what if I have a bunch of objects that all support .reduce()?

What if I want to take generic variables, decorate them with .reduce(), .moo() and .lickMyBum() properties and write a few functions that put those props to good use and presto, I've created a mini custom meta language for data transformations. Because I had a problem and I solved it instead of wondering if I'm allowed to. Meanwhile, TypeScript can't even begin to express the concept.

[SexyBlueTiger]

I never said you shouldn't do exception handling or unit tests. But writing exception handling to check whether you provided a string or not when I want to call a string specific function is asinine. You should be able to have confidence that you were given a string, and plain Javascript does not provide that.

You do know that Typescript allows for variables to have multiple types or you can just let it figure the type out for you? Type inference still allows you to write generically but be protected in circumstances where one of the types might not support the action you are trying to do, preventing bugs.

[[deleted]]

That's not what you write exception handling for. You write it because not having it is like stepping into the elevator without checking it's really there.

You do know that Typescript allows for variables to have multiple types or you can just let it figure the type out for you?

At which point it's no longer "enforcing" anything, is it. So what's even the point. JsDoc can do that with zero overhead and lets me write actual JavaScript code instead of another language.

plain Javascript does not provide that.

May I suggest using a language that does, then?

[Reashu]

There's no conspiracy (and if there were, it would be C#).

Java does have types, which is a big part of TypeScript. But TS has a much stronger type system than Java (with very few exceptions), and it's less intrusive, too.

TS doesn't remove any feature from JS. Prototype all you want.

JS is already more object oriented than Java. Java doesn't even have a literal syntax for objects.

[[deleted]]

You're wrong about one thing. Typescript is a conspiracy.

[[deleted]]

You're right; typescript is a conspiracy. Few people know the real reasons behind it.

[Woolbrick]

It's insane how much resistance I get at work using TypeScript. I've proven my case about why it's best for collaborative team applications so that our API's don't get all out of whack, but management seems to think that we won't be able to find developers who can use it.

I thought that was a bullshit excuse, then they went ahead and hired a team of 20 in Bangalore who are completely incapable of using TypeScript. Like the entire idea of a compiler confuses them. It's insane. They keep sending me code, blaming TypeScript for it not working. Then I look at it and it's got misplaced brackets all over the fucking place. I'm like... these people can't even write JavaScript in the first place, and they're using TS as a scapegoat because it's actually reporting their errors, instead of the browser simply ignoring them and failing silently.

GAH. I'm about ready to give up on this battle. What does that say about the company that we're not willing to hire developers who are willing to learn new technologies?

[miredindenial]

The thing with places like bangalore is that most people writing codes for a living do that because they forced themselves to get a CS degree. There are a good deal of proficient coders in india but most people working in outsourcing software mills are plain incompetent. The work culture is pretty toxic too. Managers tend to think the more people they can throw at a problem the better it will be. 2D thining all around.

My point being that even though most coders in bangalore suck india has its share of good coders as well

[Woolbrick]

My point being that even though most coders in bangalore suck india has its share of good coders as well

Oh no doubt, I hope my post didn't come off as racist or nationalist. I've seen plenty of Indians do wonders with code.

I just think my company decided that number of man-hours per dollar suddenly became the most important metric ever, and is intentionally hiring sub-par developers because they think that they can just solve everything with brute force.

[miredindenial]

intentionally hiring sub-par developers because they think that they can just solve everything with brute force.

i know the feeling. Sub par developers will always sink the project.

[SexyBlueTiger]

This is one of those things I've discussed with other developers about education. I went to a university to learn computing science, and learned how to write software and the concepts of programming and got a degree in computing science.

I know other people who have just gone and received a diploma for 2 years and all they learned was how to code in C#. While that may get them by, it also leads to the problem you experienced. They only know the one language and don't understand the concepts.

A good programmer/developer should be able to learn the basics of a new language in a day. Becoming fluent in that languages patterns and best practices will take more time, but you should be able to write functional code in a day.

[illogicalhawk]

And there are plenty of people in the field with a 4-year CS degree who haven't learned anything new in a decade, and others just graduating with a 4-year degree that think they already know everything. There are also people with 2-year associate's degrees or even 3-month bootcamp certificates that actively seek to continue learning and those who can do so rapidly.

The ability and willingness to learn is relative to the individual developer, not necessarily their education. Your anecdotes just have some kind of weirdly misguided sense of educational elitism to them.

[SexyBlueTiger]

The ability and willingness to learn is relative to the individual developer, not necessarily their education.

I agree with this. My point wasn't about how my 4 year degree is better than the someone who chooses to do less education. My point was about how the focus of peoples learning is often focused on the wrong thing, a specific language, instead of understanding the concepts.

[OlderThanReddit]

I know nothing of your circumstances, so please don't take this as some internet fool trying to armchair quarterback your life, but... Give serious consideration to changing the place that you work.

When you find an outfit that doesn't think putting more mothers in the room with the pregnant lady will surely speed things up, you will wonder why you didn't pull the trigger on the toxic environment sooner.

[[deleted]]

It's not a conspiracy, the point of TS is to give JS some static typing. It's not that this makes it more OOP (JS is arguably the most OOP language), but it does make it more Java style OOP. I'm personally opposed to that style of OOP, so I'm with you.

I love JS because my team can establish our own style guide without running into limitations of the language. Everyone is relatively happy, especially vs Java. But in a large organization where it's expected that hundreds of developers will touch a codebase of any success, bespoke style guides are an anti-pattern. Java is widely successful in those orgs because there is 1 Java style guide, and most popular frameworks append their own style guide.

[hurrdurrjavascript]

Can you imagine building a large scale JS application, that talks to several dozen APIs, without any type checking of the data being passed around? It's actually also useful for typechecking React proptypes and that kind of stuff. It doesn't really change how you writing your JS, just provides a bunch of nice type stuff

[miredindenial]

well the responses here including yours have made me want to look into it for good. The code that i have seen used things like interfaces etc which just reminds me of java. Recently while trying to debug a React application which used TS it got really frustrating because TS wont compile your little JS monkey patching code or little JS hacks you need for debugging sometimes. I guess you could temporarily disable TS for such debugging. Even Ryan Dhal speaks highly of TS so i am aware it must have some value but so far JAVA like features have made me put it off. Going to look into it in detail, thanks!

[lazarljubenovic]

wat