I keep seeing companies bringing unnecessary complexities in web development for the simple reason of following the standard “corporate” hierarchy team-structure. I have recently 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 ongoing 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 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:
- Design
- Markup & JS — My role
- Copy, edit, paste markup into a back-end framework of choice
- Help developers understand certain functionalities — My role
- Compile and generate Web resources and files
- Perform and run tests
- Evaluate bugs — My role
- Fix and re-touch markup — My role
- 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
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), or a bigger framework (e.g. Bootstrap) 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
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.
Thank you for reading!
Until next time,
Owen Far
P.S. This article was originally published on Medium, but since I've discovered DEV.to, I'm looking forward to publish original content here depending on the feedback I get. I encourage you to leave yours below 🙂
Top comments (6)
I would say try always to use the framework if it provides the same feature.
The framework might have a community of many developers, each one bulletproofing it with different use cases.
Try to diminish the amount of custom code of your company.
Hey Yucer! Yeah, this is very opinionated and different companies should know what's best for them depending on the project / product. Sometimes custom code is the best way to go (as long as you know what you're doing). Frameworks are very powerful and it's great that they exist, but you need to know when it's the right time to use them or not. I say this mainly for the sake of large code that comes pre-loaded with some frameworks and libraries. But if you choose to start using them from the very beginning, than it's completely fine.
Well said. Thanks 👍
Glad you liked the post Erick. Thank you!
Brilliant post
Thanks Ben :) Much appreciated!