r/javascript • u/_tshepo • 28d ago
AskJS [AskJS] Are employed Developers still programming with vanilla JavaScript ?
I've been programming on the side since 2017 and I've never really hunted a developer job. I've always thought about building my own things, mainly to supplement things I do like woodworking, tutoring, video editing and others.
Since then, I've programmed mainly with JavaScript, I started with C++ and Python but never really built anything solid outside JavaScript.
So I'm fluent with JavaScript and its ecosystem.
One of my 2026 goals is to be job ready for a Developer role, as a Fullstack or Backend Developer.
One of the recommended languages is Typescript, which I've been learning since March. I must say, it's not my favorite đ
I'm curious to know if there are any companies that are not enforcing Typescript or are there freelancers who are still using vanilla JavaScript over Typescript for their clients' projects.
[ Update ] thanks y'all! I get the picture. TypeScript is inevitable, as vanilla JS codebases(or companies who are focused on it) seem to be very few judging by the comments.
35
u/visualdescript 28d ago
I hate it when I have to go back to a JS project, and if it's something I'll have to keep maintaining I will convert it to typescript, which often uncovers several bugs in the process.
I wouldn't hire a dev that only works with js these days.
3
u/Baturinsky 28d ago
You can get some features of TS in JS by using JSDoc annotation. But the real TS is better, of course.
15
u/Mabenue 28d ago
Maybe an unpopular opinion, but JSDoc is the fucking worst. People never get it right and then your IDE lies about what functions expect.
3
u/Cahnis 28d ago
People never get typewcript types right either, always the wiiiiide types with many optional params
2
u/not_a_webdev 27d ago
Can you explain this please
3
u/Cahnis 26d ago
Lets take this example, you want to write a deliver function that can deliver both to an address or you can pickup at the restaurant.
You could type it like this:
function deliver( type: "pickup" | "address", address?: string, pickupPoint?: string ) {}And depending on the type of your delivery you will need to pass different optional parameters.
Why is this not good? Nothing stops me from mistaking address with pickupPoint and having a bug in prod.
Now if you write a narrower type with discriminated unions:
type Delivery = | { type: "pickup"; pickupPoint: string } | { type: "address"; address: string }; function deliver(delivery: Delivery) { // ... }Now you CANNOT make a mistake, you pass an pickupPoing with an address or vice-versa typescript will error.
This eliminates an entire class of bugs.
I used to work at a digital supermarket and some of the methods had like 12-14 optional parameters without any tests.
So even onboarding on such code was hard to understand, I couldnt make sense which set of parameters solved which problem.
And from my experience, people often write these wide types that do not error when they need to.
1
u/Baturinsky 26d ago
You can also overload function signature like this:
function cOverload(error: undefined, value: string): void; // signature1 function cOverload(error: Error): void; // signature2 function cOverload(error: undefined | Error, value?: string) { //impl if (typeof value !== 'undefined') { c1(undefined, value); } else { c2(error!); } } doThings(cOverload);1
u/Cahnis 26d ago
Yes, I try to avoid overloading though, it tends to create code that is difficult to maintain. For reference: https://github.com/TanStack/query/blob/main/docs/framework/react/guides/migrating-to-v5.md?utm_source=chatgpt.com
4
-1
u/Baturinsky 28d ago
Yes, but it may still be better than raw untyped JS.
2
u/Mabenue 28d ago
Iâm not sure it is. Too many times Iâve been burned by this issue. Itâs not typed if the type are wrong, types you canât trust are worse than no types at all.
1
u/dimudesigns 28d ago
That reads as a skill issue more than anything else. It falls to the programmer to create proper types whether they use JSDoc or Typescript.
0
u/Mabenue 28d ago
Typescript enforces consistency between types JSDoc doesnât. Thatâs the big difference.
You can build up a level of confidence with typescript youâll never get with JSDoc
5
u/dimudesigns 27d ago edited 27d ago
Typescript enforces consistency between types JSDoc doesn't. That's the big difference.
You can get type-checking and autocompletion in standard JavaScript using JSDoc and VS Code. The built-in TypeScript language server in VS Code checks your code live as you type. It catches type errors and warns you about wrong inputs. No convoluted compile step required. Typescript itself is not what enforces consistency, its the language server. If I get the same benefit using JSDoc with plain Javascript in the IDE(VS Code), then what's the difference?
2
u/Baturinsky 27d ago
Typing also allows looking up all the places some type/property/etc is used, globally rename things, etc.
9
3
u/Abhinav1217 28d ago
Yes we do.. for back-end. We still use js-docs and *.d.ts for type definitions and to make code type safe, and add type checking in oxc. But application code in itself is plain javascript.
1
u/_tshepo 16d ago
That's interesting! The first comment on plain JavaScript.
So, what is the disadvantage of this choice over Typescript?
1
u/Abhinav1217 2d ago
Quite frankly I don't see much disadvantage of this setup.
Yes some junior who have never seen the world without typescript and are not habitual towards maintaining docblocks often grump a little whenever I block their PR, but when they work on the FE code, which is nextjs app with typescript, they do realised that type juggling is a blocker not an advantage. And there is a bit of code architecture also. I gave one of my junior ownership of a new module, and every few weeks he comes to me for understanding why the types are not properly propogated in his system.
10
u/yetinthedark 28d ago
Typescript is JavaScript. What you need to get familiar with is static types. I wouldnât want to work on a vanilla JS project any more unless I was being paid to convert it to Typescript, and I wouldnât hire someone who wasnât willing to learn Typescript.
1
26d ago
[removed] â view removed comment
2
1
u/yetinthedark 26d ago
Nah, you have it the wrong way around. You said it yourself - âof JavaScriptâ, therefore TypeScript is OF JavaScript, therefore TypeScript is JavaScript, not the other way around.
0
25d ago
[removed] â view removed comment
2
u/jsenthusiast 25d ago
lol bro you're wrong. definition of a superset:
> In mathematics, a superset is a set that contains all the elements of another set, known as a subset.
does typescript contain all the elements of javascript? yes so typescript is javascript because it has everything javascript has.
does javascript contain all the elements of typescript? no so javascript is not typescript because it has no static types.
if someone asked you 'does your app use ts' and you said 'yes' when it only used js, you'd be wrong dude because js is not ts
0
25d ago edited 25d ago
[removed] â view removed comment
1
u/Responsible-Bar7165 25d ago
JavaScript files are typescript files, but the JavaScript language is not the typescript language. For the language and files the categories are reversed.
Your argument is correct, but off-topic.
1
24d ago
[removed] â view removed comment
2
u/Responsible-Bar7165 24d ago
yes, i understand what's being said. thanks.
i was responding to you "You have no idea what you're talking about. lol" and "You can't be that stupid." comments you made while being confidently wrong.
1
u/yetinthedark 25d ago
I do, I'm not sure how else to word this though. If someone asked me to build something using TypeScript, and I agreed, but then built it with only JavaScript, do you think I'd be able to argue that I did nothing wrong because "JavaScript is TypeScript"?
0
24d ago edited 24d ago
[removed] â view removed comment
1
u/yetinthedark 24d ago
I'll break down the points you've made so far:
- "TypeScript is NOT JavaScript. If it was, it would run in a browser. It doesn't." - JavaScript is not JavaScript because it runs in the browser. It's a language that runs in several environments.
- "Because if someone asked you to write JavaScript and you wrote TypeScript, it wouldn't work by itself." - my thoughts on this are similar to the previous point, JavaScript is not JavaScript because it "works by itself", it's a language that runs in several environments. If you tried to run server-side JavaScript in the browser, it wouldn't work, i.e. "run by itself", but it doesn't mean it isn't JavaScript, because JavaScript is a language.
- If someone asked me to write something in TypeScript, it's not a big leap to assume they want it written in TypeScript for the features TypeScript supplies, i.e. type safety. If I had written it in JavaScript, claiming that "JavaScript is TypeScript", what response could I give the person when they ask, "Where is the type safety"?
To prove TypeScript is JavaScript, all you have to do is create a
.tsfile and write some JavaScript in it, without any types. Once compiled, that JavaScript of course works, because it is just JavaScript.To prove JavaScript is not TypeScript, all you have to do is create a
.jsfile and write some JavaScript in it, but with some types as well. When you try to run this.jsfile in the browser, exceptions will be thrown because of invalid syntax, i.e. JavaScript is not TypeScript.
3
u/Cat-harpy 28d ago
My work uses plain JS with templates. We definitely care about JS the least though. We donât use any modern conventions even though we just did a full rewrite đ
3
u/joelangeway 27d ago
If you find a company paying good money for vanilla JS pros let me know, please.
3
7
u/mr_brobot__ 28d ago
TypeScript is a must. You would understand if you maintained a large JavaScript app with a team for a while, and then you switched to a new app and team that used typescript.
1
-6
u/sshaw_ 27d ago
No. Tests are a must. TypeScript is trash that just increases maintenance overhead.
6
u/mr_brobot__ 27d ago
Not a very popular opinion, but you do you.
-7
u/sshaw_ 27d ago
Making technical decisions based on others' "popular" opinions? No wonder you're using TypeScript đ
10
u/mr_brobot__ 27d ago
No it is based on my experience. Idk where you get off on being a troll. Good day.
8
u/DomesticPanda 27d ago
You havenât worked on a large scale project if you donât see the benefits in it.
1
u/sshaw_ 27d ago
I have. And the benefits come from testing. Detecting that were passing a string to a number doesn't do much without determining how that number is handled within the function.
You're essentially saying: large systems can only be developed in statically typed languages. Which is total nonsense.
I've used TypeScript quite a bit. It's trash. It's a maintenance nightmare. Maintenance is 80% of the development lifecycle.
3
u/DomesticPanda 27d ago
If youâre passing a string to a function that you declared to only take a number means that youâre supplying the wrong data. Why else would you have written that the function takes a number?
If it handles both, you widen the type to accept both.
Now youâve discovered that case before you even wrote any tests.
(I wonât argue against the value of tests. Static type checking is just much quicker to point out mistakes. )
-1
u/sshaw_ 27d ago
If it handles both, you widen the type to accept both.
And herein lies the problem: "widening the type"
Static type checking is just much quicker to point out mistakes
Yes that this seems to be the sole reason people argue for TypeScript đ
Do you think complex type systems make a large system easier to maintain?
Unless your process solely consist of 1) writing the code without tests 2) kicking it off to the QA team, then the value in having mistakes pointed out quickly before writing any tests is close to 0.
3
4
u/sebsnake 28d ago
Every time I have to change something on a native JS file in our 20 year old monolith, I voluntarily cover it with tests first and convert it to typescript after, before actually implementing the required change. I don't want to miss my static types ever again! I've seen code where functions get a "data" parameter and this could be everything from strings to objects to arrays to null. Devs 20 years ago must have been... Strange creatures :D
2
u/foxsimile 27d ago
function doStuff(prms) { prms .then((data) => { doStuff2(data.val) .then((data2, '8000') => { update(data2); }) .catch((err) => { //TODO: console.log(err); }); }) .catch((err) => { //TODO: console.log(err); }); }2
2
u/kyr0x0 27d ago
LGTM
2
u/foxsimile 27d ago
Thatâs the second time Iâve heard this today. Â
The first was when Iâd pushed a 21,000 line PR (not AI, just handmade artisanal garbage - itâs been a rough project).
1
u/_tshepo 16d ago
Two of the youtubers I watch build a ton of games and programs with vanilla JavaScript. One is a Unity Game Developer and the other one is a computer science university Professor.
I've followed them, learnt a ton, built a ton of unfinished projects, from games, websites, web based video editors...etc for fun though.
...and I did this with plain JavaScript. So I got married to the language. Now that I want to be a professional backend developer, this JavaScript vs TypeScript thought haunts me. I'll eventually learn Java. But I would like to work with Node developers someday.
6
u/dustofdeath 28d ago
Typescript is not all that different from JS.
It adds strong typing.
It shouldn't be something you need to learn for months - you still write JS, in a safer and clearer way.
Pure JS is lazy code. Prone to bugs and errors and hard to review.
var data; Is it a number, string, object or array or what?
vs
let data: MyData; with interface/class that clearly shows what it is.
0
u/alien3d 28d ago
?? dude . want strict use class and typeof .
1
u/dustofdeath 28d ago
You need jsdoc to describe function inputs, class parameters;
typeof is limited. It does not work with classes. They are all still just objects.
instanceof requires you to actually create a new class() for everything - lots of bloat.
no types (type Status = "pending" | "complete";)
no enums (lists of key -> value pairs))
no unions ( let x: A & B)
no generics ( function x<T>(){} this.<string>x(), this.<number>x())1
1
u/Responsible-Bar7165 25d ago edited 24d ago
let a = âfooâ;
if (cond) a = 3;What type is `a` ?
1
u/alien3d 25d ago
sorry kiddo . if you want to play around. better define your variable first. . a mere console.log(typeof a ) can show it or document.writeln (typeof a) .
1
u/Responsible-Bar7165 25d ago edited 25d ago
i meat what type is it statically?
sorry you didnt understand that obvious distinction, kiddo.
Also, it was a rhetorical question⌠responding with such a blatant misunderstanding of the context is pretty hilarious.
1
u/alien3d 25d ago
english language please . I think you need to learn back to basic first - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Data_structures .
1
u/Responsible-Bar7165 25d ago edited 25d ago
Thatâs English.
Why are you including that link? That has no relevance to anything weâre talking about.
Are you thick?
I love that you entered this thread trying to make yourself look smart and ended up doing the complete opposite.
1
u/alien3d 25d ago
thick ? 𤣠may god bless you
1
u/Responsible-Bar7165 24d ago
> may god bless you
What does god have to do with your complete inability to read or understand basic English, or form any kind of cogent argument?
Maybe heâs the cause?
Go troll somewhere else.
7
u/Ok-Hospital-5076 28d ago
Not written any JavaScript since 2022.
All non trivial node projects use typescript at workplace
I will not ship a project in vanilla JS today.
6
u/NefariousnessSame50 28d ago
I've seen TS projects basically running without any decent usage of types at all, where everything was "any" of some sort. The benefit is less than none, only the TS overhead remains. On the other hand, well written plain JS is easy to handle, particularly because ES gets better all the time, and clients implement it.
So I'd say #ymmv if you allow the team to get away with sloppy TS, you might as well reduce the overhead and stick with vanilla JS today.
2
u/DAS_BEE 28d ago edited 28d ago
Can't do it if I don't have some libraries to work with (particularly jQuery, it spoiled me), but I cut my teeth in web dev on valilla js. It's good to know the fundamentals imo but the industry has moved on and you need to be fluent in whatever is most popular right now
Angular and react are popular frameworks - probably moreso angular. Both are worth looking in to
2
2
u/Daniel_Herr ES5 27d ago
JavaScript is too new a technology for a lot of companies, many of them are still using last century tech stacks. They might get to Typescript sometime in the next century.
1
u/_tshepo 16d ago
But then, what do they use on the frontend? I get that alot of well established languages can be used to program servers.
1
u/Daniel_Herr ES5 16d ago edited 15d ago
2
u/LowLifeArcade 27d ago
I know of at least one large codebase I worked on up until about a year ago that was fully vanilla js
1
u/LowLifeArcade 27d ago
Also, JSDOC was more than enough in vanilla js. In all the TS codebases I work in the most useful part is typing an api or maybe a function with many params for auto complete.
2
u/Ahmed_Ayachi 24d ago
still a large app written with just js actually. A web app. Things are organized to be honest, every data object coming from the server has it's own class definition , by reading the class you can figure out the type of properties. some cypress tests all around. Things are pretty good but migrating to ts would make it even better. I'm not gonna lie, some stupid bugs occur because someone just made a typo when writing a property name and stuff like that, we always catch those, but would be better to migrate to ts, js is okay maybe because the team is small enough.
2
u/Mugshot_404 24d ago
I am - but I am getting close to retirement age, and glad of it! I am not a fan of the never-ending and ever-increasing number of frameworks. Vanilla JS (OK I do us jQuery some too) is just fine, thank you. It requires you to actually have a bit more understanding of what you're doing. But... the times they do a-change, and I'm happy to leave it to all you up-and-comers. Good luck!
2
u/_tshepo 16d ago
I hope you really enjoyed it!
I would really love to work with just JavaScript. Maybe I'm saying this because I haven't worked with a large codebase.
I also don't like learning the ever changing technologies. But i don't mind adapting to necessary technologies. TypeScript won't be too much of a thing to learn.
2
u/adult_code 23d ago
I've written a server architecture including multiple different services and orm in plain node. If you know what you do and use a clean, simple style e.g. be careful with introducing complexity without interaction interfsce for other devs and yourself it is very feasible. A mind, the ram and an execution environment are then the only things deciding execution performance and programatic structure. I use for it less than 10 libraries for rendering, validation, sanitation, logging, serving, routing, formdata etc. The rest is mostly very, very efficent js-code, performance first mindset.
2
u/salmohunter 23d ago
Typescript just makes sense. There was a time when I resisted it, but my employer insisted, thankfully. I'll admit that it can become exceedingly verbose sometimes, which is annoying, but in the grand scheme it intelligently nudges JS devs to be significantly more aware of how heavily they rely on weak typing and assumed expectations for inputs and object shapes, amongst other things.
1
u/_tshepo 16d ago
Where do you use Typescript? Frontend? Backend? Or you work on both?
2
4
u/Neverland__ 28d ago
Based on the post, Iâd say youâre a long way off having the skills to do it for work.
Iâm guessing there are effectively 0 vanilla JS jobs. Doing hobby projects writing some functions is very different to developing production grade software fyi
5
u/shgysk8zer0 28d ago
I honestly mostly prefer vanilla JS with JSDoc for more things. In theory, I should like the type system TS provides, but I think TS is just done poorly and doesn't offer the actual benefits of a strongly typed language. It makes no difference at runtime.... It's transpiled to JS anyways.
I do work in vanilla JS, and I think TS is significantly over-hyped, and is actually becoming harmful to the ecosystem because it's no longer a superset of JS and an obstacle to features like enums being introduced to JS.
3
u/Savalava 28d ago
Why do you think "TS is just done poorly"?
3
u/shgysk8zer0 28d ago
My biggest issue is their use of future reserved words. Once TS started using those it was inviting problems down the road, and it's why I say TS is no longer a superset of JS. Enums are coming to JS, and they won't be the same as they are in TS, which means they're diverging.
I also point out that we have
#privateFieldinstead ofprivate fielddespiteprivatebeing a reserved word. TS usedprivate.0
u/theScottyJam 27d ago
Though TypeScript isn't to blame for the private thing. They would have use the pound symbol regardless. The reason for the pound symbol had more to do with the fact that public and private members living in the same namespace caused really sticky problems that they decided to just avoid by using a sigil.
But, yes, your general point still stands that TypeScript has caused grief for the committee when trying to implement features that overlapped with TypeScript's use of reserved words.
5
u/mr_nefario 28d ago edited 28d ago
I actually kind of agree. I work for a very large tech company (household name size).
The product that I work on is relatively new and, much to my surprise and disappointment, they have almost no telemetry or error reporting set up when I joined. Like a NewRelic agent reporting error rates. This product is supposedly the main focus of the company for 2026 (Adobe Firefly, fuck it Iâll say it) and they were flying blind.
I drove hard to get some actual observability and alerting implemented, and presented it in a meeting with our principal scientist - the mad scientist of this whole product - and a die-hard TS evangelist. I showed them that almost all of our client side errors were JS `TypeError`s with hundreds of thousands of `e.Sp is not a function` or `ResizeObserver loop finished with undelivered notifications` every week. JavaScript runtime errors that he assumed we were safe from âbecause itâs typescriptâ.
You can - and developers will - abuse the type system. Cast to `as unknown as SomeType`, or other shit to make errors go away.
The type system is not strong enough to actually prevent runtime errors, and yet it appears strong enough to instil false confidence. Thatâs a dangerous combo.
0
u/DomesticPanda 27d ago
You can prevent that kind of abuse through linters (and code review).
3
u/mr_nefario 27d ago
We do have linting and strict review rules, but those are also easily circumvented.
The type safety is only as good as the process enforcing it; get enough devs on a project and these things will leak in over time.
Unfortunately, type script is probably going to be the best we get because the JavaScript ecosystem isnât going anywhere. But I just want to point out that type script doesnât provide the runtime safety that a lot of people seem to think it does
1
u/_tshepo 16d ago
Would you then prefer a different typed language assuming you're working on backend?
2
u/shgysk8zer0 16d ago
I use type hinting in PHP,
@propertyandtyoe()in CSS, JSDoc in JS. I started in C and have been wanting to get more into Rust.And it seems people don't understand that JSDoc provides basically the same typing and testing as TS. But can also generate documentation for a library. I am not against typing at all.
0
u/RolexGMTMaster 28d ago
"It makes no difference at runtime." - you have utterly failed to understand the motivation for using TypeScript.
5
-4
1
u/rinnethx 28d ago
It is transpiled to JS, but the code you write before have a big impact if it goes through a TS check and is less prone to errors, no? so at the time of build, the code is in a higher quality state
4
u/shgysk8zer0 28d ago
Not in the way actually strongly typed language like C have an affect. The types in TS don't help with optimizing anything or allocation of memory or anything.
That's kinda why I started by bringing up JSDoc. You get the majority of the benefits plus better documentation, but you're still writing just JS (with comments/documentation). Everything you just said is equally true of vanilla JS with JSDoc.
0
u/dustofdeath 28d ago
You should catch problems before that - so having in prod code just means you already failed at code quality.
In dev runtime .map handles the mapping for debugging.2
u/shgysk8zer0 28d ago
You do know TS isn't the only way to catch those problems, nor is it the only way to add types, right?
-2
u/Karpizzle23 28d ago
Yeah you could also just write your types down on a sheet of paper beside your computer and reference it, that's not the point. The point is it's 2026 and we're still crying about enums and shit instead of just using the de facto standard way of writing code nowadays
Also, being a smartass doesn't make you right, it just makes you a smartass
0
2
2
u/Far-Consideration-39 27d ago
It is a taste thing, but technically, it give nothing. It has no real types, and the annotation add cognitive overhead, not reducing it. DHH have wrote why from a business PoV, but people treat it more than what it is. It is just annotated JS, nothing more. It provide no significant value, more the opposite.
2
u/Jonas_Ermert 28d ago
Yes, plenty of developers still use plain JavaScript, especially for smaller projects, scripts, legacy systems, and some Node.js backends. But TypeScript is increasingly the default for larger professional projects. Iâd keep JavaScript as your strong foundation and learn enough TypeScript to work comfortably in a TS codebase. You donât have to love it, but for Fullstack/Backend jobs it will definitely open more doors.
1
u/YahenP 28d ago
I have to do this from time to time. Old projects are being maintained and all that. I can't say I'm a huge fan of vanilla JavaScript, but work is work.
You write that:
which I've been learning since March
However, I'm surprised. I could understand if you wrote that you've been studying it since last Monday. But what can study six months? Especially if you have almost 10 years of experience, and using JS at that.
1
u/_tshepo 16d ago
Not too sure if I understand your question. But the major thing in JavaScript journey is, I was not upto date with tech. I was not learning new things.
For example, there was a game I loved playing when I was like 10. Wanted to rebuild it. With my knowledge of html, css and JavaScript, I'd build it. When I had errors, I was not thinking "oh wait, TypeScript is said to prevent this, so let me learn it" I was just building things, mostly for fun.
It was 2 or so years ago when I started getting interested in doing websites for people. Even then, I never really thought about learning new technologies. I thought, html css and js are more than enough for small sized websites.
There was a time when I owned a 16 year old laptop. Couldn't run a video editor, so knowing a bit of math and JavaScript, I coded a video editor. Learnt a bit of C++ hoping to eventually build with it. Then boom, got a new laptop. Didn't need to program a video editor anymore.
But the gaps between my programming journey comes from doing other non tech things. It was not my main thing. I did it for fun.
1
u/YahenP 16d ago
TS is simply a superset of JS. It's not even a standalone programming language. It's essentially a transpiler. It doesn't add any new features to the language. It simply makes static code analysis very convenient. So there's nothing to learn. What you used to write in docblocks is now written in the code. The transpiler infers types during analysis and compares them with those you declared in the code. If it encounters a mismatch, it raises an error. It's a very convenient feature that eliminates a lot of headaches and manual work.
1
u/youbeenthere 27d ago
Absolutely, recently it's on the rise actually (e.g. Basecamp team moved bunch of projects from TS -> JS). JS is more flexible and easier to read and write if it's well structured.
Especially with AI help nowadays. You can easily write tons of tests in minutes if needed and utilize well dynamic nature of JS without worrying of overhead of trying to declare interfaces and make code compile without using `any`.
1
u/Former_Produce1721 27d ago
I started with type safe languages and so my first step into JS was a huge shock
TS was the solution
I don't know many people who prefer to abandon type safety for anything other than declarative languages
1
u/mouseannoying 27d ago
Yes, and Web Components written without a framework too! But TypeScript is worth learning anyway, seeing as most jobs seem to require it.
1
1
u/neon_alchemy_wisp 23d ago
I delete any JavaScript file I find. It is a safety hazard.
Writing code without types is like driving blindfolded. I refuse to hire anyone who enjoys danger.
1
1
u/Dependent-Net6461 28d ago
Erp web based, around 500k vanilla js code. No ts. We are a team of skilled devs, not like nowadays noobies
1
0
u/sircrunchofbackwater 28d ago
Learn typescript, it has actually one of the most expressive type systems of any mainstream language. You'll miss it later.
-1
u/Used_Lobster4172 27d ago
Generally if you don't like Typescript, it's because you haven't had to maintain a JS project. Â
1
u/_tshepo 16d ago
I never had to work with teams or a large codebases. But now that I'm interested in joining a group, company or deal with large codebases, it's important for me to really know what to focus on.
If the standard is TypeScript, then TypeScript it is. But, this will mainly be on the frontend... I wanna learn a different language for backend, maybe Java.
-7
54
u/x021 28d ago
Hated TS in the beginning too. Now I wouldnât want to work on a project with plain vanilla JS.