"Develop on the BAMF stack" This is an article where I will try to describe my favorite project architecture for web application development, which I happen to call the BAMF stack. With that, there's information on how I got to this stack, what my decision criteria were, and some sample code. The Web is divided …
“Develop on the BAMF stack”
This is an article where I will try to describe my favorite project architecture for web application development, which I happen to call the BAMF stack. With that, there’s information on how I got to this stack, what my decision criteria were, and some sample code.
The Web is divided into two parallel (though technically somewhat perpendicular) universes commonly described as user interfaces and user interfaces. Each of them has a different set of standard functions needed to create basic web applications, and each of them has tens, hundreds, or thousands of options for doing something as simple as “Please hello world”.
This article will be part 1 as I will dive into modern UI development and that will bring us to a fork in the road which I will discuss next in part 2 and possibly part 3 because so if you liked this post, keep it up. The days are not old
When I started web design, almost everything I did was static HTML. Rails and PHP don’t exist, and .NET is something you wouldn’t risk as a hobbyist. CSS is hardly a thing, tables and images are everything, and you can create these little animations in Macromedia to animate anything.
Now, fortunately, we can forget about those. Everything has become simpler and more unified. Today
doctype === html
A website from a user interface perspective consists of HTML, CSS, JavaScript and multimedia resources. That’s it.
If you need to change the look of something, try doing it with CSS.
If that’s not possible, do it with JavaScript (or in some cases SVG).
If you need timed, asynchronous, or user-driven events to interact with the server or redraw the page, do it with JavaScript. It’s simple, but we’re really missing something if we just stop there.
I see a lot of job descriptions that say the following:
“write vanilla OO JavaScript, preferably without relying on frameworks or libraries”
I’m still scratching my head over this as there are only a few times where it can be beneficial. I narrow it down if you are:
write a base library without dependencies as it will be a new library for many other projects
create ad units with very limited size CZK
publish a read-only website with almost no interaction
limited to supporting mobile device browsers such as Hand Web
deliberately increase your project maintenance costs to secure work or lock out suppliers
On the other hand, vanilla JS without dependencies is just bad architecture and here’s why:
By abstracting large amounts of code into well-tested and fairly reliable dependencies, any new code can be very simple and have a direct relationship to its functionality. Shorter code is generally easier to read and understand, and by that logic, cheaper to maintain and better maintainable.
You will often fall into addictions even if you try to avoid them. Trying to avoid them means you’re generally not set up with dependency injection, package management, module loader, or concatenation. Usually it ends up with a set of script tags in the HTML header that can easily become outdated. I’ve seen sites like this with over 70 JavaScript files loaded into each page because they weren’t designed for the inevitable.
