DEV Community


Discussion on: What Tool Can You Never Remember or Get Good At?

stojakovic99 profile image
Nikola Stojaković • Edited

Honestly, I'll take undefined over type errors getting in the way of a refactor, or when another developer before you defines an object too rigidly and you need to do something complicated on a deadline.

If something is getting in the way of refactoring it means there was a design mistake - this doesn't have to do with languages being strongly typed or not. Sadly, doing things quick to meet deadlines is most often the cause of creating software which will become hard to maintain later.

JavaScript was fundamentally designed to be a dynamically typed language, and you lose half the features of JavaScript.

You don't lose any feature of the JavaScript because TypeScript is a JavaScript with additional features (more precisely, a superset of JavaScript). Yes, you will lose features like adding strings to numbers, but if you need that, you're doing something horribly wrong.

Actually Typescript is lying to you about how JavaScript works. Class isn't a thing in JavaScript ( for now ). You have functions. Functions are everything. Private isn't a thing either. You CAN get actual private behavior using closures, but it's a strange paradigm for alot of people.

Umm, this would be like saying that JavaScript 2015 (ES6) lies to you about JavaScript because class keyword was introduced in it. Yes, it is just a syntatic sugar for prototypes, but again, it's a construct already present in the JavaScript.

I will say JavaScript needs an answer to the question that classes answer in other languages, but I'm not sure that answer is classes. Half the code in an angular project are import statements and you can't solve any problem without diving 20 levels into some complex hierarchy of rigid, interconnected objects, when 99% of the time you can solve your problem by typing x.newMethod = () => {}

I have wrote medium sized e-commerce system in TypeScript with Nest.js (which uses Angular philosophy for the project structure and the way some things work) and I haven't stumbled upon such problem. The only slight inconvenience I had was having to forward references few times, but I'm pretty sure I could have avoided that if I thought better about module structure (but I don't say what you described doesn't happen).

Python actually did this right. It's still dynamically typed, with type-hinting and optional typing. Of course your going to start seeing massive bloated, verbose, unreadable python code bases now because Developers sometimes just like to type things - but hints are very useful in certain cases.

TypeScript has optional typing too. You can start converting your JavaScript project today by annotating your variables with any and specifying types later on as you progress with transition.

I'd argue over-defining things in the era of the web causes far more problems than it solves. We should let data be data. Excess abstraction is worse than no abstraction. However, the fight of typed vs. untyped is a silly one - the real danger is we are trying to make Javascript into something it isn't, and lies are never a good way to design.

With all due respect, I will say opposite is the case. Understanding what something is and what it does helps you to write more predictable software, less bug-prone. This has been proven over and over in the practice. Sure, it's the overkill to use strongly typed language for writing scripts for automating things or some basic CRUD applications, but once your application starts becoming more complex benefits of strong / static typing outweigh benefits of dynamic typing by a great margin.

Thread Thread
holywar20 profile image
Bryan Winter • Edited

I can't go point by point on this,

From JavaScript docs
JavaScript classes, introduced in ECMAScript 2015, are primarily syntactical sugar over JavaScript's existing prototype-based inheritance. The class syntax does not introduce a new object-oriented inheritance model to JavaScript.

But again with Closures, I don't think we need class at all, and I think class is step backwards. I'm not just pulling this out opinion out of no where. I'm of the Douglas Crockford school of JavaScript. Use a subset of everything, strip it to the bare minimum, aim for readability and not clever. Class is too clever of a thing in my mind, because it isn't actually a class in the way that OO languages actually use class. I have to use it now, everything modern and new uses it, but there was a much better way.

Interfaces however, are fantastic, and something we should use everywhere. So it's not all bad.

I really think classes are an error in JS, and we should be using a paradigm that reflects prototypal inheritance and how it works. IE, your objects are composed, dynamic, living things, and not dead rigid objects, in a rigid hierarchy that we never define correctly. Prototypes work really well with composition style of development, where you have a thing that isn't a single type, but many types or no types.

I keep hearing the scaling argument - but I honestly have my doubts. I've worked on big complicated projects in both dynamic and strictly typed languages, and I find it way easier to fix problems and refactor. I'm not against typing it all, but I do think it's way too overused, and eventually it creates a mess of boilerplate that is hard to reason about. Your mileage will vary.

This reminds me of circular arguments with regards to something like Wikipedia. Harder to screw up, or harder to change? pick one.

I pick easy to change every time, for the reason that you pointed wisely out : you can't control what other people write, only what you write.

Forem Open with the Forem app