im in a multinational company in a billion dollar industry yet our frontend code is reactjs without typescript, eslint misconfigured, stylelint not used, bad practices on use of react hooks, and many more.
there are teams and devs that are out of touch on maximizing what tools are available out there. im not even saying they are incompetent, what i mean is most are just unable to keep up.
Skill can be taught
having depth in technical skill is maxing out one stat
but there are more stats
- how you communicate, persuade, negotiate, and sell ideas
- how you work with the team, how you navigate office politics
- how you meet your kpi's, how relative your efforts are in capturing business value for the company
sometimes it's not our technical skills that determine our satisfaction and dissatisfaction.
personally i enjoy my technical skills more when i work on my personal projects. pure enjoyment lol.
Considering the code I wrote for work is in private repos, would you have to create an open source project to demonstrate this to future employers?
In interviews you'll be asked about them. If you're not mention them or refer to them in your answers to other questions! Discuss your approach to the design of those projects, considerations, performance tradeoffs, how you approached testing, how deployments were handled etc.
Mention the tools you used that made a big difference - maybe swapping compilers led to faster build times and smaller bundles. Swapping test runners led to improved test times. Maybe you tried to swap test runners and that increased test times and so you went back to the previous one. Maybe you led an effort to automate deployments!
Discussing migrations from old patterns to newer ones demonstrates that you know what good tools are available and you know how to leverage them.
I don't blame them. I hate Typescript. Worked on projects at a major gaming company, no typescript necessary.
However, if the JS build system was actually sane, TS would be the default choice. It's a superset of JS, so saying no typescript necessary is like saying a horse gets me from a to b, no need for cars. TS is objectively better for many use cases and situation if you spend an hour learning it without all the build tooling nonsense getting in the way.
It's equivalent to a company using assembly when they could choose to port to C because assembly gets the job done.
I learned it but never saw the need for the extra overhead.
It's full of these situations. And I'd rather just see less code due to "Attention Economy" issues-- the more things to focus on, the less focus each thing receives. It's easier on the big picture, if there's less things going on. TS has a ton of terms and concepts that I just don't need to make my business logic work.
const cat Cat cat<T Cat> = cat
vs.
const cat = cat
dto? iterface? i can define those without typescript. Just plain objects with comments about what they do and what they are.
Anyway, yep it's just my personal opinion of course.
My opinion is basically... I think in some cases there's a desire to make things overly complex, sometimes even as a way to gate keep--
I'm not saying that's what is happening here.
But sometimes I feel that way about Typescript leaking into all of the Javascript ecosystem.
Ultimately, TS enforces those implicit comments you mentioned and adds some explicitness to the code.
Whatever works for you and gets your job done
But it's worth mentioning, TS with some of the strict settings disabled is basically JS but with some added benefits, primarily due to the TS type checker still being available. No need to go fully in, you can just as easily add explicitness and overhead where necessary and write JS everywhere else to avoid the overhead.
While working with TS in VS Code, I liked the intellisense of TypeScript + VSCode... it was able to piece itself together better than vanilla JS-- it predicted which objects, functions, or files I would reference quite well. So, I'll give it that.
I totally see a reason for it in the corporate realm of developer churn and in the vein of keeping projects very structured and stable. I might give it another go eventually.
For my own projects where I try to keep mental overhead low, and reduce focus on anything over than the main business logic, I prefer plain JS (e.g. within an ExpressJS or ReactJS project)
i despised typescript for years until i tried it again recently. these days the developer tools are better.
prettier now formats it very well. eslint now lints it very well. tsx and ts-node now lets me run my ts files without compile step to js before i can run it with node. on frontend, vitejs has templates for react with typescript projects.
im a performance freak too, i currently use uwebsockets.js instead of express/fastify/hapi/koa. i wrote my own redis client instead of node-redis and ioredis. i fucking hate overhead too, haha.
i think my strongest preference on typescript stems from my frustration on very large projects. say thousands of commits every month, at that scale typescript really helps a lot in catching bugs before we even run our code.