Programmers are complicating the Web culture

Web development doesn’t have to be complicated

A couple of weeks ago, I received Anselm’s newsletter, and I couldn’t agree more with Jeffrey’s article on his arguments regarding complexity. While reading his article, I confirmed my own beliefs and concerns about the future of web development. This is also what triggered these thoughts, and why I wanted to share my side of the story about this so called “cult of the complex”.

Dream team != (is not equal to) success

I keep seeing companies bringing unnecessary complexities in web development, for the simple reason of following the standard “corporate” hierarchy team-structure. I now experienced in person how a company can be brought up to keep such focus on the old fashioned standards, while leaving the coding environment to be poorly built. It made me wonder how much value they brought into building a “dream” team in a company, while completely ignoring the importance of advancing developments in areas such as the Internet and its technologies.

All the ambitions I ever had towards building “our” visionary product drifted away, as I was deciding to depart the company “ship” again. I saw what I’m inevitably always prone to see in many web companies. A company driven foremost by their financial successes, goals, deadlines, and building a cult of the complex. They implement so many strategies and unnecessary complexities that it takes them years or more to have the first stable version of their web-app running online. Throughout this time, they also get lost in minor details which make them blind from the real complexities that come after shipping and maintaining an online version of their product — be it successful. As long as there is a means for cash-flow, anyone has the opportunity to create anything they dream of. Unfortunately some of us aren’t as privileged as others.

Web development — if done by those who really understand it — should allow teams to build and update features simultaneously and effortlessly. Forget about how others are doing it. Discuss what we — as a team — can do to make things better. There will never be a single definition of a particular standard, as things will always keep changing.

We need to continuously find ways that fit the product’s best needs, and keep adapting to these changes. We have to start building less complicated cults and focus on what matters the most.

Look beyond the impossible and make a difference

Developers don’t always need a design, to start implementing the basic architecture of a webpage or website. If we’re to be invited in more meetings about the stories and ideas behind the proposed future implementations, we (developers) can understand better how the development will evolve, and how it should change or adapt future changes. This is always helpful to us developers that care about maintaining a performant website online. It should never only be about the ship, ship, ship! It’s more about reliability, security, accessibility, and privacy.

Never get locked to one single web culture or “micro” ecosystem.

I just left a company were the primary focus was still based on back-end implementations first. After a year and a half, I couldn’t handle this front-end non-sense anymore. I was to be a lead front-end developer (and potentially a company “partner”), working with just two more front-end fellows, but more than twenty Java developers. Yes, you read that right. It was ridiculous to see the amount of wasted time it took for us to finish a feature. In its simplest explanation possible, here is how a feature workflow carried on:

1. Design
2. Markup & JS — My role
3. Copy, edit, paste markup into a “back-end” framework of choice
4. Help developers understand certain functionalities — My role
5. Compile and generate Web resources and files
6. Perform and run tests
7. Evaluate bugs — My role
8. Fix and re-touch markup — My role
9. Update design if necessary and hit repeat

I could never understand such a workflow. “Perform and run tests” aren’t tests after publishing a beta-version online. These are bugs that come out when the front-end structure is generated by the back-end framework. The steps from line three onward can be eliminated if you build a proper front-end architecture. The back-end should be mostly used to handle services through AJAX requests (depending what you build). It’s highly inadvisable that the front-end is maintained by the back-end.

I kept trying my best to move things forward to — at least — a leaner and more modern front-end workflow (no, don’t even mention React). Later on they brought a professional SCRUM “master”, and the first thing he mentioned was that we have to get rid of this legacy environment (JSF anyone?). Their approach, while ignoring my advice towards no adaptations of complex frameworks, went towards the future implementation of AngularJS. Don’t get me wrong, I’m not comparing the above mentioned frameworks together. I would rather say to strive for no frameworks altogether. Check out last years’ statistics about the use of front-end frameworks.

After this, it’s been a month of a personal roller-coaster. For who knows how many times I did this by now, I decided to move on and stick more towards building my own visions and continue teaching online.

Let’s embrace the “vanilla” side of life

Just a tempting vanilla ice-cream picture

I studied computer engineering prior to enrolling to a more “software” based course, and this might be the reason why I quickly understood the JavaScript language during that time. I always chose to embrace the “vanilla” languages themselves, while taking a step backwards from the use of frameworks, platforms, and other form of huge libraries. I always believed that the complexity of learning these “code-stacks” rises by a factor of 10x or more. Since eight years ago, I knew that JavaScript at its core is the language I should strive to become the most familiar with, and I only keep proving myself right. A lot of these arguments come from the same ideas and research which will also be found in the book I’m currently finalizing.

Web development at the core is a pretty straightforward architecture — yes, standards. It is more the ecosystems and the complex cultures that had developed by time, which are making everything seem so complex and impossible to achieve. You have to understand that these frameworks and services are there to ease your development — and only that. It is not a requirement, nor is it possible to keep up with all the new Web “packages” released today. This is why I think we should embrace a little bit more the main web-languages that made the Web how it is today.

I would tell you right now to forget about the hundreds of available frameworks online and learn the standards instead. If you get stuck on something, use a friendly search engine to find your answers. Maybe find a smaller library that provides you only the functionality you require, instead of requesting a bigger library (e.g. jQuery), simply to use a couple of functions.

Try to embrace the vanilla language first, and be careful what kind of packages you use and find online. Don’t always trust everyone straightaway. Try to be more cautious but also curious about building things with your own hands. If you want to invest time for growth, than dismiss or ignore the continuous use of frameworks and libraries. The Web is simpler than you might think, and by learning the standards you invest in yourself.

You should know that all the front-end libraries, platforms, and frameworks built today run behind the same technologies that make anything possible on the Internet. These technologies sum up our three front-end family languages: HTML, CSS, and JS. As simple as counting one, two, and three. Right? Jokes aside, things are becoming much simpler now more than ever. When you put the effort and try to understand how these languages work together, and everything behaves nicely on all the browsers, you will realize that it isn’t so hard after all — you only need to look for time and patience.

Closing thoughts

Survival instincts are deeply integrated within our DNA

There are two main kinds of developers: You either come from the world of programming languages or not. Both of them may also lead towards different development pathways, but the easiest way to get started is to learn and understand the standards — do not create unnecessary complexities_._

Sometimes we all prefer to choose the “fastest” or the “easiest” way of development, maybe because we lack time or money, but this doesn’t always result the way we expect it to be either. Sometimes it can get worse. I hear a lot of frustrations and other misfortunes arising simply because of the poor judgment and lack of proper organization behind the web development technologies chosen.

If you follow the standards and try to understand how everything works, you don’t have much to worry about. The term “from scratch” shouldn’t scare you either. If you’re patient enough, you will find anything you need online. Even if you don’t find the solution, you can always ask for help and get answers.

There’s a lot more we can discuss about the subject from today’s article. Let me know in the comments what you think, and if there’s anything you want me to discuss on coming articles.

Follow me here or join my newsletter if you want to keep learning the crucial secrets of web development. You can also have a look at my eBook — Mastering Web Development

Until next time!

Owen Far

More from Owen Far:

The advantages of building your website from scratch_Most of the people I talk with regarding the product or website that I am developing, tend to ask if I’m using any…_hackernoon.com

Your audience matters the most_Don’t fish out for email addresses, we’re humans you know._hackernoon.com