My $0.02 but that is NOT a reason to use JS on the backend. That is an argument to cross-train or hire someone. It's like saying "We only had an expert on building houses made with straw so we chose straw." Because they know the language doesn't mean for one moment that that will make a good background there are so many concepts, services, paradigms and best practices that the language is probably the least of importance other than it should be something solid, robust, and battle tested which I would argue against with most JS backends although some are fairly well understood.

Yea sure, but removing the language as a thing to learn makes it easier to learn concepts needed for programing on the backend. Besides were using Typescript, have automated tests, code reviews and Manual QA, I'm not worried about the code not being solid or robust.

> Besides were using Typescript, have automated tests, code reviews and Manual QA, I'm not worried about the code not being solid or robust.

Oh god...

Yeah, no. None of this stuff is a substitute for actual code quality. Give me a good engineer that refuses to write tests over a mediocre one that does TDD any day.

What kind of "good engineer" refuses to write tests?

I don't write many tests. I've found with experience and heavy linting you can avoid the vast majority of bugs. Not much point to spending a ton of time on tests if they hardly ever break for nontrivial reasons. My normal setup for java is:

Linters: ErrorProne Checkstyle PMD SpotBugs Nullaway

All with highly customized settings

All warnings enabled on javac

Google-java-format to autoformat everything on build.

For runtime analysis: LeakCanary to find memory leaks

Hibernate with interceptors to find long queries

Rest framework or gRPC with interceptors for long calls

Proxied JDBC connector to find long or N+1 queries

Opentracing/Zipkin integration to make debugging crazy stuff easier

NewRelic for projects where the $ makes sense

And I'm always on the lookout for more of these tools. In the long-run they save enormous amounts of time by preventing buggy code and keeping most shitty hacks out of the codebase.

Unlike tests, they don't break constantly and add more maintenance burden to the codebase. And it's less work, one time setup vs ~50% codebase bloat to add tests.

I see project leads call for more tests all the time to "fix" an unreliable codebase where there's zero linting. It won't save you from everything but I swear it's like 95% bug reduction. You should have most/all of these tools in place before you consider writing the first tests

> I've found with experience and heavy linting you can avoid the vast majority of bugs.

No, you can't.

In fact, I can't even begin to see how "apply this specific standard to the code" (linting) is even remotely related to "know everything about this particular domain so you don't make any mistakes in creating an application for it" or "know everything about this particular system so that a given difference in configuration screws up your application at run time".

You seem to be primarily a java developer so I understand why you prefer avoiding tests (among the many things that Java makes absurdly difficult, writing tests is one of them) but you should still write tests .

Look at any serious open source project, most of them have hundreds, thousands of tests. It's almost presumptuous to think that one knows more than the community.

> I swear it's like 95% bug reduction.

The only situation where linting really causes that much of an impact, that I've seen, is in an application where a huge portion of the code was just connecting or boilerplate that should've been brought from third party libraries anyway, and was written only because of the NIH syndrome.

Mind you, having code style is necessary so that any given developer can quickly get up to speed and more easily review other developer's code, but it doesn't (nor it shouldn't) tell you whether whatever you wrote actually works.

Assuming otherwise is like pretending that a movie featuring state of the art special effects, cinematography, etc, isn't still Transformers or similar garbage.

Linting is about so much more than code style and standards. Since we use auto format I have almost all the style checks off. What it does catch is hundreds of different types of potential bugs. Uninitialized variable. Missing null check. Deprecated or beta marked api used. Improper thread synchronization and double locking. Reassignment of parameters. Conditional check that's always true/false. This list is huge, and in my experience it catches mistakes constantly.

For the average crud app, if you're wrong about the requirements the tests will be wrong anyways. It sounds like you're talking more about TDD which IMO is a cargo cult. And I'm hardly the only one with that opinion. Integration tests are important but that's more about running data through the code all at once than testing each function in isolation.

Also, many open source projects get along with hardly any tests. The Linux kernel is probably the best example, but there's tons of popular projects without good or any tests. Check NPM popular repositories, I'll bet you more than half of the top 500 are under 10% code coverage. Tons of huge apps are doing fine without tests, and many I've worked on with tests are still horrible.

I haven't really noticed any contribution from having lots of tests. IMO what's far more important is linting and maintaining code standards. It's hard to write a function that's horrible to debug when the linter limits you to 300 lines. Or a class that's totally incomprehensibly long when the linter limits you to 1000. All of my debugging nightmare projects have been due to lack of sound OOP principles, huge files of spaghetti. Good linting prevents that from happening.

Besides Java my other big language is TypeScript. Using Mockito in java isn't that bad, and JUnit5 or TestNg are decent. Certainly easier than getting tests working in the garbage fire that is Angular6 + Jasmine + Karma.

I don't see how linting and experience prevents logic errors, missed corner cases, or misunderstandings of the requirements. In my experience integration tests are crucial to robust software.

It does nothing for missed requirements, but in my experience the test will be wrong if the requirements are anyways. I don't disagree with integration tests, which are usually just running the software through the motions in a semi automated way. I just think unit tests are pretty useless with good linting.

You might be surprised how much bad logic static analyzers can catch though.

I don't see how unit testing prevents that stuff either. How do you write a unit test for a corner case if you've missed it? If you're aware of it's existence, why not just update the code to handle it?

Quickcheck like libraries are reasonably good at finding missing corner cases in my code. It also helps if the person writing the test is different from the person writing the code and the person writing the requirement.

That's true. Regression tests are also useful.

But TDD is about neither, it's about test-first approach at the unit test level, which is arguably less useful and leads to design by random walk.

I know a couple that would tell me to go jump if I suggested they aim for 90% code coverage on a CRUD app. They also write very clean, maintainable code and do it very, very quickly.

There's always a trade off.

I'm one of those. Unit tests are a waste of time IMO. It usually takes almost as much code to test logic as it does to write it, so I always wondered why the TDD folks don't just implement the code twice and check the result at the end :)

I'm not writing a CRUD app, I'm writing a program that my company expects to put into production. Writing tests is very much a part of writing production code.

If you're in webdev, CRUD apps is probably 95+% of what gets put into production. CRUD isn't meant as pejorative here, it's just most of the things people do with software fits in the model of Create/Read/Update/Delete access to a DB.

?

CRUD apps generally go into production, unless something goes horribly wrong.

I find that beyond this, not having a cognitive disconnect in working on the frontend/backend is really nice. And depending on your data tier(s), can even go there (Mongo, Plv8, etc).

Compared to when I'd have to use ActionScript, JavaScript, VBScript, VB6, T-SQL daily... that was sometimes painful... then adding C# and VB.Net to the mix was ugly having to switch from one area of code to another.

Seriously, not knowing the language shouldn't be a factor in choosing a language.

Just choose the best programming language, and everyone can learn it; and they'll be happy and grateful in the long run that they chose to learn this new language, rather than use whatever they were familiar with.

Moreover, Java is such a simple and an easy language to pick up. If the cruft is too much to deal with, go with Kotlin. An experienced developer could learn either language (Java or Kotlin) easily over a single weekend.

This isn't always a useful way to look at it. For a startup or small team especially, any time spent learning a new programming language is time spent not working on the core product. Yes, you might be better off in the long run using a more foreign programming language, but then again the business might not survive that long if you aren't actually building anything.

Also, it's easy to learn a language's syntax over a weekend, but it generally takes a lot longer to start being productive and writing idiomatic code in a new language, especially if you're also learning a new platform. That's time that you or your team may not have.

As I said above: hire someone new or invest the time to learn the language. Just because someone knows how to make a cute scarf using duct tape, safety scissors, and Elmers glue doesn't mean they should be building your backend driving the company 95 mph with seatbelts, airbags, and a chassis with crumple-zones.

Hiring someone is very time consuming, and requires paying another salary, benefits, etc. Also learning a new language takes time, yes a person can learn the basics of a language in a day or two, but it will be a long time before they are equally proficient with that new language.

You said nothing that wasn't painfully obvious. My point is to build the backend right so you don't have to rewrite it again later. The time investment in the beginning will pay dividends as you scale (unless you are just mocking up or making an MVP)