{"id":385,"date":"2024-02-07T12:00:00","date_gmt":"2024-02-07T13:00:00","guid":{"rendered":"http:\/\/sobre-portugal.com\/?p=385"},"modified":"2024-06-12T20:25:07","modified_gmt":"2024-06-12T20:25:07","slug":"web-development-is-getting-too-complex-and-it-may-be-our-fault","status":"publish","type":"post","link":"http:\/\/sobre-portugal.com\/index.php\/2024\/02\/07\/web-development-is-getting-too-complex-and-it-may-be-our-fault\/","title":{"rendered":"Web Development Is Getting Too Complex, And It May Be Our Fault"},"content":{"rendered":"<p>              <title>Web Development Is Getting Too Complex, And It May Be Our Fault<\/title><\/p>\n<article>\n<header>\n<h1>Web Development Is Getting Too Complex, And It May Be Our Fault<\/h1>\n<address>Juan Diego Rodr\u00edguez<\/address>\n<p>                  2024-02-07T13:00:00+00:00<br \/>\n                  2024-06-12T20:05:40+00:00<br \/>\n                <\/header>\n<p>Front-end development seemed simpler in the early 2000s, didn\u2019t it? The standard website consisted mostly of static pages made of HTML and CSS seasoned with a pinch of JavaScript and jQuery. I mean, who doesn\u2019t miss the cross-browser compatibility days, right?<\/p>\n<p>Fast forward to today, and it looks like a parallel universe is taking place with an overwhelming number of choices. Which framework should you use for a new project? Perhaps more established ones like React, Angular, Vue, Svelte, or maybe the hot new one that came out last month? Each framework comes with its unique ecosystem. You also need to decide whether to use TypeScript over vanilla JavaScript and choose how to approach server-side rendering (or static site generation) with <em>meta-frameworks<\/em> like Next, Nuxt, or Gatsby. And we can\u2019t forget about unit and end-to-end testing if you want a bug-free web app. And we\u2019ve barely scratched the surface of the front-end ecosystem!<\/p>\n<p>But has it <em>really<\/em> gotten more complex to build websites? A lot of the frameworks and tooling we reach for today were originally crafted for massive projects. As a newcomer, it can be frightening to have so many to consider, almost creating a fear of missing out that we see exploited to sell courses and tutorials on the new hot framework that you \u201ccannot work without.\u201d<\/p>\n<p>All this gives the impression that web development has gotten perhaps <em>too<\/em> complex. But maybe that is just an exaggeration? In this article, I want to explore those claims and find out if web development really is that complex and, most importantly, how we can prevent it from getting even more difficult than we already perceive it to be.<\/p>\n<h2 id=\"how-it-was-before\">How It Was Before<\/h2>\n<p>As someone who got into web development after 2010, I can\u2019t testify to my own experience about how web development was from the late 1990s through the 2000s. However, even fifteen years ago, learning front-end development was infinitely simpler, at least to me. You could get a website started with static HTML pages, minimal CSS for styling, and a sprinkle of JavaScript (and perhaps a touch of jQuery) to add interactive features, from toggled sidebars to image carousels and other patterns. Not much else was expected from your average developer beyond that &mdash; everything else was considered \u201cgoing the extra mile.\u201d Of course, the awesome native CSS and JavaScript features we have today weren\u2019t around back then, but they were also unnecessary for what was considered best practice in past years.<\/p>\n<p>Large and dynamic web apps certainly existed back then &mdash; YouTube and Facebook, to name a couple &mdash; but they were developed by massive companies. No one was expected to re-create that sort of project on their own or even a small team. That would\u2019ve been the exception rather than the norm.<\/p>\n<p>I remember back then, tend to worry more about things like SEO and page optimization than how my IDE was configured, but only to the point of adding meta tags and keywords because best practices didn\u2019t include minifying all your assets, three shaking your code, caching your site on edge CDNs, or rendering your content on the server (a problem created by modern frameworks along <a href=\"https:\/\/www.gatsbyjs.com\/docs\/conceptual\/react-hydration\/\">hydration<\/a>). Other factors like accessibility, user experience, and responsive layouts were also largely overlooked in comparison to today\u2019s standards. Now, they are deeply analyzed and used to boost Lighthouse scores and impress search engine algorithms.<\/p>\n<p>The web and everything around it changed as more capabilities were added and more and more people grew to depend on it. We have created new solutions, new tools, new workflows, new features, and whatever else new that is needed to cater to a bigger web with even bigger needs.<\/p>\n<p>The web has always had its problems in the past that were worthy of fixing: I absolutely don\u2019t miss tables and float layouts, along with messy DOM manipulation. This post isn\u2019t meant to throw shade on new advances while waxing nostalgic about the good days of the \u201cold wild web.\u201d At the same time, though, yesterday\u2019s problems seem infinitely simpler than those we face today.<\/p>\n<div data-audience=\"non-subscriber\" data-remove=\"true\" class=\"feature-panel-container\">\n<aside class=\"feature-panel\">\n<div class=\"feature-panel-left-col\">\n<div class=\"feature-panel-description\">\n<p>Meet <strong><a data-instant href=\"\/printed-books\/typescript-in-50-lessons\/\">\u201cTypeScript in 50 Lessons\u201d<\/a><\/strong>, our shiny new guide to TypeScript. With detailed <strong>code walkthroughs<\/strong>, hands-on examples and common gotchas. For developers who know enough <strong>JavaScript<\/strong> to be dangerous.<\/p>\n<p><a data-instant href=\"\/printed-books\/typescript-in-50-lessons\/\" class=\"btn btn--green btn--large\">Jump to table of contents&nbsp;\u21ac<\/a><\/div>\n<\/div>\n<div class=\"feature-panel-right-col\"><a data-instant href=\"\/printed-books\/typescript-in-50-lessons\/\" class=\"feature-panel-image-link\"><\/p>\n<div class=\"feature-panel-image\">\n<img decoding=\"async\" loading=\"lazy\" class=\"feature-panel-image-img\" src=\"https:\/\/archive.smashing.media\/assets\/344dbf88-fdf9-42bb-adb4-46f01eedd629\/c2f2c6d6-4e85-449a-99f5-58bd053bc846\/typescript-shop-cover-opt.png\" alt=\"Feature Panel\" width=\"481\" height=\"698\" \/><\/p>\n<\/div>\n<p><\/a>\n<\/div>\n<\/aside>\n<\/div>\n<h2 id=\"javascript-frameworks\">JavaScript Frameworks<\/h2>\n<p>JavaScript frameworks, like Angular and React, were created by Google and Facebook, respectively, to be used in their own projects and satisfy the needs that only huge web-based companies like them have. Therein lies the main problem with web complexity: <strong>JavaScript frameworks were originally created to sustain giant projects rather than smaller ones<\/strong>. Many developers vastly underestimate the amount of time it takes to build a codebase that is reliable and maintainable with a JavaScript framework. However, the alternative of using vanilla JavaScript was <em>worse<\/em>, and jQuery was short for the task. Vanilla JavaScript was also unable to evolve quickly enough to match our development needs, which changed from simple informative websites to dynamic apps. So, many of us have quickly adopted frameworks to avoid directly mingling with JavaScript and its messy DOM manipulation.<\/p>\n<p>Back-end development is a completely different topic, subject to its own complexities. I only want to focus on front-end development because that is the discipline that has perhaps overstepped its boundaries the most by bleeding into traditional back-end concerns.<\/p>\n<h2 id=\"stacks-getting-bigger\">Stacks Getting Bigger<\/h2>\n<p>It was only logical for JavaScript frameworks to grow in size over time. The web is a big place, and no one framework can cover everything. But they try, and the complexity, in turn, increases. A framework\u2019s size seems to have a one-to-one correlation with its complexity.<\/p>\n<p>But the core framework is just one piece of a web app. Several other technologies make up what\u2019s known as a tech \u201cstack,\u201d and with the web gaining more users and frameworks catering to their needs, tech stacks are getting bigger and bigger. You may have seen popular stacks such as MEAN (MongoDB, Express, Angular, and Node) or its React (MERN) and Vue (MEVN) variants. These stacks are marketed as mature, test-proofed foundations suitable for any front-end project. That means <strong>the advertised size of a core framework is grossly underestimated<\/strong> because they rely on other micro-frameworks to ensure highly reliable architectures, as you can see in <a href=\"https:\/\/stackshare.io\/stacks\">stackshare.io<\/a>. Besides, there isn\u2019t a one-size-fits-all stack; the best tool has always depended &mdash; and will continue to depend &mdash; on the needs and goals of your particular project.<\/p>\n<p>This means that each new project likely requires a unique architecture to fulfill its requirements. Giant tech companies need colossal architectures across all their projects, and their stacks are highly engineered accordingly to secure scalability and maintenance. They also have massive customer bases, so maintaining a large codebase will be easier with more revenue, more engineers, and a clearer picture of the problem. To minimize waste, the tech stacks of smaller companies and projects can and should be minimized not only to match the scale of their needs but to the abilities of the developers on the team as well.<\/p>\n<blockquote class=\"pull-quote\">\n<p>\n    <a class=\"pull-quote__link\" aria-label=\"Share on Twitter\" href=\"https:\/\/twitter.com\/share?text=%0aThe%20idea%20that%20web%20development%20is%20getting%20too%20complex%20comes%20from%20buying%20into%20the%20belief%20that%20we%20all%20have%20the%20same%20needs%20and%20resources%20as%20giant%20enterprises.%0a&amp;url=https:\/\/smashingmagazine.com%2f2024%2f02%2fweb-development-getting-too-complex%2f\"><\/p>\n<p>The idea that web development is getting too complex comes from buying into the belief that we all have the same needs and resources as giant enterprises.<\/p>\n<p>    <\/a>\n  <\/p>\n<div class=\"pull-quote__quotation\">\n<div class=\"pull-quote__bg\">\n      <span class=\"pull-quote__symbol\">\u201c<\/span><\/div>\n<\/p><\/div>\n<\/blockquote>\n<p>Trying to imitate their mega stacks is pointless. Some might argue that it\u2019s a sacrifice we have to make for future scalability and maintenance, but we should focus first on building great sites for the user without worrying about features users <em>might<\/em> need in the future. If what we are building is worth pursuing, it will reach the point where we need those giant architectures in good time. Cross that bridge when we get there. Otherwise, it\u2019s not unlike wearing Shaquille O\u2019Neal-sized sneakers in hopes of growing into them. They might not even last until then if it happens at all!<\/p>\n<p>We must remember that the end-user experience is the focus at the end of the day, and <strong>users neither care about nor know what stack we use in our apps<\/strong>. What they care about is a good-looking, useful website where they can accomplish what they came for, not the technology we use to achieve it. This is how I\u2019ve come to believe that web development is <em>not<\/em> getting more complex. It\u2019s developers like us who are perpetuating it by buying into solutions for problems that do not need to be solved at a certain scale.<\/p>\n<p>Let me be really clear: I am not saying that today\u2019s web development is all bad. Indeed, we\u2019ve realized a lot of great features, and many of them are thanks to JavaScript frameworks that have pushed for certain features. jQuery had that same influence on JavaScript for many, many years.<\/p>\n<p>We can still create minimum viable products today with minimal resources. No, those might not make people smash the Like button on your social posts, but they meet the requirements, nothing more and nothing less. We want bigger! Faster! Cheaper! <a href=\"https:\/\/lodestar.asu.edu\/blog\/2011\/09\/research-friday-bigger-better-faster-cheaper\">But we can\u2019t have all three.<\/a><\/p>\n<p>If anything, front-end development has gotten way <em>easier<\/em> thanks to modern features that solve age-old development issues, like the way CSS Flexbox and Grid have trivialized layouts that used to require complex hacks involving floats and tables. It\u2019s the same deal with JavaScript gaining new ways to build interactions that used to take clever workarounds or obtuse code, such as <a href=\"https:\/\/www.smashingmagazine.com\/2018\/01\/deferring-lazy-loading-intersection-observer-api\/\">having the Intersection Observer API to trivialize things like lazy loading<\/a> (although <a href=\"https:\/\/www.smashingmagazine.com\/2019\/05\/hybrid-lazy-loading-progressive-migration-native\/\">HTML has gained its own features in that area, too<\/a>).<\/p>\n<blockquote class=\"pull-quote\">\n<p>\n    <a class=\"pull-quote__link\" aria-label=\"Share on Twitter\" href=\"https:\/\/twitter.com\/share?text=%0aWe%20live%20in%20this%20tension%20between%20the%20ease%20of%20new%20platform%20features%20and%20the%20complexity%20of%20our%20stacks.%0a&amp;url=https:\/\/smashingmagazine.com%2f2024%2f02%2fweb-development-getting-too-complex%2f\"><\/p>\n<p>We live in this tension between the ease of new platform features and the complexity of our stacks.<\/p>\n<p>    <\/a>\n  <\/p>\n<div class=\"pull-quote__quotation\">\n<div class=\"pull-quote__bg\">\n      <span class=\"pull-quote__symbol\">\u201c<\/span><\/div>\n<\/p><\/div>\n<\/blockquote>\n<div class=\"partners__lead-place\"><\/div>\n<h2 id=\"do-we-need-a-javascript-framework-for-everything\">Do We Need A JavaScript Framework For Everything?<\/h2>\n<p>Each project, regardless of its simplicity, desperately needs a JavaScript framework. A project without a complex framework is like serving caviar on a paper plate.<\/p>\n<p>At least, that\u2019s what everyone seems to think. But is that actually true? I\u2019d argue on the contrary. JavaScript frameworks are best used on bigger applications. If you\u2019re working on a smaller project, a component-based framework will only complicate matters, making you split your website into a component hierarchy that amounts to overkill for small projects.<\/p>\n<p><strong>The idea of needing a framework for everything has been massively oversold.<\/strong> Maybe not directly, but you unconsciously get that feeling whenever a framework\u2019s name pops in, as Edge engineer Alex Russell eloquently expresses in his article, \u201c<a href=\"https:\/\/infrequently.org\/2023\/02\/the-market-for-lemons\/\">The Market For Lemons<\/a>\u201d:<\/p>\n<blockquote><p>\u201cThese technologies were initially pitched on the back of \u201cbetter user experiences\u201d but have utterly failed to deliver on that promise outside of the high-management-maturity organisations in which they were born. Transplanted into the wider web, these new stacks have proven to be expensive duds.\u201d<\/p>\n<p>&mdash; Alex Russell<\/p><\/blockquote>\n<p>Remember, the <strong>purpose of a framework is to simplify your life and save time<\/strong>. If the project you\u2019re working on is smaller, the time you supposedly save is likely overshadowed by the time you spend either setting up the framework or making it work with the rest of the project. A framework can help make bigger web apps more interactive and dynamic, but there are times when a framework is a heavy-handed solution that actually breeds inefficient workflows and introduces technical debt.<\/p>\n<p>Step back and think about this: Are HTML, CSS, and a touch of JavaScript enough to build your website or web application? If so, then stick with those. What I am afraid of is adding complexity for complexity\u2019s sake and inadvertently raising the barrier to entry for those coming into web development. We can still accomplish so much with HTML and CSS alone, thanks again to many advances in the last decade. But we give the impression that they are unsuitable for today\u2019s web consumption and need to be enhanced.<\/p>\n<h2 id=\"knowing-everything-and-nothing-at-the-same-time\">Knowing Everything And Nothing At The Same Time<\/h2>\n<p>The perceived standard that teams must adopt framework-centered architectures puts a burden not only on the project itself but on a developer\u2019s well-being, too. As mentioned earlier, most teams are unable to afford those architectures and only have a few developers to maintain them. If we undermine what can be achieved with HTML and CSS alone and set the expectations that any project &mdash; regardless of size &mdash; needs to have a <em>bleeding edge<\/em> stack, then the weight to meet those expectations falls on the developer\u2019s shoulders, with the great responsibility of being proficient in all areas, from the server and database to front end, to design, to accessibility, to performance, to testing, and it doesn\u2019t stop. It\u2019s what has been driving <a href=\"https:\/\/css-tricks.com\/the-great-divide\/\">\u201cThe Great Divide\u201d in front-end development<\/a>, which Chris Coyier explains like this:<\/p>\n<blockquote><p>\u201cThe divide is between people who self-identify as a (or have the job title of) front-end developer yet have divergent skill sets. <strong>On one side<\/strong>, an army of developers whose interests, responsibilities, and skillsets are heavily revolved around JavaScript. <strong>On the other<\/strong>, an army of developers whose interests, responsibilities, and skillsets are focused on other areas of the front end, like HTML, CSS, design, interaction, patterns, accessibility, and so on.\u201d<\/p>\n<p>&mdash; Chris Coyier<\/p><\/blockquote>\n<p>Under these expectations, developers who focus more on HTML, CSS, design, and accessibility rather than the latest technology will feel less valued in an industry that appears to praise those who are concerned with the stack. What exactly are we saying when we start dividing responsibilities in terms of \u201cfull-stack development\u201d or absurd terms like \u201c10x development\u201d? A while back, <a href=\"https:\/\/bradfrost.com\/blog\/post\/front-of-the-front-end-and-back-of-the-front-end-web-development\/\">Brad Frost began distinguishing these divisions as \u201cfront-of-the-front-end\u201d and \u201cback-of-the-front-end\u201d<\/a>.<\/p>\n<p><a href=\"https:\/\/medium.com\/@mandy.michael\/is-there-any-value-in-people-who-cannot-write-javascript-d0a66b16de06\">Mandy Michael explains<\/a> what impact the chase for \u201cfull-stack\u201d has had on developers trying to keep up:<\/p>\n<blockquote><p>\u201cThe worst part about pushing the \u201cknow everything\u201d mentality is that we end up creating an industry full of professionals suffering from burnout and mental illness. We have people speaking at conferences about well-being, imposter syndrome, and full-stack anxiety, yet despite that, we perpetuate this idea that people have to know everything and be amazing at it.\u201d<\/p>\n<p>&mdash; Mandy Michael<\/p><\/blockquote>\n<p>This isn\u2019t the only symptom of adopting heavy-handed solutions for what \u201cvanilla\u201d HTML, CSS, and JavaScript already handle nicely. As the expectations for what we can do as front-end developers grow, the learning curve of front-end development grows as well. Again, we can\u2019t learn and know everything in this vast discipline. But we tell ourselves we have to, and thanks to this mentality, it\u2019s unfortunately common to witness developers who may be extremely proficient with a particular framework but actually know and understand little of the web platform itself, like HTML semantics and structure.<\/p>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/web-development-getting-too-complex\/do-i-need-to-learn-javascript-first.jpeg\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"241\" src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/web-development-getting-too-complex\/do-i-need-to-learn-javascript-first.jpeg\" alt=\"The text in the picture reads \u2018Do I need to learn JavaScript first?\u2019, and the answer is the following: \u2018You might be asking whether you need to learn JavaScript before you dive into React. In 2024, I would personally say, no, you don&#039;t really need to.\u2019\" \/><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      (<a href=\"https:\/\/files.smashing.media\/articles\/web-development-getting-too-complex\/do-i-need-to-learn-javascript-first.jpeg\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>The fact that many budding developers tend to jump straight into frameworks at the expense of understanding the basics of HTML and CSS isn\u2019t a new worry, as <a href=\"https:\/\/rachelandrew.co.uk\/archives\/2019\/01\/30\/html-css-and-our-vanishing-industry-entry-points\/\">Rachel Andrew discussed back in 2019<\/a>:<\/p>\n<blockquote><p>\u201cThat\u2019s the real entry point here, and yes, in 2019, they are going to have to move on quickly to the tools and techniques that will make them employable, if that is their aim. However, those tools output HTML and CSS in the end. It is the bedrock of everything that we do, which makes the devaluing of those with real deep skills in those areas so much more baffling.\u201d<\/p>\n<p>&mdash; Rachel Andrew<\/p><\/blockquote>\n<p>And I want to clarify yet again that <strong>modern Javascript frameworks and libraries aren\u2019t inherently bad; they just aren\u2019t designed to replace the web platform and its standards<\/strong>. But we keep pushing them like we want them to!<\/p>\n<h2 id=\"the-consequences-of-vendor-lock-in\">The Consequences Of Vendor Lock-In<\/h2>\n<p>\u201cVendor lock-in\u201d happens when we depend too deeply on proprietary products and services to the extent that switching to other products and services becomes a nearly impossible task. This often occurs when cloud services from a particular company are deeply integrated into a project. It\u2019s an issue, especially in cloud computing, since moving databases once they are set up is expensive and lengthy.<\/p>\n<p>Vendor lock-in in web development has traditionally been restricted to the back end, like with cloud services such as AWS or Firebase; the front-end framework, meanwhile, was a completely separate concern. That said, I have noticed a recent trend where <strong>vendor lock-in is reaching into meta-frameworks<\/strong>, too. With the companies behind certain meta-frameworks offering hosting services for their own products, swapping hosts is increasingly harder to do (whether the lock-in is designed intentionally or not). Of course, companies and developers will be more likely to choose the hosting service of the company that made a particular framework used on their projects &mdash; they\u2019re the experts! &mdash; but that only increases the project\u2019s dependency on those vendors and their services.<\/p>\n<p>A clear example is the relationship between Next and Vercel, the parent cloud service for Next. With the launch of Next 13, it has become increasingly harder to set up a Next project outside of Vercel, leading to projects like <a href=\"https:\/\/open-next.js.org\/\">Open Next<\/a>, which says right on its website that <em>\u201c[w]hile Vercel is great, it\u2019s not a good option if all your infrastructure is on AWS. Hosting it in your AWS account makes it easy to integrate with your backend [sic]. And it\u2019s a lot cheaper than Vercel.\u201d<\/em> Fortunately, the developers\u2019 concerns have been heard, and <a href=\"https:\/\/nextjs.org\/blog\/next-14-1#improved-self-hosting\">Next 14 brings clarity<\/a> on how to self-host Next on a Node server.<\/p>\n<p>Another example is <a href=\"https:\/\/www.gatsbyjs.com\">Gatsby<\/a> and <a href=\"https:\/\/www.gatsbyjs.com\/docs\/how-to\/cloud\/\">Gatsby Cloud<\/a>. Gatsby has always offered helpful guides and alternative hosting recommendations, but since the launch of Gatsby Cloud in 2019, the main framework has been optimized so that using Gatsby and Gatsby Cloud together requires no additional hosting configurations. That\u2019s fantastic if you adopt both, but it\u2019s not so great if all you need is one or the other because integrating the framework with other hosts &mdash; and vice versa &mdash; is simply harder. It\u2019s as if you are penalized for exercising choice.<\/p>\n<p>And let\u2019s not forget that no team expected <a href=\"https:\/\/www.netlify.com\/press\/netlify-acquires-gatsby-inc-to-accelerate-adoption-of-composable-web-architectures\/\">Netlify to acquire Gatsby Cloud in February 2023<\/a>. This is a prime case where the vendor lock-in problem hits everybody because converting from one site to another comes at a cost. Some teams were charged 120% more after converting from Gatsby Cloud to Netlify &mdash; even with the same plan they had with Gatsby Cloud!<\/p>\n<p>What\u2019s the solution? The common answer I hear is to stop using paid cloud services in favor of open-sourced alternatives. While that\u2019s great and indeed a viable option for some projects, it fails to consider that <strong>an open-source project may not meet the requirements needed for a given app<\/strong>.<\/p>\n<p>And even then, open-source software depends on the community of developers that maintain and update the codebase with little to no remuneration in exchange. Further, open source is equally prone to locking you into certain solutions that are designed to solve a deficiency with the software.<\/p>\n<p>There are frameworks and libraries, of course, that are in no danger of being abandoned. React is a great example because it has an actively engaged community behind it. But you can\u2019t have the same assurance with each new dependency you add to a project. We can\u2019t simply keep installing more packages and components each time we spot a weak spot in the dependency chain, especially when a project is perfectly suited for a less complex architecture that properly leverages the web platform.<\/p>\n<blockquote class=\"pull-quote\">\n<p>\n    <a class=\"pull-quote__link\" aria-label=\"Share on Twitter\" href=\"https:\/\/twitter.com\/share?text=%0aChoosing%20technology%20for%20your%20stack%20is%20an%20exercise%20of%20picking%20your%20own%20poison.%20Either%20choose%20a%20paid%20service%20and%20be%20subject%20to%20vendor%20lock-in%20in%20the%20future,%20or%20choose%20an%20open-source%20one%20and%20pray%20that%20the%20community%20continues%20to%20maintain%20it.%0a&amp;url=https:\/\/smashingmagazine.com%2f2024%2f02%2fweb-development-getting-too-complex%2f\"><\/p>\n<p>Choosing technology for your stack is an exercise of picking your own poison. Either choose a paid service and be subject to vendor lock-in in the future, or choose an open-source one and pray that the community continues to maintain it.<\/p>\n<p>    <\/a>\n  <\/p>\n<div class=\"pull-quote__quotation\">\n<div class=\"pull-quote__bg\">\n      <span class=\"pull-quote__symbol\">\u201c<\/span><\/div>\n<\/p><\/div>\n<\/blockquote>\n<p>Those are virtually the only two choices. Many of the teams I know or have worked on depend on third-party services because they cannot afford to develop them on their own; that\u2019s a luxury that only massive companies can afford. It\u2019s a problem we have to undergo when starting a new project, but one we can minimize by reducing the number of dependencies and choosing wisely when we have to.<\/p>\n<h2 id=\"each-solution-introduces-a-new-problem\">Each Solution Introduces A New Problem<\/h2>\n<p>Why exactly have modern development stacks gotten so large and complex? We can point a finger at the \u201cDevelopment Paradox.\u201d With each new framework or library, a new problem crops up, and time-starved developers spend months developing a new tool to solve that problem. And when there isn\u2019t a problem, don\u2019t worry &mdash; we will create one eventually. This is a <strong>feedback loop that creates amazing solutions and technologies but can lead to over-engineered websites<\/strong> if we don\u2019t reign it in.<\/p>\n<p>This reminds me of the famous quote:<\/p>\n<blockquote><p>\u201cThe plain fact is that if you don\u2019t have a problem, you create one. If you don\u2019t have a problem, you don\u2019t feel that you are living.\u201d<\/p>\n<p>&mdash; U.G. Krishnamurti<\/p><\/blockquote>\n<p>Let\u2019s look specifically at <strong>React<\/strong>. It was originally created <em>by<\/em> Facebook <em>for<\/em> Facebook to develop more dynamic features for users while improving Facebook\u2019s developer experience.<\/p>\n<p>Since React was open-sourced in 2013 (and <a href=\"https:\/\/ma.tt\/2017\/09\/on-react-and-wordpress\/\">nearly re-licensed in 2017, if it weren\u2019t for the WordPress community<\/a>), hundreds of new utilities have been created to address various React-specific problems. How do you start a React project? There\u2019s Create React App and Vite. Do you need to enhance your state management? There is Redux, among other options. Need help creating forms? There is a React Hook Form. And perhaps the most important question: Do you need server-side rendering? There\u2019s Next, Remix, or Gatsby for that. Each solution comes with its own caveats, and developers will create their own solutions for them.<\/p>\n<p>It may be unfair to pick on React since it considers itself a <em>library<\/em>, not a <em>framework<\/em>. It\u2019s inevitably prone to be extended by the community. Meanwhile, Angular and Vue are frameworks with their own community ecosystems. And this is the tip of the iceberg since there are many JavaScript frameworks in the wild, each with its own distinct ideology and dependencies.<\/p>\n<p>Again, I don\u2019t want you to get the wrong idea. I <em>love<\/em> that new technologies emerge and find it liberating to have so many options. But when building something as straightforward as a webpage or small website &mdash; which some have started referring to as \u201cmulti-page applications\u201d &mdash; we have to draw a line that defines how many new technologies we use and how reliable they are. We\u2019re quite literally mashing together third-party code written by various third-party developers. What could go wrong? Please don\u2019t answer that.<\/p>\n<p>Remember that our <strong>users don\u2019t care what\u2019s in our stacks<\/strong>. They only see the final product, so we can save ourselves from working on unnecessary architectures that aren\u2019t appreciated outside of development circles. It may seem counterintuitive in the face of advancing technology, but knowing that the user doesn\u2019t care about what goes behind the scenes and only sees the final product will significantly enhance our developer experience and free you from locked dependencies. Why fix something that isn\u2019t broken?<\/p>\n<div class=\"partners__lead-place\"><\/div>\n<h2 id=\"how-can-we-simplify-our-codebases\">How Can We Simplify Our Codebases?<\/h2>\n<p>We\u2019ve covered several reasons why web development appears to be more complex today than in years past, but blaming developers for releasing new utilities isn\u2019t an accurate portrayal of the real problem. After all, when developing a site, it\u2019s not like we are forced to use each new technology that enters the market. In fact, many of us are often unaware of a particular library and only learn about it when developing a new feature. For example, if we want to add <em>toast notifications<\/em> to our web app, we will look for a library like <a href=\"https:\/\/www.npmjs.com\/package\/react-toastify\"><code>react-toastify<\/code><\/a> rather than some other way of building them because it \u201cgoes with\u201d that specific library. It\u2019s worth asking whether the app needs toast notifications at all if they introduce new dependencies.<\/p>\n<p>Imagine you are developing an app that allows users to discover, review, and rate restaurants in their area. The app needs, at a bare minimum, information about each restaurant, a search tool to query them, and an account registration flow with authentication to securely access the account. It\u2019s easy to make assumptions about what a future user might need in addition to these critical features. In many cases, a project ends up delayed because we add unnecessary features like SSR, notifications, offline mode, and fancy animations &mdash; sometimes before the app has even converted its first registered user!<\/p>\n<p>I believe we can boil down the complexity problem to personal wishes and perceived needs rather than properly scoping a project based on user needs and experiences.<\/p>\n<p>That level of <a href=\"https:\/\/www.coursera.org\/gb\/articles\/what-is-scope-creep\">scope creep<\/a> can easily turn into an over-engineered product that will likely never see the light of launching.<\/p>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/web-development-getting-too-complex\/overengineering.png\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"423\" src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/web-development-getting-too-complex\/overengineering.png\" alt=\"Three-panel comic strip titled \u2018The UX Designer Paradox.\u2019\" \/><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      Image source: <a href=\"https:\/\/twitter.com\/rspective\/status\/984684411181518848\">@rspective via X<\/a>. (<a href=\"https:\/\/files.smashing.media\/articles\/web-development-getting-too-complex\/overengineering.png\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>What can we do to simplify our own projects? The following advice is relevant when you have control over your project, either because it\u2019s a personal one, it\u2019s a smaller one for a smaller team, or you have control over the decisions in whatever size organization you happen to be in.<\/p>\n<p>The hardest and most important step is <strong>having a sense of detection when your codebase is getting unnecessarily complicated<\/strong>. I deem it the hardest step because there is no certainty of what the requirements are or what the user needs; we can only make assumptions. Some are obvious, like assuming the user will need a way to log into the app. Others might be unclear, like whether the app should have private messaging between users. Others are still far-fetched, like believing users need extremely low latency in an e-commerce page. Other features are in the \u201cnice to have\u201d territory.<\/p>\n<p>That is regarding the user experience, but the same questions emerge on the development side:<\/p>\n<ul>\n<li>Should we be using a CSS preprocessor or a CSS framework, or can we achieve it using only CSS modules?<\/li>\n<li>Is vanilla JavaScript enough, or are we going to add TypeScript?<\/li>\n<li>Does the app need SSR, SSG, or a hybrid of the two?<\/li>\n<li>Should we implement Redis on the back end for faster database queries, or is that too much scope for the work?<\/li>\n<li>Should we be implementing end-to-end testing or unit tests?<\/li>\n<\/ul>\n<p>These are valid questions that should be considered when developing a site, but they can distract us from our main focus: getting things done.<\/p>\n<blockquote><p>\u201cDone is better than perfect.\u201d<\/p>\n<p>&mdash; Sheryl Sandberg<\/p><\/blockquote>\n<p>And, hey, even the largest and most sophisticated apps began as minimal offerings that iterated along the way.<\/p>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/web-development-getting-too-complex\/first-web-versions.png\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"450\" src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/web-development-getting-too-complex\/first-web-versions.png\" alt=\"First versions of Amazon, Facebook, Google and Twitter\" \/><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      First versions of Amazon, Facebook, Google and Twitter. (<a href=\"https:\/\/files.smashing.media\/articles\/web-development-getting-too-complex\/first-web-versions.png\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>We also ought to be asking ourselves what would happen if a particular feature or dependency <em>isn\u2019t<\/em> added to the project. If the answer is \u201cnothing,\u201d then we should be shifting our attention to something else.<\/p>\n<p>Another question worth asking: <em>\u201cWhy are we choosing to add [X]?\u201d<\/em> Is it because that\u2019s what is popular at the moment, or because it solves a problem affecting a core feature? Another aspect to take into consideration is how familiar we are with certain technologies and give preference to those we know and can start using them right away rather than having to stop and learn the ins and outs of a new framework.<\/p>\n<p>Choose the right tool for the job, which is going to be the one that meets the requirements and fits your mental model. Focus less on a library\u2019s popularity and scalability but rather on getting your app to the point where it needs to scale in the first place.<\/p>\n<h2 id=\"conclusion\">Conclusion<\/h2>\n<p>It\u2019s incredibly difficult to <em>not<\/em> over-engineer web apps given current one-size-fits-all and fear-of-missing-out mentalities. But we can be more conscious of our project goals and exercise vigilance in guarding our work against scope creep. The same can be applied to the stack we use, making choices based on what is really needed rather than focusing purely on what everyone else is using for their particular work.<\/p>\n<p>After reading the word \u201cframework\u201d exactly 48 times in this article, can we now say the web is getting too complex? It has been complex by nature since its origins, but <strong>complexity doesn\u2019t translate to \u201cover-engineered\u201d web apps<\/strong>. The web isn\u2019t intrinsically over-engineered, and we only have ourselves to blame for over-engineering our projects with overly-wrought solutions for perceived needs.<\/p>\n<div class=\"signature\">\n  <img decoding=\"async\" src=\"https:\/\/www.smashingmagazine.com\/images\/logo\/logo--red.png\" alt=\"Smashing Editorial\" width=\"35\" height=\"46\" loading=\"lazy\" \/><br \/>\n  <span>(gg, yk)<\/span>\n<\/div>\n<\/article>\n","protected":false},"excerpt":{"rendered":"<p>Web Development Is Getting Too Complex, And It May Be Our Fault Web Development Is Getting Too Complex, And It May Be Our Fault Juan Diego Rodr\u00edguez 2024-02-07T13:00:00+00:00 2024-06-12T20:05:40+00:00 Front-end<\/p>\n<p class=\"more-link\"><a href=\"http:\/\/sobre-portugal.com\/index.php\/2024\/02\/07\/web-development-is-getting-too-complex-and-it-may-be-our-fault\/\" class=\"readmore\">Continue reading<svg class=\"icon icon-arrow-right\" aria-hidden=\"true\" role=\"img\"> <use href=\"#icon-arrow-right\" xlink:href=\"#icon-arrow-right\"><\/use> <\/svg><span class=\"screen-reader-text\">Web Development Is Getting Too Complex, And It May Be Our Fault<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[],"class_list":["post-385","post","type-post","status-publish","format-standard","hentry","category-javascript"],"_links":{"self":[{"href":"http:\/\/sobre-portugal.com\/index.php\/wp-json\/wp\/v2\/posts\/385","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/sobre-portugal.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/sobre-portugal.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/sobre-portugal.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/sobre-portugal.com\/index.php\/wp-json\/wp\/v2\/comments?post=385"}],"version-history":[{"count":1,"href":"http:\/\/sobre-portugal.com\/index.php\/wp-json\/wp\/v2\/posts\/385\/revisions"}],"predecessor-version":[{"id":386,"href":"http:\/\/sobre-portugal.com\/index.php\/wp-json\/wp\/v2\/posts\/385\/revisions\/386"}],"wp:attachment":[{"href":"http:\/\/sobre-portugal.com\/index.php\/wp-json\/wp\/v2\/media?parent=385"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/sobre-portugal.com\/index.php\/wp-json\/wp\/v2\/categories?post=385"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/sobre-portugal.com\/index.php\/wp-json\/wp\/v2\/tags?post=385"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}