Opinionated File Structures for Vanilla JS?

I just saw this Tweet(and follow on discussion) from @una that left me curious.

My own journey into the world of JS doesn’t get far beyond FizzBuzz and a few snippets of jQuery, with frameworks being in some distant and probably parallel universe.

Does anyone know I’d such a thing exists, and why one might/might not exist?

I’ve never come across anything like that. You can find plenty of boilerplate/starter projects out there, but they seem to all be built around specific tools or frameworks.

As to why there isn’t a standard/popular way to structure JS apps, that’s an interesting question - I think many people start out learning JS via jQuery, adding just a little bit of interactivity to their sites here and there… as they progress, things get more complicated and convoluted and they start looking into frameworks as a way to tame the madness. Once they’ve picked up a framework and got comfortable with it, probably not many consider dropping back to vanilla JS.

I made a conscious decision when starting a project recently to avoid using a framework up front and see how things would work out using plain JS and a few basic patterns. I almost got myself into a mess before I decided to structure the app along the same lines that Backbone encourages (without using the actual library) and that improved things.

So would the kind of structure you ended up using be amenable to description do you think? How long have frameworks been around? Half as long as JS perhaps? (I genuinely don’t know the answer to that). You’d imagine someone would have documented the type of ‘best practice’ Una’s asking about in some form, but it may have got lost in the torrent of frameworks we now have. You’d think with JS being as non-opinionated as it seems to be, someone would have thought “I wonder what the best way of organising this stuff is?”.

Less than that. They are all written in JavaScript so each required the author to figure out in detail how to do what they wanted in vanilla JS before they could start on their particular framework.

Well, I have to admit, it’s still a WIP and I’m still trying out different approaches to see what works and what doesn’t. Backbone itself isn’t strongly opinionated, but it does give you some components to help separate the different concerns of your application and so that’s really what I was imitating with my own code.

Basically, you have models and views (Backbone also has collections and routers, but I’ve not implemented those yet in my app). Models are responsible for containing your data, and saving/loading that data from the server. Views manage specific sections of your UI - they are where you attach your DOM event handlers and update the page. These components can also emit their own events which you can listen for.

An example of this from my app would be the ‘current project’ display. I have an area of the screen which displays the current project name and some other details. The view object that manages that part of the UI listens to the the current project model for changes and updates the display accordingly.

I find that structuring the app along these lines makes it easier to manage, as all the code that interacts with a certain part of the page is kept together within a view object. If something is not working correctly, you know where to look, rather than potentially having jQuery calls sprinkled throughout your code that may be touching the same part of the DOM.

As for the file structure, I keep my JS files organized into folders by type (e.g. View, Model etc.) For larger applications it seems to be more popular to group files according to the part of the application functionality they relate to (e.g. Users, Projects, Portfolio).

If you’re not come across it before, I’d recommend taking a look at the TodoMVC project. They take a basic to-do list app and provide versions created with different libraries/frameworks for comparison. There is a vanilla JS version, and a jQuery version that you might be interested in.

1 Like

So if you were to try and describe ‘best practice’ for a vanilla JS app, that’s perhaps where you’d start then? Look at a pre-existing frameworks, look for patterns in how it has been structured and replicate those patterns, but without reverting to the framework libraries themselves?

It seems slightly surprising I guess that you have to create this yourself. You’d imagine it would have been around long enough, that others would have done something similar and recorded their findings - even as a stepping stone to creating that first framework (I wonder what that was?).

OK, I can follow that as a basic idea of how they are intended to operate. If I’m to extend you description there further, there would be other UI sections (perhaps being controlled by another user elsewhere) that are used to pass new data into server. As new data is passed in, this triggers an event that is heard ‘elsewhere’, at which point the UI pulls that data into itself through the View component.

[quote=“fretburner, post:5, topic:203909”]
I find that structuring the app along these lines makes it easier to manage, as all the code that interacts with a certain part of the page is kept together within a view object. If something is not working correctly, you know where to look, rather than potentially having jQuery calls sprinkled throughout your code that may be touching the same part of the DOM.[/quote]

I think I get that. The idea is that the jQuery library is getting calls from all over the app, some of which could clash. In the MVC model, things are more deconflicted?

That seems to lend itself to some sort of continuum, depending on extent of functionality, dev team structure (who is building what), potential number of users, transaction volumes and so on. Sounds like a study all of its very own.

That sounds interesting. I wonder how closely they resemble each other in structure and organisation? Time to take a look.

Just curious, but how close are we to the question @una originally asked?

For me best practice varies depending on the complexity of the project.

  • When doing something really simple with one html, css, and js file, having all three in the same folder is no problem at all.
  • With 3 or more scripting files, placing them in a dedicated js/ folder is wise.
  • With libraries, placing those in a separate lib/ folder is a good idea.

When doing a simple project, it’s worse to use a highly opinionated folder structure as you’re left with lots of empty unused folders, and if you remove those empty ones you then have one or two files lost in a deeply nested structure that serves no benefit either.

When you’re working with an opinated framework, it’s best to work with the structure given you you there.
Otherwise, when you have several scripting files that do similar jobs, it’s best to group those together. When the number of files that you’re managing grows, it helps to group them in to appropriate structures.

So when it comes to folder structure, the answer tends to be, “It depends”. There is no one-size-fits-all mumu that we can give.

1 Like

Hi Chris, sorry for the delayed reply…

Sort of. Say you had an app that showed you some sort of notifications of other users’ activities, then you’d have a model that was responsible for retrieving those from the server. Whenever the model received new data, it would emit an event. You might have several views listening for that event which would update their sections of the page in response.

Without some sort of separation of concerns it’s quite easy to end up in a situation where you have several different pieces of code acting on a section of HTML.

Continuing with the example of a notification area, you might have this set up so that the success callback of an AJAX request updates it. Later on, you want to add notifications from some other action (clicking something on the page, for example) so you add some additional code that updates the notifications list. You now have duplicated code (the code that modifies the list) and two separate places to look if you want to change how that list is updated (say that you want to change the HTML).

With a view object to manage the notification list markup, you avoid duplication and you know exactly where to look to troubleshoot/change things. The code that interacts with the page is separated from other concerns (such as saving/loading data) making it easier to maintain, test and reason about.

I did a bit more research since my last post and came across a good article you might like to read: Patterns For Large-Scale JavaScript Application Architecture. Despite talking about large-scale applications, there’s a lot of good information that will be equally useful when writing smaller apps.

One of the related-reading links from the article (the link in the article is broken, here is the updated link) actually describes the sort of architecture I’m currently using in better detail.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.