Ask HN: Help, I'm Drowning in JavaScript

Accept that your understanding of JavaScript is outdated. Appreciate you have at least some experience though.

If you care to learn modern JavaScript, which you should, check out Eloquent JavaScript [0]. It’s a free web-based ebook providing an introduction to modern JavaScript.

Also, stop with the negative narrative. You are overwhelmed, not helpless. Instead of telling yourself you don’t understand code and giving up, just Google said code. It’s easier than ever. In a few weeks, you won’t need to reach for Google. If you encounter a dependency you don’t understand, try to find some documentation.

Accept that there are black boxes that “just work” despite being deprecated or lacking documentation.

Your job is not to learn the history of JavaScript and how it evolved from your understanding. Your job is to get up to speed with modern JavaScript enough to make functional programs to solve the business’ needs.

0: https://eloquentjavascript.net/

OP follow this advice, that's the best learning resource for modern JS.

The #1 thing you can do for yourself first though is accepting that what you learned 20 years ago probably means dick. JS has radically changed and that's OK. Go into this book with that mindset and you will come out a champ.

After completion of Eloquent JavaScript and a decent comfort level with modern JS, is there an equally great resource to then transition into TypeScript?

Typescript docs are good [0], and it's incredibly easy to pick up, since it's just javascript with type annotations.

[0]: https://www.typescriptlang.org/docs/

> Accept that there are black boxes that “just work”

This is pretty integral to my job and I’ve been in the industry for 11 years or so. You can’t know everything right away and it’s overwhelming to try to attempt to do so. Learning certain parts has its time. For now just focus on what is in front of you.

“Method X produces Y and that’s what I need” next step.

PS. It's fine to stay old-school (until it finally isn't, but that's decades...)

https://news.ycombinator.com/item?id=31660869

Ask HN: Best alternative jobs for “outdated” skills with small websites/apps?

> you should be applying at small to medium-sized companies that are not tech companies. There's a ton of work in these companies and hiring is more focused on solving business problems

Hey, it's okay. I was in your exact boat a few years ago. Javascript has exploded in popularity in just a few years and yes, the ecosystem is horribly complex. It's an running gag even among full time JS devs how crazy it's gotten. None of us can keep up.

It's OK. Just tackle it one step at a time. Forget Typescript for now. Don't use third party libraries until you need them. Arrow functions are optional. Ternaries are a form of jargon/an optional shortcut.

If the other developer's code is too hard to read, that's okay, set it aside for now and you can come back to it when you have a little more experience.

Start with the problem you're actually trying to solve (which isn't terribly clear, sorry). You have XML and HTML you're trying to parse? Which is it? (XML will be much easier than HTML, because it's much stricter. HTML is notoriously loose, which is why there is only like three real browsers in the world.) What are you trying to do with the parsed input?

Regex probably isn't the best tool to use here. There are specialized parsers for these data formats that we can help you use, if we better understood your needs.

Ask. Ask a lot. Find a mentor if you can. Ask on Stack Overflow if you can't. It's totally okay. Modern JS is a new and exploding field and we're all pretty ignorant about it. Fortunately, 80% of it is relatively easy to learn, and the remaining 20% you can usually ignore or work around. Just take it one step at a time... it's not you. It really just is a chaotic ecosystem.

Oh, and LinkedIn Learning is really excellent, if you want to learn the basics from an actual guided course. Very much worth it, and helped me go from casual vanilla JS to the more complex systems.

Thanks for the kind words. Slowly going into the water is my approach as well, but sometimes it just gets to me. My learning projects die on the hill, because of the frustration I have on the job with these techniques. Plus, overwhelming ecosystem.

About my regex problem: This is a structual mess. JSON/XML with HTML code in the data fields. We process them and send them to multiple job boards. Our clients mainly use HRM software or some CMS, some of which are only able to spit out whatever HTML is displayed on their career sites. This code often does not even have classes or IDs. Most of the times we are dangling together whatever is between two headlines, praying those won't change. But they do, because the recruiters put fields, where they not belong. I call myself code cleaner, not web dev nowadays. We are not able to use APIs, because the receiving job boards either don't offer one, the client doesn't, or it's just not worth it financially.

I will take a step back and reevaluate my situation.

I spent a decade parsing text-with-angle-brackets with regexes, and it sucks. It’s always tempting to try an html parser but if the code is written by a human (or worse, a mixture of human and machine, especially if the machine involves MS Word) it just doesn’t work.

I’d suggest rather than attempting to do big regexes that capture a bunch of stuff in one call, break it down to a bunch of smaller, more targeted calls - one call to capture the text of the whole record, another with 3 variants to get the title, another with 2 variants to pick up a tag line, etc.

Essentially, this is what I do. First matching with a broader regex ruleset, working down to next one and so on and so forth. But with more complexity of code comes more breakage down the line. I went in full maze mode yesterday and questioned everything after thtat, so this is what my sanity looked like this morning.

Regex isn't really the problem though (even though it technically should also not be the solution in this case, but I cannot dictate the techstack). It was just the last drop on my frustration with the situation and myself not being able to do, what my colleague does, even though I want to. I felt the need for help, and I got it. Awesome community around here.

Thank you for the context! What you're doing is actually much harder than regular web dev. It's a specialized kind of data processing, often called a "extract, transform, load" (ETL) workflow.

Most web devs don't need to do that, and that you're willing to tackle it at all just shows how willing to learn you are, despite the frustration.

If you hate this situation, it's totally understandable lol. That kind of work has all the tedium of dealing with someone else's arcane data format, and none of the joy of seeing your creativity come to life. Some people love that sort of work, and specialize in it, becoming backend people or DB engineers or data scientists or the such, but it's not usually what web devs are known for (who tend to focus instead on UIs and some level of design and interactive stateful apps). Nothing wrong if ETL just isn't your cup of tea. I'd go crazy if I had to do that often, too.

Anyhow, if I'm understanding you right, you have HTML embedded in either JSON and/or XML. Do you know what "escaping" is in the text embedding sense? Like if you have quotes inside quotes, or tag brackets inside tags, how to separate each layer of embedding? If your JSON and XML files are cleanly escaped, you should be able to (as a first step) just iterate through the files and get the HTML parts out (without regex).

Like if the HTML is just a data string inside JSON, you can transform the JSON into an array of HTML strings using array.map() or object.values.map().

In the XML, if the HTML is stored in CDATA fields, you can access it using an "XPath" selector... you know how CSS has selectors that let you say headings should be styled one way, paragraphs another? XML has its own selector language that lets you directly target a certain node inside the document, without using regex, by specifying the hierarchical path that takes you there (like a CDATA inside a description inside a job inside a company, or whatever). Although there is a learning curve to XPath, it is much more suited to the task than regex, because the regex can't easily account for the complexity within XML (especially when there's nested layers).

It would help if you can post some example snippets, but that might be better suited for Stack than HN (though feel free to link to it here).

Once you have the HTML out, then you can run it through a sanitizer -- that's an optional step, but would let you strip out unnecessary divs, old font tags, whatever, keeping old basic formatting (headers, paragraphs, links, bold, etc.) which should be much cleaner to hand off to your clients. That would be much easier to embed on someone else's site vs a scraped page with all the HTML mess from someone else's framework.

I know there is a lot of complexity in each of those steps, but there are great tools and documentation for each step of the way. That's just to get you started.

At the end of the day what you're doing isn't really a Javascript issue at all, it's just a different kind of work that Javascript happens to be able to handle if you really need it to (but so can Python or Java or specialized command line tools like jq). It's a different body of work, which is why your casual web dev skills aren't providing easy answers. It's OK! You can learn it once and make it work (and then decide never to do that again, like I did lol). Or switch tracks, totally up to you :)

But feel free to ask here or on Stack if you have followups!

You are much appreciated. I didn't even know there is term for this part of my work.

Down the line, we do everything you cautiously described. We extract single fields with pointers (in lack of a better term, english is not my main language) to the XML/JSON fields we like to extract. Our software then lets us use JS snippets to manipulate the contents. Problem is, once you define a rule, it may get 80-90% over hundreds of datasets. But breakage is not an option most of the time. It's pareto principle work: 80% in 20% of the time, 20% work in 80% of the time. In the end, they are just snippets, then a giant gap, then the projects my colleague does.

I get where you are coming from, regarding "never to do that again". This not the only work I do. I also build HTML from customer demands, many of which are pdfs meant for print use, but not for the web. I like it, but I only scratch the surface of what might be. Thanks to the resources in this thread, I have a good insight of what to come. So, thanks again.

You should check out the free online ebook series You Don't Know JS [0].

Go straight to the last book in the series, called "ES6 & Beyond" [1] which specifically covers the most important features of JavaScript that have appeared since you last worked with it.

For hands on practice with newer JS features, the best resource is Execute Program's "Modern JavaScript" [2] course. Once you work through that, move on to their TypeScript Basics course [3]. Both are amazing. Execute Program is the best tool for learning a programming language that I've ever used.

[0]: https://github.com/getify/You-Dont-Know-JS/blob/1st-ed/READM...

[1]: https://github.com/getify/You-Dont-Know-JS/blob/1st-ed/es6%2...

[2]: https://www.executeprogram.com/courses/modern-javascript

[3]: https://www.executeprogram.com/courses/typescript-basics

You can learn ternary operators and arrow functions. I feel that you may be overwhelmed because you're trying to learn so much at one time. I've been in your shoes. If you keep trying, you will improve. Something I've done in the past is to write down everything I don't understand, and just chip away at that list daily by reading documentation and learning new things. Don't try to learn them all in one day.

Seconding this. It’s easy to be overwhelmed by the seeming combinatorial complexity of things. Just start a little personal wiki (eg, arrow syntax, structural typing, etc) and it’ll help you decompose things into more easily understandable pieces (it’s easier to multiply 7x5x21x22 than to factor 16170, if that makes sense).

It does and it sets a good perspective on the problem at hand. Thank you.

Thanks, I just needed the hint to take a step back and reevaluate.

Having a wiki is a good tip, I already have started to maintain a small database with snippets I use often. But it's just that. My next focus will be having a project which does not have to many features. Baby steps it is.

You can do it. It's normal to feel overwhelmed. I was in that position once but I really had no choice, I had to press forward or starve, so I eventually made it through.

How to eat an elephant? One bite at a time. JavaScript is fairly complex language and skipping a few parts in foundation can lead to not understanding the rest of it. You also mentioned regex,which is a whole separate piece to learn.

Here's what I suggest:

1) Get the language basics really well.Like really well.

2) Move on to more complex concepts,again don't skim read, but do again and again and again.

3) learning from code written by a more experienced colleague may not be the best option. He may have a certain style, approach and etc. If you can't understand the code , you won't learn much from it.

4) Get yourself all ' you don't know JS' series and devour it. The books aren't easy read if you really try to understand the concepts but way better than some random guy on YouTube covering the subject in 2 min video.

5) I've recently did a private job with Regex,which I barely know. It was painful.. but it gets easier. Again, start with basics and build up, instead of trying to run complex queries and not fully understanding them.

6) Be methodical. Don't jump from one tutorial to another,from one book to another. Read one book,do all the exercises, only then move to something else.

P.S: Regexing HTML is by far the worst thing a dev could get to do, that's why most would advise against it. Don't be hard on yourself.

Good luck!

Don't panic! Do not despair! Solve it like any big problem: you split it into smaller, managable chunks and tackle them systematically, one by one.

For the syntax thing you might wanna pick out one particularily "bad" one and have your collegue explain it to you. Takes him maybe 15 mins and will safe you a good chunk of time. Where I work asking is expected. I ask our Network/Linix guru for things all the time. He asks me as well when I use something he does not know. Pretending to know everything won't get anybody ahead.

As for the regex hell: I always found tools that visualize the matches in realtime useful (like this: https://projects.verou.me/regexplained/). Just make sure the flavour of regex matches yours.

Edit: I suspect your collegue relies heavily on ES6 syntax (as I would). A overview of that can be found here: https://www.w3schools.com/Js/js_es6.asp

Make sure to give yourself a little time to play, e.g. try to replace something where you would use a for loop with an Array.forEach loop or something like that.

You are right, but me and my colleague are limited on time unfortunately, because there is so much work to do. I already asked him, if he could include me in his next project, just to watch, what he is doing from the boilerplate up. Maybe this clears out some of the question marks. And thank you for the resources. I already use regexr.com for visualisation, but this seems better for learning.

I'm sort of in the same boat, but I'll tell you what's been helping me keep my sanity:

The debugger is your friend. Figure out how to get it attached anywhere if you haven't already.

That means running node with --inspect-brk=<port number> that also means figuring out where spawns are.

This exercise will greatly aid you in overcoming any surprising control flow going on by allowing you to single step the program. JS is one of those languages I just have to cling to my debugger in.

Two: node has two "ClassLoaders"(CommonJS/ESM). They don't mention squat about the differences between them until the middle of the nodejs documentation.

Start learning dependencies one by one. There's really no other way around it.

Avoid using regex for XML/HTML. Try something more akin to SAX parsers. Seriously. There:s way too much pain in doing regex XML processing. You could literally rewrite the damn thing in java faster than getting a shoddy, flaky JS monstrosity reliable.

God help you if they're doing weird Async/Event nonsense.

Keep cracking at it, but be aware, I think JS has broken my brain, because I just don't even like programming anymore since I started dealing with the language and all the necessary tranpilation/toolchains.

You're not alone - it's nuts how much JS has changed over the last decade.

I don't know if I can offer any suggestions beyond just Googling syntax you don't understand and experimenting with it until you feel you understand it. From there it just a matter of time before you can glance your eye over the code and understand what it's doing without needing to decipher every line. I just want to say you're not alone. I think most frontend devs have gone through something similar at some point over the last decade - I know I have.

As for deprecated dependencies, that's a huge problem. Senior devs generally do care and will be selective around dependencies. One of the problems is that the ecosystem is evolving so quickly. Libraries come into and out of fashion almost over night so frequent maintenance is needed to keep dependencies up to date. My guess is that either devs are not putting enough thought into what dependencies they're using, or your not currently assigning enough time as a team to review & maintain your existing dependencies - this is definitely something worth raising with your team imo.

The last thing I'll say is that the use of ternary operators are something I'm very critical of and it's interesting that you mentioned them in your post. A lot of devs seem to have this mindset that if you can convert 5 lines of code to 1 or 2 that's always a good thing, but compressing 5 lines of code to 2 often comes at the cost of clarity and readability. It sounds like you might need to think about coding standards with your team. Is part of the problem here that the team is writing confusing / messy code, and it's that coupled with your lack of knowledge of modern JS that's resulting in the stress you're feeling here?

I can see how it can be overwhelming, as with everything the beginning is the hardest but it will get easier over time. Seeing a ternary the tenth time will be much easier than the first.

I would look for the old-ish articles and tutorials that introduce es6, for example: https://babeljs.io/docs/en/learn/ idk if you need to go earlier, but surely there are tons of articles on each update to the language.

I think it's good to realize most of it is not new, it's largely the same stuff, just slightly different and more convenient.

> I do not understand his code

I believe that's your main problem. You are seeing a foreign language kinda close to what you know and expect to understand it right away (while it's the same "Javascript", using different writing ways is more akin to another dialect). It takes a bit of time and practice to familiarize yourself with it. Try to decompose it until you become fluent. When you learned to read, you would read a word one letter at a time. Do the same: read the code one operator at a time, until you understand what's going on and how they work together.

For example, a ternary is just a compressed if/else with a different syntax. An arrow function is just an inline function with a different syntax. etc...

> I do not get Typescript

Typescript is Javascript with type safety. In Javascript, if you pass a number to something that expects a string, it will convert without any complaint. Typescript will complain that it's the wrong type. You can go much further than this with complex types that have to be passed correctly.

> thousands of dependencies, while nobody cares, that 20 to 100 of them are deprecated

Some people care, but for most dev, it's a black box that just works. It's frankly not something to worry about when starting.

> I do not understand, how this whole eco system works

If I had to sum it up, it would be building on the shoulders of giants, over and over again, at a break-neck speed, valuing improvements over backward-compatibility. I'm personally not a fan of it, but that's how it is.

to sum it up our dude here wasnt properly onboarded on the tech stack the team uses before he is given any tasks.

The journey ahead will be long but it's totally manageable if you put in the hours. First and foremost the whole situation gave you a glimpse of some of the things that are out there. It may lead you to more interesting and challenging work.

Nowadays the Internet is literally drowned in resources and you may quickly feel overwhelmed by everything. The trick here is to choose only a handful and stick with them for the time being.

Some of my personal favorites for starting out are https://www.freecodecamp.org/ to get your feet wet and up to speed with JS. You will build projects and explore some of the fancier syntax you saw.

You may also want to start building a strong CS foundation at some point. This is going to be really beneficial as you move forward. Arguably one the best (and completely free) resources for starting out is CS50 - https://cs50.harvard.edu/x/2022/.

Also don't follow courses blindly, take notes and try to implement things yourself. Moreover, start tinkering with some projects as soon as possible.

Good luck.

You are right about node dependencies. It would be good to think someone is trying to get on top of it. Maybe someone here knows?

MDN is a very reliable source of reference for all of JavaScript.

https://developer.mozilla.org/en-US/docs/Web/JavaScript

You can't parse [X]HTML with regex. Because HTML can't be parsed by regex. Regex is not a tool that can be used to correctly parse HTML. As I have answered in HTML-and-regex questions here so many times before, the use of regex will not allow you to consume HTML. Regular expressions are a tool that is insufficiently sophisticated to understand the constructs employed by HTML. HTML is not a regular language and hence cannot be parsed by regular expressions. Regex queries are not equipped to break down HTML into its meaningful parts. so many times but it is not getting to me. Even enhanced irregular regular expressions as used by Perl are not up to the task of parsing HTML. You will never make me crack. HTML is a language of sufficient complexity that it cannot be parsed by regular expressions. Even Jon Skeet cannot parse HTML using regular expressions. Every time you attempt to parse HTML with regular expressions, the unholy child weeps the blood of virgins, and Russian hackers pwn your webapp. Parsing HTML with regex summons tainted souls into the realm of the living. HTML and regex go together like love, marriage, and ritual infanticide. The <center> cannot hold it is too late. The force of regex and HTML together in the same conceptual space will destroy your mind like so much watery putty. If you parse HTML with regex you are giving in to Them and their blasphemous ways which doom us all to inhuman toil for the One whose Name cannot be expressed in the Basic Multilingual Plane, he comes. HTML-plus-regexp will liquify the n erves of the sentient whilst you observe, your psyche withering in the onslaught of horror. Rege̿̔̉x-based HTML parsers are the cancer that is killing StackOverflow it is too late it is too late we cannot be saved the transgression of a chi͡ld ensures regex will consume all living tissue (except for HTML which it cannot, as previously prophesied) dear lord help us how can anyone survive this scourge using regex to parse HTML has doomed humanity to an eternity of dread torture and security holes using regex as a tool to process HTML establishes a breach between this world and the dread realm of c͒ͪo͛ͫrrupt entities (like SGML entities, but more corrupt) a mere glimpse of the world of reg ex parsers for HTML will ins tantly transport a programmer's consciousness into a world of ceaseless screaming, he comes, the pestilent slithy regex-infection wil l devour your HT ML parser, application and existence for all time like Visual Basic only worse he comes he comes do not fi ght he com̡e̶s, ̕h̵i s un̨ho͞ly radiańcé destro҉ying all enli̍̈́̂̈́ghtenment, HTML tags lea͠ki̧n͘g fr̶ǫm ̡yo ͟ur eye͢s̸ ̛l̕ik͏e liq uid pain, the song of re̸gular exp ression parsing will exti nguish the voices of mor tal man from the sp here I can see it can you see ̲͚̖͔̙î̩́t̲͎̩̱͔́̋̀ it is beautiful t he final snuffing of the lie s of Man ALL IS LOŚ͖̩͇̗̪̏̈́T ALL I S LOST the pon̷y he comes he c̶̮omes he comes the ich or permeates all MY FACE MY FACE ᵒh god no NO NOO̼O O NΘ stop the an *̶͑̾̾ ̅ͫ͏̙̤g͇̫͛͆̾ͫ̑͆l͖͉̗̩̳̟̍ͫͥͨe̠̅s ͎a̧͈͖r̽̾̈́͒͑e n ot rè̑ͧ̌aͨl̘̝̙̃ͤ͂̾̆ ZA̡͊͠͝LGΌ ISͮ̂҉̯͈͕̹̘̱ TO͇̹̺ͅƝ̴ȳ̳ TH̘Ë͖́̉ ͠P̯͍̭O̚ N̐Y̡ H̸̡̪̯ͨ͊̽̅̾̎Ȩ̬̩̾͛ͪ̈́̀́͘ ̶̧̨̱̹̭̯ͧ̾ͬC̷̙̲̝͖ͭ̏ͥͮ͟Oͮ͏̮̪̝͍M̲̖͊̒ͪͩͬ̚̚͜Ȇ̴̟̟͙̞ͩ͌͝S̨̥̫͎̭ͯ̿̔̀ͅ

Have you tried using an XML parser instead?

- https://stackoverflow.com/a/1732454

With that aside, for parsing HTML with node, use cheerio. It has a jQuery-style API and IIRC is more lightweight than jsdom (which is what I'd suggest if cheerio isn't enough). If you're parsing HTML in a browser, you don't need any libraries, use a DOMParser. Arrow functions are just normal functions but with `this` automatically bound to the `this` of the scope they are in. MDN is your friend.

WTF, dude?

I can’t even parse that enough to decide if it should get an up or down vote and I haven’t even tried regex.

WDYM WTF? He's clearly telling you that you can't parse HTML with regex. Don't even try.

s/He/She/

This was the answer I was hoping to see with regards to OP's current troubles. Thank you.

This looks like copy pasta, I swear I've seen this before.

EDIT: I see

Stop using regular expressions. Honestly, it sounds like you were having trouble with that, and blamed JavaScript.

Regular expressions are the worst.

Also if someone scraped web pages and then stored the HTML, that seems like a bad idea. You would want to actually extract the data at that point.

Also regular expressions are the worst way to extract data from HTML.

I think the real problem is the business model and technical approach. It almost sounds like you are scraping a massive number of websites using regexes, which is guaranteed to break somewhere on an almost daily basis since developers change the HTML and regexes are very brittle.

You are probably taking advantage of a lot of other people's work, possibly quite a bit of it copyrighted and certainly most of it NOT curated with the idea of some other company profiting off of it.

So you deserve your pain.

But don't blame JavaScript or lack of familiarity with new versions when it's all of your other life choices that are the real problem.

I would store the HTML as well for later purposes / hoarding

It looks like you’re lacking some fundamentals.

And not if/else type of, but rather oop, software design and organization of code kind of things.

What will help is to master a single decent beginners course that focuses on applying fundamentals to building practical projects. And it’s better to be python or ruby based course (to minimize friction and infra pain).

Don’t jump on anything else until you finished and have some coherent picture.

Only then you should proceed with learning other concepts bit by bit.

Js world looks complicated for beginners because of a diversity of tools and techniques like bundling, transpiling etc.

It is not easy to comprehend and it is not necessary, you just focus on your specific goals and moving from a goal to another goal you gradually build holistic picture.

You don’t just “get” Typescript etc. Im still learning typescript after 2 years professionally working with it.

I can agree on the fundamentals, even though I took OOP and CS in college, but that was a long time ago and not my main field of study. I find it hard to apply to JS though, as you said, it is not easy to comprehend.

Are you suggesting a different technology stack for the fundamentals? Others seem to go the same way, but they are suggesting it within the ecosystem of JS, just not with the overhead of the new technologies.

> Are you suggesting a different technology stack for the fundamentals?

It's not that important in general. But I assumed that if you're already overwhelmed by JS infra, you might get a smoother initial experience with less messy yet still interpreted dynamic language like ruby.

Maybe take a step back and look at foundational topics such as higher order programming. Then you can take this foundational knowledge and apply and use it in any programming language and not be surprised when you come across it.

The ternary operator is born out of the need for an expression form of if-else. Some languages have if-else already implemented as an expression so they don't need a ternary operator.

Typescript exists to provide a static-typing discipline to javascript, if you don't care about this obviously you won't see the importance of typescript.

I think Javascript environment encourages this behavior.

From day 0, a javascript project starts as a goal driven project of finishing things. Write hacky code for now we will figure them down the road. From that point on the hacks keep piling on top of hacks.

Another issue is "syntax overload". Javascript allows for doing one thing ten different way. So keep doing things your own way as long as you don't have to review other people's code. The new things JS brings out doesn't bring significant syntactical improvement and yet adds to the syntax overload syndrome.

Oh, god, please stop abusing yourself. Stop using bad tools for the job of manipulating XML/JSON and start using a tool designed for the task: Saxon XSLT. It comes in Java, .Net, and JS forms.

https://www.saxonica.com/

XPath/XSLT3/Xquery are full-fledged functional programming languages that specialize in querying and transforming tree data structures. They make it so easy to work with XML and JSON. You don’t have to hurt yourself using the wrong tools!

I just read https://insanecoding.blogspot.com/2009/11/they-actually-want... and didnt believe it. Turns out its true :o

You are very lucky nobody at your company caught on yet. My suggestion is hire me as a subcontractor - I will do your job for half your wage, you will have plenty of spare time to do whatever.

Plug in unknown syntax into https://babeljs.io/repl/ or https://www.typescriptlang.org/play and it will convert it to vanilla JavaScript.

knowing difference between es5 es6 es2017 es2018 and so on

knowing the internal modules of nodejs such as fs, events, process, streams

knowing utility modules like lodash, asyncjs, rxjs

these could help.

but the fact is if your workmate is writing unreadable and unmaintainable code, hes the problem, not you.

you need linters, code conducts, test sequences, dependency upgrade schedules, node runtime update schedules, things like that.

i once left a high paying job because a colleague there is code golfing on our code. the team suffered more when i left lol.

in life choose your battles, dont stick with a shitty one. when applying for work, it is not just you applying for their company, it is you screening if their tech stack and coding practices is the right fit for you. screen hard.

>> My problem: I do not understand his code.

> but the fact is if your workmate is writing unreadable and unmaintainable code, hes the problem, not you.

That's a stretch, especially since OP also says:

> Or anyone elses.

Idiomatic new js/typescript is a completely different beast from old javascript. For all intents and purposes, it's a different language entirely. No one would be expected to pick it up in a minute. Sounds to me like this guy has decades old knowledge and doesn't know where to learn the new stuff, since the target is moving from one year to the next.

You yourself are suggesting today, that he learns libraries that are no longer necessary, like lodash.

You could try to learn modern JavaScript/TypeScript as if it was a complete new programming environment you don’t know about. Which is a bit the case from what I can read.

A bit like learning Golang when you know C99.

I would highly recommend learning FP fundamentals in another language, not Javascript.

For example, there is an excellent introductory FP course on Coursera by Martin Odersky ("Functional Programming Principles in Scala"). It happens to be based on the Scala language syntax, but most of what you learn there will be directly applicable in other FP languages too. For me, taking this course was a game changer ~10 years ago. Highly recommended.

Once you understand the basics, picking up stuff like "arrow functions" (lambdas) will be just a matter of adjusting to the JS syntax.

Never forget: The original version of Javascript was written in 10 days.

Javascript is a mess, especially at smaller shops which may face pressures to ship projects to a client that work, regardless of the state of the code.

Breathe. You're overwhelmed and that's ok. Just take it day at a time, line at a time and don't be afraid to have to google the same thing over and over again. It eventually sticks.

Don't be afraid to ask for help after you've exhausted yourself trying to solve something. Lots of other great advice in this post too. You'll get there.

Write some Greasemonkey/Tampermonkey scripts as a hobby and forget Node, and insecure npm. Forget $frameworkOfTheWeek and just hack.

> While I basically use if/else, he uses ternary operators. I write functions by hand, the uses arrow functions and symbols I can hardly understand.

What you are describing is commonly known as ES6 or ES2015 syntax. The language got some features at that time that solve gotchas related to using JS and arrow functions are a great example. These features make JavaScript easier to work with if you use them, and learning the most important ones doesn't take more than a day. https://www.boardinfinity.com/blog/top-10-features-of-es6/ After 20165, they only released like 2 features per year, and most of those haven't had the same adoption.

Arrow functions are a great example, as they don't have their own `this` and it makes the `this` keyword work how you think it should.

> ternary operators vs if/else

Sometimes new features make sense in a certain context. If/else makes sense if your code has actual branching, but if the assignment of a single variable is all you need to branch for, ternaries are great.

``` // classic JS let variable;

if (someCondition) { variable = 'foo'; } else { variable = 'bar'; }

// with ternary

const variable = someCondition ? 'foo' : 'bar'; ```

> We do not have the time to code review his projects.

That's crazy.

Ternaries are also a great example of a feature that can be abused. As conditions get more complex, ternaries become more opaque and are a worse choice. More concise code isn't necessarily better. This can be true for a lot of JS. Fancier code isn't better if the rest of the team can't understand it, and if you don't have a review system, you can't blame him for writing in his own accent and you not being able to understand. Developers on a team need oversight. I catch bugs my teammates write, and they do for me too. If you can't understand it when the PR is made, you're not going to understand it later.

So my answer to you is to try to start doing code review. Reading code is important, and a PR should be focused enough that you can track what a feature or bugfix is actually doing. If you can't, you should be speaking up.

> Also, he should not be my teacher.

Why not? What dev wants their teammates to struggle? I love helping more jr developers, and I've never had someone on any team bristle when I asked them to help me.

Try transpiling to earlier js (ES) https://www.tutorialspoint.com/babeljs/babeljs_transpile_es6... Or transpiling TS to JS https://transform.tools/typescript-to-javascript

So natural... as it's the most dynamic PL over the others