@Voxera likewise and those were the deps i was talking about, i am currently working on such a project and it is a bit frustrating

@red-knot ig nobody knows how to read the git history anymore, yeah i'm aware how typescript works. i've used it before. he didn't need to put it in there and its an unnecessary dep. typescript does not necessarily mean quality, ive seen bad codebases with typescript. plenty of unnecessary abstractions can be made. anyway i know exactly when and where i would choose to use typescript and most people overuse it, and overstate its marginal benefits

idk man maybe try chatGPT. i mean. it takes awhile to get good or at least translating your ideas into code. you get better at it the more you do it.

@red-knot i don't think you understand my philosophy here. less deps == more reliable faster running code. less code is better and easier to read. typescript is antithetical to that. There are cases where it helps but most cases i deal with i and others who have worked on my projects never complained about it being vanilla js. because i can write less code my development is faster. that doesn't necessarily mean i'm not aware of types. People who know me respect what i'm able to accomplish without using typescript.

@iiii I get things out the door. I'm the person that replaces you when you can't get things done. That's my future in software development

@iiii i highly doubt you were but which part of what i'm saying is wrong?

yeah don't go without git, especially if you go frameworkless, looking through git history really helps understand a codebase even if it was terribly written. i too have written my own php framework and tried to maintain a large vanilla js application and i typed a lot. the only one where i haven't typed alot was svelte.

BEM isn't much better tbh than utility first, what you should focus on is layout first framework like mflx and then use components to have your css scoped to the component. you can write much larger apps that way without polluting your classes. actually using components in a js framework make utility style frameworks bearable. i legit use mflx in all my personal and I've even used it in a client project https://www.npmjs.com/package/mflx

you can also use webcomponents too and the styles are scoped so you don't need BEM

@Voxera youre going to have to coerce the type anyway, after all user input isn't to be trusted. so it doesn't matter you're going to type more to accomplish the same task, and then when you have to add or change it, type even more than i will to get it done. i too have worked on codebases, and quite a few actually that relied on type coersion, not all of them were good i will admit, but i've worked on such projects that were thousands of lines long and i myself have maintained js code without a framework for thousands of lines. my last project that didn't use typescript was a pain only because we were doing number crunching on the frontend thus the components were filled with parseInt and parseFloat to keep things working smoothly. didn't really run into perf issues. but we were also using vue so. idk at what scale you think this matters but i've yet to see what you describe, and i've only worked with 4 at once and never really had any major issues save for one project

well. i do prefer to manage my own servers and i hate typescript. don't come crying to me when your aws service gets shutdown because a company didn't like your companies politics. you are part of the developer groupThink and don't trust your own opinion on things. I learn things i hate for money, not because they are objectively good like you think they are.

Its called TypeScript because you Type more

i think @CoreFusionX has the right answer but like. honestly why are you worried about that? just build it, unless you are actively using peoples data and you have significant traffic don't worry about it

@Voxera literally all you need is map, reduce and filter, potentially other array functions for doing things like dom diffing, and place your conditions to check for types using typeof. you don't need typescript for this. I can see the argument of perhaps enforcing a sort of intermediary schema to be received or sent for each object however in a lot of cases this is also unecessary. and my projects last longer than a week, i don't understand where you get the idea that software is fragile unless you have a million deps in your project, which would make sense considering you need to have @ts version for all your packages.

@Oktokolo uh yes it does. you already know the type will probably a string, within an object property especially if you pulled it from form data. and in most cases when building software you don't need to check for numbers. maybe you're doing reliability engineering, and accounting for a .1 percent case it won't be. but if you simply pull in ts in every project you are committing the sin of over engineering. know what data you're dealing with, and deal with it accordingly, js already give you tools to enforce types if you want to, and you need it in fewer cases than you think.

@atheist abstraction breakage? what are you talking about? yeah you only need to work with strings in most cases. there are very few cases unless you are doing number crunching where you need types, if you're returning functions or any other data type most of your needs can be handled with typeof, or parseInt or Float and you only need to do it in a couple places depending on the project. the one instance i wish i had type script was when i was doing a stock ticker application where we basically ran calculations on string data, and even then there was one instance where type conversion was really handy. for example comparing js time strings works based on how js does math on strings. having typechecking would have made that project go a lot faster.

@Crost for example, you may get a linting error that says "undefined variable getrequest on line 98" and you might be like "wtf getRequest exists and i defined it" OH its GetRequest, not getrequest.

oh lol check this out.

https://npmjs.com/package/...

@Crost eslint has caught misspellings and missing semi-colons especially if you enforce style that deffo helps with code quality.

@Crost you should use a linter then. i recommend you and your team use eslint

@Oktokolo depends on the type of data you are recieving on the json right? if you're not doing a bunch of number crunching you don't need typescript. you're going to be receiving string data from users, most likely, and it will be in a json object or some other similar format. if you're recieving things like telemetry data from a rocket or weather balloon, then yeah you might want to use a language with types otherwise your code will be polluted with parseFloat or parseInt

@Crost idk man, i've been told i'm a faster dev by those who really like typescript. less code == less mistakes. easier to read. easier to maintain. you don't need to know the types in web development unless you're working with data that requires it, and in many cases you don't. and if you do its not the main basis of the application, or you can pass it off to a language thats better at such things like php or python. node.js is probably the only place typescript should be

@red-knot no you just coerce the types as you need them, you use parseInt() or typeof in your functions if you absolutely need them. typescript only serves to make projects bigger and harder to make progress on, you should be typing less code rather than more code. also you should use a linter, and misspellings are a thing of the past.

That's your cue to find another job that pays better. sounds like he hates to admit it but he's going to either pay more now or later, losing devs costs money, and onboarding new ones are expensive depending on the project. if you're really feeling confident and have another job potentially lined up, ask him how much it will cost to hire a new dev. if he says not much the project and him weren't worth working on in the first place. if its a decent chunk then you can negotiate a bit and call his bluff.