Redux while using React. I don't know why it's popular. It's just so verbose and unnecessary in my opinion...
Also, TypeScript is overrated? I don't think additional type checking helps that much, and also it reduces the flexibility of JavaScript, which I think is the best thing of it. But maybe I was wrong.
I agree with TypeScript. I haven’t done enough front end work to justify learning it, and if you are trying to strongly type a back end, why not use something faster and more tuned than a JS-esque engine?
There is a huge benefit to isomorphic TS when training juniors as full stack engineers. I love TS and we use it to build a distributed microservice backend. We don't have much pain with it. Maybe because we forbid the any type?
Precisely because JSON is dynamic in nature, and TypeScript can always escape to JS-esque dynamicness. Also, NPM got what I wanted, Flask-esque Express.js, which feels quite standard.
JS/TS seems to integrate with the IDE better than Python.
I actually like Kotlin, but I have never done well with Spring Boot, and I hated (someone-else made) boilerplate. Though, I have used Spark Java quite well, but it is not quite standard, so not much tutorials. Also I attempted to use Kotson for dynamic typing in a real static typing language.
Dart for web server feels quite nice, although I haven't dive into it much. Also, less tutorials and Heroku support...
I haven't dive into Golang and Rust much. Perhaps I should try...
Though, for TypeScript on the server, I hate ESM vs CommonJS, and the need for "build process".
Flexibility is nice till your project hits a certain size and you start to wonder why your object property is suddenly undefined even though it wasn't last week.
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.
JavaScript was fundamentally designed to be a dynamically typed language, and you lose half the features of JavaScript. 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.
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 = () => {}
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.
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.
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.
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.
TypeScript is just a pre-compiled JavaScript, just like JSX. It helps integrate with the IDE. (And you can write you own helper as well.)
However, TypeScript lulls into false sense of security, especially with user input, REST API, as type, and any type. Microsoft denied to put this into TypeScript. (Yes, sometimes IDE type checking is wrong.)
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.
Reduxwhile usingReact. I don't know why it's popular. It's just so verbose and unnecessary in my opinion...Also,
TypeScriptis overrated? I don't think additional type checking helps that much, and also it reduces the flexibility of JavaScript, which I think is the best thing of it. But maybe I was wrong.I agree with TypeScript. I haven’t done enough front end work to justify learning it, and if you are trying to strongly type a back end, why not use something faster and more tuned than a JS-esque engine?
There is a huge benefit to isomorphic TS when training juniors as full stack engineers. I love TS and we use it to build a distributed microservice backend. We don't have much pain with it. Maybe because we forbid the any type?
Precisely because JSON is dynamic in nature, and TypeScript can always escape to JS-esque dynamicness. Also, NPM got what I wanted, Flask-esque Express.js, which feels quite standard.
JS/TS seems to integrate with the IDE better than Python.
I actually like Kotlin, but I have never done well with Spring Boot, and I hated (someone-else made) boilerplate. Though, I have used Spark Java quite well, but it is not quite standard, so not much tutorials. Also I attempted to use Kotson for dynamic typing in a real static typing language.
Dart for web server feels quite nice, although I haven't dive into it much. Also, less tutorials and Heroku support...
I haven't dive into Golang and Rust much. Perhaps I should try...
Though, for TypeScript on the server, I hate ESM vs CommonJS, and the need for "build process".
Flexibility is nice till your project hits a certain size and you start to wonder why your object property is suddenly
undefinedeven though it wasn't last week.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.
JavaScript was fundamentally designed to be a dynamically typed language, and you lose half the features of JavaScript. 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.
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 = () => {}
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.
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.
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.
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.
Umm, this would be like saying that JavaScript 2015 (ES6) lies to you about JavaScript because
classkeyword 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 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).
TypeScript has optional typing too. You can start converting your JavaScript project today by annotating your variables with
anyand specifying types later on as you progress with transition.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.
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.
TypeScript is just a pre-compiled JavaScript, just like JSX. It helps integrate with the IDE. (And you can write you own helper as well.)
However, TypeScript lulls into false sense of security, especially with user input, REST API,
astype, andanytype. Microsoft denied to put this into TypeScript. (Yes, sometimes IDE type checking is wrong.)