I see this on almost every project I work for in large companies and it's a practice I never fully understand, it's the practice of using frameworks. I understand that often time is a factor and opting for these frameworks cuts down development time, but it create an environment of dependency. I see it almost monthly when a new update has been released and we seem to move away from doing things in an easier more simplistic approach. We opt to use a hammer when a screwdriver is the requirement.

With the web, sometimes you don't need the JavaScript framework to create a static page, sometimes good old fashioned HTML and CSS is more than enough. We often try to fit a square peg in a round hole when it comes to building sites, many agencies will specialise with one framework and that becomes their go to usage for all projects without any scoping for requirements. Do you really need to use React for a static page? Probably not, in most cases you're using 1% of it's full power and the other 99% if taken up by the bloat.

We need to get better at looking at the requirements and asking ourselves do we need (X) and (Y) when (A) fits this need.

Often the goal is promotion and clean fast page loads. We could spend days optimising the code to fulfil this need, streamline the JavaScript that is compiling on build, making sure the SCSS is clean, but the reality is we could have cut down that time by just producing a pure HTML/CSS page without the extra steps. Now in some cases we want to keep this feature rich, loading in images and animations, but we can achieve much of this with PURE HTML and CSS now, but we've pushed these cores to the bottom of the stack in favour of over complicated data structures.

What we're trying to achieve

In most cases we're trying to deploy a simple static webpage which has an image and some content, not so many blog posts anymore as we've moved to social media to achieve this, but we just need a great way of deploying a webpage. When I first started in web development, we built in tables and used inline CSS. It was clunky and cumbersome and didn't look very pretty. Granted back then the fastest connection we had was a 52k dial up modem and we had 2 browsers to pick from (I.E and Netscape Navigator). But it gave me insight into structure of data, something I feel I have carried with me since those early days.

Back then we coded in a text editor (notepad). We had to manually write things out and we didn't really have the luxury of automated closure tag systems. Build tools didn't really exist and it was impossible to find a CMS which didn't cost you money.

But I've watched the environment change over the years. I don't recognise it sometimes, but little nuggets pop through some times. We now have a billion frameworks to choose from, and a number of design systems to work from. We have multiple JavaScript Framework and ways of displaying data.

I've played around with a lot of open source CMS's to really try them out, I eventually landed on DecapCMS but looking at Contenful in the future. I most recently hosted sites in Hugo, which is a great little system for static sites, it allowed me the ability to work with webcomponents which was a nice little trip into some personal discovery. It also allowed me the opportunity to assess if it's worth having a huge JavaScript framework like React or VueJS for a project. In most cases my personal work doesn't really warrant. As the site was just building static HTML with CSS/JS it meant that performance was good and I didn't have to spend my days trying to inject simple data into a field.

We have so much tooling in our work flow now that we spend as long getting our projects set up than we used to just coding by hand with a text editor. Again, I'm not saying that the tooling is counter productive, it's good to have and keeps your code clean and tidy. Maintenance of these build tools becomes a full time role within any team, but you can keep up and keep and eye on trends these tools make life so much easier.