Ask HN: Help, I'm Drowning in JavaScript

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.

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

> 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.