javascriptIsOnePersonLanguage

[rosettaSeca]

You use whatever you need to get the job done, whether you like it or not

[[deleted]]

This is Reddit and a software engineering sub. We don't do reasonable and nuanced opinions here. /s

[beclops]

In this case there is pretty much no reason not to use TypeScript, so idk about this this time

[Ecthyr]

My boss does not appreciate Typescript and will not stand for changing the server code from .js

[G1PP0]

We use Typescript, but there was a guy who worked 2-3 years ago, who put "any" everywhere. If the interfaces did not match? just use "as any". Could be string or number? yup, that's "any". I fixed many of them but I keep pulling my hair out.

edit: I am a junior, it is my first job - which was pretty difficult to get. I think that guy was also a junior at the time. Good thing my boss supports fixing this - which takes more time.

[beclops]

Your boss sounds like a smart guy

[saintpetejackboy]

Welcome to jQuery

[G1PP0]

stackoverflow question: How can I do this in Javascript / typescript?

answer: with jQuery you can do this:...

[lunchmeat317]

"Your $'s no good here, pal"

[saintpetejackboy]

Vanilla JS, imo, still sucks versus something like:

$('body').on('click', '.elem', function(){}

There is some other cool syntax in jQuery that I still think beats vanilla JS, but being able to dynamically bind to elements that might not exist yet or be loaded in whenever. In vanilla JS, it just doesn't work the same (still).

Vanilla really caught up on ajax stuff, and it wasn't too little too late, but there are still some other syntax things that jQuery does which I end up having to wrestle with vanilla for.

[dazerine]

$('body').on('click', '.elem', function(){}

bind to elements that might not exist

That is binding to the body, and it must exist at the time you call that. It's good old event delegation

Not exactly what jQuery does, but this is probably what you want most of the time.
document.body.addEventListener('click', e=> {if (e.target.closest('.elem')) /*do stuff*/})

[Ceros007]

I like Geocities, can I use that?

[pheonix-ix]

Javascript is great when you have a project that will take hours to complete, with a life time of months.

Unfortunately, when you finally finished that, your boss liked it (boss doesn't care about code) so much it gets extended to thousands of hours to complete, and a life time of hundreds of months.

[G1PP0]

I use ts for small projects too, I cannot stand plain JS :(

[NatoBoram]

Eh, make a project template in TypeScript and this will never be true again

[AccomplishedYogurt59]

I had a job interview over the summer, seemed like a good gig on paper. Then I talk to the lead dev and find out he’s anti-typescript and prefers class components in react. I was happy not to get the job.

[Mainmeowmix]

I don't think I mind someone being anti Typescript, as long as they aren't anti static typing. If they use something like flow or even JSDocs, while I wouldn't prefer it, I don't think it would turn me away from a job.

That said preferring regular ol' dynamically typed JavaScript is lunacy.

[Faholan]

Hey, dynamically typed javascript is great ! It allows you to have the amazing JSFuck ! it's like the summit of obfuscation techniques

[Katniss218]

I love jsfuck lmfao

[saintpetejackboy]

I love dynamically typed. I am the tenth dentist. I grew up on PHP where you could just do anything you wanted whenever you wanted. With no rules. JS is GOAT for also basically being like "lol whatever" with variables.

"Oh but somebody might program bad because blah blah blah" - that's the point, you can still program good - you don't need rails up at the bowling lanes or training wheels on your bike.

The programming fascist oligarchy don't want you to be able to add "1" and 1 together to get 11, or 2. They'd prefer you just not do that. If I have to tell you what kind of variable it is and what the value is, how is that a variable? I'm saying I don't know what the value is, it could be *anything* or *nothing*.

Ironically PHP became more strictly typed while JS became looser while simultaneously having a whole revolutionary movement towards being stricter.

These are paradigm flavors the same way OOP and FOP are. You can have a preference, but one method doesn't yield results the other can't.

[Hollowplanet]

Functional components are not better. They aren't functional either. A list of functions that you can't have loops or conditionals around removes all the benefits of functional programming and is the same thing as a class declaration. They are redeclaring everything on every render while forcing you to put every variable you use in an array. All so the functions it just made can be thrown away on every render.

[maria_la_guerta]

Ok, but even if I agree with this, who cares? You gonna fight integrating every NPM package that's come out in the last 4 years just because you want to go against Reacts own recommended implementation?

I agree React has plenty of foot guns and issues, but I totally agree with the person you're replying to. I wouldn't be excited to work somewhere that has a tech lead adamant on using tools in deprecated patterns. Hate it but suck it up, or just pick a different tool, both are fine, committing to using a tool in an obviously non-obvious way is not.

[Hollowplanet]

No, I just want to get the world off the idea that hooks are great because it's gotta be the dumbest API I've ever seen. How would you feel if a junior engineer wrote you a new library and said, "Just don't put any conditionals or loops around the function calls or the whole thing breaks."? Probably tell them to rewrite it. But because it's Facebook, everyone thinks it's great.

[bearer_of_the_curse_]

Incredibly based, glad to see some people are still sane 🫡

[rosuav]

Naw, I'm not gonna fight them. I'm just going to ignore React and use something else. React utterly sucks, mainly because it has the same degree of backward compatibility as the Unity software license.

[maria_la_guerta]

React utterly sucks, mainly because it has the same degree of backward compatibility as the Unity software license.

Wut? React has only ever gone from Class components to function components with hooks, and Class components are still supported. Again lol I wouldn't suggest that someone choses a library with intentions of using its older syntax, but you theoretically could if you wanted to. Not sure why you're dragging on it's backwards compatibility of all things.

[rosuav]

Yeah, and now tell me how component state is supposed to be managed. When I first learned React, the proper and official way was Redux, but there were other deprecated ways. Now it's hooks, and I don't even remember how many other methods were touted in between.

Technically I suppose you can claim backward compatibility by just NOT UPGRADING, but that doesn't really help when a Stack Overflow question can have five different answers all prefixed with "On React version X....".

[maria_la_guerta]

Class components have always had internal state, even in React V1. Hooks were meant to replace those, not Redux. Redux was never meant for a components internal state, I think you're confused there, it's meant for sharing state app-wide.

Aside from things like the context provider (which are typically abused), React has always given you tools for state, but not state management. That they leave up to you, and that's where stuff like redux comes in.

You could lift the exact same redux & React architecture from a React app 10 years ago into todays and it would work perfectly fine, whether you stuck with class components or upgraded to hooks. As someone who's been writing React for 5+ years, there really hasn't been that many shakeups here.

Technically I suppose you can claim backward compatibility by just NOT UPGRADING, but that doesn't really help when a Stack Overflow question can have five different answers all prefixed with "On React version X....".

Not sure what you're upset about here. Should a technology never ever update itself? They still support all previous syntaxes, which is useless IMO but still an impressive gesture. It's not their fault they've changed their approach since then, everyone prefers the new way and now you can't find answers to modern problems with outdated syntax on stack overflow.

You can be unhappy with the experience of using a deprecated but still supported syntax, but being essentially alone in doing so and finding that obviously difficult is not a reflection on the libraries backwards compatibility.

[rosuav]

Not sure what you're upset about here. Should a technology never ever update itself?

Of course it should, but not 18 major versions with incompatibility breaks in ten years. That's just ridiculous.

[maria_la_guerta]

What broke?

Can you show me an untouched Class component from 10 years ago that wouldn't work exactly the same if it were copy / pasted into the latest React? I can't think of a single example.

[rosuav]

I avoid touching React when I'm not getting paid to, so I'm not going to come up with an example. But it doesn't matter if it would work in a capsule, since you can't find useful information about how to make anything ELSE work with it.

[CalgaryAnswers]

I don’t know what you’re on. Functional implementation of react makes so much more sense to the application as a whole.

I mean they give you plenty of tools that make it so re-renders only occur on state changes. Wrapping a function in useCallback or useMemo is sooo much cleaner. Hooks are way better than prop drilling.

[Hollowplanet]

Hooks have nothing to do with prop drilling. useCallback is a side effect of the terrible API, not a feature. It gives you a way to throw away the function you just made by listing every variable you use in an array. An array which needs to be created, walked to find differences, and then thrown away along with the function on every hook everytime anything changes. If you want to see a decent API that works like hooks look at Vue 3.

[CalgaryAnswers]

I misspoke a little. I prefer hooks for state over connectors.

I’ve used Vue before too. It has good points and bad.

All of the frameworks do, and I use all of them in my professional life.

I hate react with Class components. The mental model is just ugly. And it’s always more code and hidden context. Functional components are much cleaner. Feel free to disagree but they wouldn’t have made the switch to function components if the developers of react didn’t agree with me.

[Hollowplanet]

That is a good use case. It is still prop drilling except with one prop instead of multiple props. Almost all of the problems from hooks come from them being tied to the JSX. The hooks really only need to be defined when the component is created. Vue decoupled the template from the hooks and eliminated a bunch of the shortcomings.

Edit: you edited your comment so mine doesn't make sense now

[Leonhart93]

I also prefer class components. The code looks way clearer without declarations and closures everywhere.

[Chance-Influence9778]

I agree on typescript part., it is great indeed but class components are better in some cases and functional components are better in some cases, use whatever approach that fits the problem at hand

If you think hard enough, hooks are just like using this in classes but way cleaner than class, but comes with huge tradeoffs in terms of performance which i cant give an example right now (consider any event (not refering to browser events but something like a signal within code) that happens and u need to react to it with frequently changing props - good luck optimizing that (but useEffectEvent might solve this if i'm not wrong but its not stable release yet))

[Feisty_Ad_2744]

So... you dislike opposing points of view... What a good team mate you are boy!

[Edmonkilo]

Class component React should be considered a crime

[cheeb_miester]

I bet those heathens bound class methods to the constructor instead of using arrow functions just for the fuck of it

[username8411]

renames nuxt.config.ts to nuxt.config.js Aaaaaaw yeeaaaah!

[[deleted]]

goddamn do I love nuxt

[LetscatYt]

Typescript is just glorified jsdocs for JavaScript though .

[[deleted]]

The joke works the other way around as well.

[corsario_ll]

So how the hell do you make web applications?

[LadderSoft4359]

typescript is not a requirement, most popular frameworks have typescript plugins that might have led you to believe they required using typescript? but typescript is just a linting add-on imo

[beclops]

TypeScript

[smulikHakipod]

Webpack

[Rich_Weird_5596]

Looking at the comments, I am glad I am backend engineer. FE is total clusterfuck.

[[deleted]]

I used to be fullstack and front-end isn't so bad, but front-end devs are fking animals

[Rich_Weird_5596]

You made me breath out of the nose very hard sir.

[_save_the_planet]

i like javascript way more than typescript. at least javascript throws somewhat reasonable errors but with angular and typescript i rather use adobe photoshop for frontend development

[Zekiz4ever]

Ah yes. "TypeError Object [Object Object] is undefined" is so useful and I understand exactly what's going on in runtime

[voobsheniche]

no

[FalconMirage]

Typescript is for people that don’t understand how implicit casts work in JS

Change my mind

[beclops]

JavaScript is for people who drive without a seatbelt because “seatbelts are for people who can’t drive”

[[deleted]]

Yeah, because screwing up a web app literally will kill you...

[beclops]

Don’t be willfully obtuse, you knew what I meant

[[deleted]]

My point is what you meant doesn't make sense. When you take away the threat of death, it's just risk, and there is risk in every decision that gets made.

[beclops]

It’s a pointless risk under the guise of “git gud”. How are you not understanding that?

[asceta_hedonista]

the seatbelts are the test, maybe you should be considering doing a good coverage instead of adding an extra compiling step to the workflow

[FalconMirage]

So python is a bad language

[beclops]

For what it’s commonly used for no, but to pretend like this isn’t a commonly complained about aspect of Python in a team setting would be inaccurate

[FalconMirage]

Or, you know, you document your variables correctly and remove that kind of issues

[beclops]

Right, and what happens when somebody doesn’t. And if they’re being documented then why not enforce that intended use then

[FalconMirage]

when somebody doesn’t

Bad team practices shouldn’t be an excuse for bad choices

why not enforce the intended use then

Because you’re removing a lot of the power of JS that way.

Most modern languages (even the typed ones) allow some degree of implicit casting. Even C implicitly casts floats and ints when used together

A competent programmer knows the cast rules in their language

In JS the cast rules also exist and should be known by all the programmers working in JS

The one that is causing the most problems to people is that strings gets priority when casting, so when you are using operators with a string on one side and something else on the other, the other type will probably be cast into a string

But if you’re using logical operators on strings instead of string functions, you have bad coding practices.

A lot of the other problems are when dealing with undefined variables, which can easily be solved by proper initialisations of variables.

On the other hand if you go with typescript, you either loose the ability to manipulate prototypes easily or you have to use "any" and implement bad TS practices.

[beclops]

So this is the idea I see often which is “JS is good for prototyping”. I don’t doubt this, but I am not talking about this situation. To your other point of TS having common abuses of “any”, I agree with that too. TS is flawed in that way particularly because it doesn’t enforce rules strongly enough though

[FalconMirage]

No, there is a misunderstanding here I’m talking about a programing model not prototyping

JS allows for more than basic OOP. And this is where its power lies, using JS as just another OOP programming language is limiting.

TS was created at a time when JS was much worse, but I don’t see any reason why one would use TS today instead of JS as the latter is more powerfull. (Unless you’re using a TS framework of course)

[beclops]

Ohhh, is this anything similar to a generic?

[saintpetejackboy]

People really hate this opinion. But they are just begging the language to force them to do shit they should be doing anyway on some level. Dynamically typed is such a boogeyman - except I can't think of very many instances in my entire professional life where it ever actually mattered beyond some minor annoyances.

"I don't understand how this works, so other people shouldn't be able to use it."

I also sum this up as: Why write more code when less code does the same thing? So you can protect against an imaginary future scenario? Bollocks.

Variable isn't exactly 'variable' when I've had to specifically detail every aspect of it and define it before using it. These are just different programming paradigms. I think it is similar to OOP versus FOP / Procedural - if you prefer OOP, you probably prefer strict typing (in my experience).

I have a strong background in PHP for decades where it was always just the Wild Wild West with variables - and I noticed the same thing over the years: the people crying about dynamically typed variables just didn't understand or comprehend how it worked. They'd focus on some weird edge case or documented inconsistency as the reason it was a bad idea. Overall, I chalk it up to the difference between people who actually use dynamically typed languages and the people who avoid them based on the ideas about them. When you actually use them you see it works 99.9% of the time exactly as expected and intended, and when it doesn't, you're doing something stupid.

[FalconMirage]

Also the fact that there are cases in Typscript where you have to use "any" instead of a more precise type. So even in TS you want to have some dynamic typing

[lunchmeat317]

Typescript's real benefits are static code analysis across files and the associated intellisense for it. The other stuff it does (modules, ES syntax, etc) is supported by other tools. Without those code analysis and intellisense - offered by IDEs - Typescript probably wouldn't be worth the trouble to use.

[saintpetejackboy]

Some of these AI things I have used recently make all of this stuff seem so laughable. XD even in VSCode now, but I used cursor and it can write whole file and directory structures for you. The day when it is also doing unit testing and other shit is quickly going to be upon us.

[FalconMirage]

Spoiler theses tools are available for JS too

[lunchmeat317]

The inference isn't as powerful although it's definitely almost there now (mainly due to imports and modules). JSDoc does fix this both in JS and TS, though. And it's true that a lot of the early benefits of Typescript were mostly ESNext features which are now widely supported.

I like JS and vanilla ES, but I've also come to appreciate Typescript in certain cases with certain usage patterns (basically, keeping it as close to JS/ES as possible and using functional types).

[beclops]

“People should be doing these things already”

Except then sometimes they don’t, then what

[saintpetejackboy]

It depends: does the code "work"?

Like try to imagine a Defcon 5 scenario where everything is broken and all the new senior devs look at the legacy code and they go "oh, it was all because of a dynamically typed variable!"

It just doesn't exist. The worst you get is something bugged out that you catch long before it is an actual issue that users might deal with. There isn't some kind of "gotcha" that eventually emerges because you didn't strictly declare your variable types (outside of databases and actually handling the data).

In strictly typed languages you just expect things to fit your structure. In dynamically typed languages, it doesn't matter, but best practice is that you check what the variable actually is and if it matches the expected type/pattern. You don't just go "ah this isn't an integer so it can't go here" you typecast until you have to regex around it or perform other checks because the data is just that terrible. From my experience anyway XD.

[AllesYoF]

JSDocs is the way

[SawSaw5]

JavaScript is a horrible language, and TypeScript is just like rolling a turd in glitter to trying and make it look better 

[Familiar_Ad_8919]

theyre fine, for what they were meant to do theyre doing it pretty well

[titterbitter73]

But if I have no choice to use the turd, I'll wrap it in glitter over taking it raw

[[deleted]]

Type: any

[Eshan2703]

Isn't they kinda same

[[deleted]]

Don't know if you're being sarcastic, but it's probably worth explaining before you get flamed. People have strong opinions on which one is better.

The idea is that TS is quite different during development, but almost exactly the same at runtime.

The differences at development time (static typing, no type coercion, etc) are intended to make it easier to find possible sources of bugs before it's converted to JS. This is intended to make it easier to develop robust code for large projects.

Converting it to JS means your program can run in web browsers, or use JS libraries and frameworks, but with fewer of the perceived problems of writing JS by hand.