How I Structure My JavaScript File

Antonin Januska on April 06, 2018

Originally posted on my blog Loads of people have been asking me how I write my JavaScript — okay, that’s a lie, no one asks me that but if they... [Read Full]
markdown guide

Great ideas/advice, I like this way of organizing it!

Personally I'm still not completely decided on the semicolons, but I now tend to go with whatever the consensus is within a certain framework/community, so as to stay at least consistent within that context.

For instance, the Vue.js community has a (strong) tendency to omit semicolons, so I omit them when writing Vue code. Then on the backend (e.g. Express or Feathers) I'll probably add the semicolons because folks tend to use them there.


I think that's the way to go with semicolons and code-styles in general. But if I have a choice, I stick to them. I had no idea that Vue was against semicolons. I think just like the browser automatically inserts them where they should be, so do I when I read code haha.


Yes, technically it doesn't matter, the JS compiler will insert them for you ... it's a matter of taste but people in the JS world make a big deal about it (as you probably know).

The creator of Vue (Evan You) is strongly "anti semicolon" so Vue code that people write almost never has semicolons. Most node.js code (backend) has them but even there I see it applied inconsistently. React programmers sometimes use them and sometimes don't.

I just go with the flow and with whatever people use. I think the sort of structure for a javascript like you described is more useful than the whole semicolon discussion.

I had no idea Evan had that preference haha. I've used Vue since version 0.10 or 0.0.10 or something like that, very early version. I never noticed the lack of semicolons so I bet my Vue code would look horrendous to Vue programmers haha.

But yeah, this is why I added the semicolon thing all the way at the end, it's not really important, just a personal preference. To me, a semicolon is like a period at the end of a sentence so I feel the need to add it.

As you can imagine, when I write Go, the compiler constantly screams at me.

I first met a semicolon-less fan when doing a React project, he had a strong opinion about everything, not just about semicolons ... I have to say that when you follow a certain style (without the semicolons), JS almost starts looking a bit like Ruby, kind of nice. But I'm in no way religious about it, on the contrary (opportunistic).


I’m not entirely sure how OOP languages handle testing private functions but it’s a similar problem.

You generally don't because it is considered bad practice. Tests should not be coupled with implementation details.


Eh, I don't entirely agree though I do realize it's important to draw the line somewhere so I guess that's where it's at.


What's your opinion and/or experience on the subject? 🙂 Why don't you agree? 🤔

I guess, I'm a fan of low-level logic testing. ie. testing the nitty gritty implementation details as well as the high-level logic. But I think that has to do with programming style.

I'm generally a fan of building very small light-weight libraries/bags of functions that build on each other and I generally love testing from the ground up based on that. Eg. functions -> internal library -> business logic -> actual API

For example, at my job, we built our internal API in Elixir and it has a fairly high test coverage but what's interesting is the "levels" of abstractions at which we test:

  1. API Http level - tests generally hit the API endpoint and make sure the result is as expected
  2. API level - tests generally call controllers/helpers themselves
  3. application level - tests call various piece of business logic and their helpers
  4. model/query level - tests call model logic and queries against DB

Generally speaking, the only functions that are ever "private" tend to be wrappers that call another helper/model/query/etc. that already have test coverage.

code of conduct - report abuse