26 ms·

Ask HN: Why did Frontend development explode in complexity?

• cttet 4y ago
  Because it is often closer to actual business logic.
• michilehr 4y ago
  "If all you have is a hammer, everything looks like a nail." Frontend frameworks like React are used everywhere. For real web applications like Facebook, they totally make sense. But for a lot of other projects, they don't because those projects do not have a complex UI/UX and so the framework adds more complexity than needed.
• fortnum 4y ago
  This will be a posting, which either receives no to little responses or will have 256 responses within the next couple of hours :) I am sure, there'll be quite a few who'd argue that this is necessary complexity, but my take on this definitely is the latter - artificially inflated But it's not only the web. Same happened to Java in the 2000s and is currently happening to Android. Any mainstream Java job is more configuration of Spring containers with a bit of code glue sprinkled in-between than "proper programming". As for Android, just follow a couple of Android forums where plenty of people complain about such complexity and frameworks changing "by the minute" Aritifically inflated :)
  • fortnum 4y ago
    > with a bit of code glue sprinkled in-between https://ptrthomas.files.wordpress.com/2006/06/jtrac-callstack1.png?w=630 https://ptrthomas.files.wordpress.com/2006/06/jtrac-callstac... :)
  • bmitc 4y ago
    A lot of programming seems to have turned into gluing a bunch of poorly programmed and documented systems together. I miss one of my previous jobs where I got to build a lot of stuff from scratch.
  • saiya-jin 4y ago
    Well why reinvent the wheel with ie Spring in Java - you want well tested automatically scaling thread messaging bus for example, just configure existing stuff. Maybe its boring to some devs, but business like boringly stable tools, and they are the ones paying for our work. Would you like that architects reinvent 'engineering wheels' with every house, bridge or tunnel and do all feom scratch just because its more fun for them? No you want well tested reliable approach, if they are bored a bit even better. Ie nuclear power plants who have some unique hybrid designs are endless source of maintenance delays and additional costs. Software devs just have much more freedom and little regulation, for now
    • fortnum 4y ago
      Not necessarily reinvent the wheel, but not build the same glass buildings all across the world either. Your analogy is not that far off. Real world architecture is quite the same.
    • chasd00 4y ago
      Spring is a strange example. It’s main selling point is you’re not reinventing the wheel and, instead, building on well tested and operational work already done.
      • fortnum 4y ago
        That's the argument for all those frameworks.
  • wankle 4y ago
    Plumbers are vitally important, imagine flushing the toilet and poop pops out of the kitchen faucet.
• tgflynn 4y ago
  I suspect a lot of it is historical. If you go back a few years there were lots of browser incompatibilities and many limitations in Javascript, CSS and HTML. To work around those difficulties and limitations many frameworks were created. Today many of the limitations of the basic technologies have been fixed but the frameworks are still here, though probably less necessary than ever. But once people have gotten used to doing things a certain way (for example using jquery instead of querySelector) they tend not to change. This isn't unique to web development. The same thing happened with C++ and Boost, for example, where gradually the language and standard library evolved to include functionality that previously required 3rd party libraries. But I think far more work and money has been invested in web development than other areas, hence creating a bigger mess. My impression is that the actual user experience of most web sites, including the big ones like Amazon, has improved very little over the last decade, so it feels like all the effort put into web technologies has, so far at least, not produced a lot of value.
• nfRfqX5n 4y ago
  people expect complicated features
  • AdrianB1 4y ago
    Complicated features don't require complicated solutions and processes.
    • bmitc 4y ago
      Thats true, but people do crave complexity. If something is "too simple", often people, especially developers, are strangely suspicious of it being useful or competent. Present someone with something doing a couple things well but simply, you'll be normally greeted with a million comments of how it doesn't scale or give enough levers or do this or that.
      • nfRfqX5n 4y ago
        most developers are not senselessly seeking complexity
        • bmitc 4y ago
          Maybe. But they aren't consciously avoiding it either. Simplicity must be sought after.
  • eloisant 4y ago
    ...or developers think that. Or they pretend customers will care because they really want to play with their new framework. Nowadays everything is a single page app, and for 90% of website/web apps it would be better (and orders of magnitude simpler) with good old server rendering. It would also be much faster.
• AdrianB1 4y ago
  From an application manager/solution manager perspective, I see 2 main reasons and a few smaller ones: 1. more and more complex UI. Things that used to be done in a native app are now in a browser, this has good and bad parts. 2. a lot of show off from the developers side going for overly engineered solutions. Nobody likes HTML+CSS and JavaScript anymore, if there is no cool framework with tons of tooling and dependencies than they are not happy. (yes, I know, flak incoming) Other reasons are the complexity of dependency chains, the lack of security mindset by having hundreds of dependencies looking for a left-pad, the complexity coming from the testing of these overengineered and overly complex solutions, the move towards hybrid front end-back end management of state, rendering etc. There is also the overstretching of the frontend development role, now a fe dev needs to not just write the equivalent of HTML+CSS+JS but also containers, devops, CI/CD, all that jazz.
  • wellanyway 4y ago
    How much of that complex UI is managing state of the notifocations that are out to rape your brain and how much is actually useful?
• mkl95 4y ago
  > Follow up question : Is that complexity necessary or artifically inflated? Is Javascript's complexity necessary or artificially inflated? Modern frontend development boils down to a bunch of abstractions on top of Javascript.
• curist 4y ago
  JavaScript as an ecosystem and language became much more accessible than ever, with all the toolings and TypeScript, it's easier to build abstractions upon abstractions; and people love to have their own version of abstractions. It's human nature, it's inevitable.
• quxbar 4y ago
  I get the impression making a web app was considerably more difficult for a solo developer pre-jQuery. For a while we had an explosion of choices, and ultimately things coalesced around React and similar paradigms. Meanwhile the per-capita productivity has been skyrocketing as increasingly sophisticated cloud services provide everything from raw key-value storage to turnkey caching and auth solutions. Is it more complex than single-device programming? Perhaps, but the modern browsers represent a nearly universal platform with very low per-user complexity.
  • treeman79 4y ago
    Internet explorer made life a nightmare. had to have if statements around most everything. Corporate was very slow to roll out new versions. So we could get to be years behind. Things like custom Active-x apps required specific versions.
  • flippinburgers 4y ago
    Web apps used to be just html and forms so no the complexity has skyrocketed.
    • art0rz 4y ago
      Where the majority of the complexity was in the backend. Now, the complexity has simply moved. I'm quite happy I don't need to have two different codebases in different languages for most things anymore. I'm more than happy to offload it to the browser to save me some effort, time and money.
      • flippinburgers 4y ago
        You have to validate on the backend among other things. Honestly the only thing we have nowadays is flashier websites for the most part. Some very small percentage of websites actually require the tech that has been built despite the fact that nearly all engineering teams seem to push for it.
• mojuba 4y ago
  It's artificially inflated and I'm seeing this in almost all areas, not just frontend. Some of the projects I've seen could have been reduced in size multiple times with no effect on the outcome whatsoever. In one instance I rewrote a GUI app and made it 15 times smaller (!), that's my absolute record to date. Been wondering for years, so you need to actually be inventive to add unnecessary complexity, it's not that it comes for free or because of incompetence (though that too of course). And a lot of the times it looks almost as if software engineers do it on purpose, sometimes very creatively at that. Where is this coming from? Is it because we want our work to look important?
  • andix 4y ago
    One of the best examples of this complexity inflation problem I always see is the Redux pattern in frontends. This pattern comes with a lot of overhead, a lot of things that need to line up (Actions, Reducers, Actioncreators, Selectors, ...). And most of the time the applications that use it are completely trivial. If you remove Redux, half of the code is gone, it's faster and easier to understand and extend.
    • davedx 4y ago
      To be fair most front-end projects have abandoned redux now. It was for sure boilerplate hell.
      • andix 4y ago
        Tell that to European corporations. Angular + NgRx/NGXS is the de-facto gold standard there.
        • dmix 4y ago
          What were they using before?
        • wildrhythms 4y ago
          I think Observables are much simpler to grok than some hundreds-line multi-file combined reducer/actions amalgamation.
• claudiulodro 4y ago
  Because the browser nowadays is an "operating system" that needs to be capable of handling all manner of dynamic software: maps, video, image editors, games, etc. I haven't done Windows development, but I assume browser-based development complexity will continue trending towards essentially the same complexity as developing e.g. a Windows program.
  • eterm 4y ago
    TWenty years ago windows development was a lot simpler than modern browser applications. Fire up visual studio and create a new winforms project. You could literally drag and drop your way to a modest application with only minimal programming 'under the hood' for the business logic. I still don't think anything has surpassed the usability of winforms for a developer just wanting to get something done.
    • eloff 4y ago
      The browser is powerful enough now that one could replicate this if one wanted to. I don’t think it’s the pinnacle of software development, but it had some advantages.
      • sillysaurusx 4y ago
        This seems true in the same sense that every language is theoretically equivalent because they’re Turing complete: technically true.
      • jelling 4y ago
        The difference is that winforms basically had one way to do everything which expedited development because it skipped all of the infinite number of stupid small decisions and libraries that must be cobbled together in a typical SPA.
        • goalieca 4y ago
          Win32 could do it all. And in windows there was often a different way to handle things like video across each major OS version. Yet still, I feel it was simpler! Crazy!!
• spapas82 4y ago
  Why? I think mainly FOMO. When react was out with the blessings of Facebook people wanted to use the same library. Of course most people didn't really care/understand that their internal crud app for editing invoices wouldn't need that complexity. I think my answer should answer your second question: This kind of complexity is actually needed on some apps but these apps are a minority. Programmers love shiny new things and most managers aren't technically competent enough to lease them...
  • davedx 4y ago
    > these apps are a minority. I disagree with this. Almost all front-end projects I've worked on in the last 10 years or so have had some requirement that made pulling in react a better choice than trying to push back on business and/or get buy in to do everything server side. Providing users the kind of tighter feedback loops for their workflows is only possible with JavaScript.
    • zozbot234 4y ago
      You don't need to do everything on the server side. You can use Svelte or Solid.JS and have the same DevX as a framework, while compiling down to lean and blazing fast JS code on the client.
      • deleted 4y ago
        [deleted]
    • chiefalchemist 4y ago
      JavaScript in proper doses and places? Absolutely. Agreed. But that's not the same as taking on a trendy library (e.g., React) and associated tooling...unnecessarily.
    • patentatt 4y ago
      And this is why half of the internet is borderline unusable. Page layout jumping around for 5-10 seconds after what appears to be a full page load, buttons simply not functioning, and god forbid you try to use the back button. I know some expert will say none of those things have to happen and has nothing to do with react, but the reality of it is that these things are incredibly common in modern front end development, and I blame all the over-engineered frameworks.
• nailer 4y ago
  I don’t think react valued simplicity. It didn’t have an official store for years and still lacks CSS solutions out of the box but it seemed to be the only way to do components so people used it.
  • ojr 4y ago
    tailwind is the best utility css library to use with React, you can make components with Angular, React became more popular than Angular because it didn't introduce new concepts like dependency injection and stuck closer to ES6 standards
    • nailer 4y ago
      Tailwind got popular because react doesn’t include CSS in components. Angular 1 wasn’t components based and only three people ever used angular 2.
      • ojr 4y ago
        no tailwind became popular because it introduced the concept of "utility css" and was the pioneer of it, if React included css in the components it would have looked like styled/inline javascript or scss/less or css modules, developers do not write their own classnames with tailwind
        • nailer 4y ago
          Utility CSS is the mixin pattern and was widely used for a decade before tailwind existed. This confirms by believe that tailwind is mainly used by people with little to no CSS experience.
• herbst 4y ago
  I still do a mixture of jQuery and whatever I learned from modern JS. I totally missed the boat on everything else. I still render server sided, and rarely run into any issues. I can simulate any kind of asynchronity with the server trough websockets or boring but effective polling. It works for me, yet all job offers I see are looking for react or whatever Devs with rails experience. It's like JavaScript totally took over.
• davedx 4y ago
  For JavaScript, two main factors both driven by fairly mundane and well accepted SWE principles: 1) npm encouraged small, "single responsibility" packages/libraries 2) developers are encouraged to never "reinvent the wheel", leading to them to pull in these libraries without considering the tradeoffs In other engineering disciplines people are taught to consider tradeoffs more than in software engineering. The tradeoffs of depending on npm packages are: 1) You don't need to reinvent the wheel, i.e. you can build very feature-rich applications at high velocities 2) Tracking, researching, integration, maintaining, and (for longer lived projects) migrating from package-A to package-B can cost way more time and energy than you'd initially think 3) Almost all packages are open source, so maintained in an ad hoc way by the contributors to the project. Even the biggest, most cohesive, well planned projects under the umbrella of tech megacorps sometimes fall into stagnation and maintenance hell. "react-scripts", which underpins the de facto standard way to bootstrap react apps "create react app", hasn't had a patch version released since Facebook pivoted to the Metaverse. Answer to follow-up: No, you can absolutely write modern, feature-rich front-end applications without any dependencies. You'll spend significantly more time writing lower level code allowing you to render your data into some kind of view, manage form inputs, app state and routing, but if you're disciplined and determined it's totally possible to do.
• etimberg 4y ago
  I think it's generally caused by a few issues: 1. UI development is hard to do well. Throughout my career I've seen complexity explosions in C++/Win32, C#/WPF, and JS UIs so this isn't a new phenomenon 2. It's always easy to develop the correct UI in hindsight once all the requirements are known. When starting out it's hard to know what will be needed or not and this leads to overly complex solutions 3. The browser as a platform has historically been painful to use due to a lack of good standard library 4. JS in particular has a low barrier to entry, so a lot of folks start there and learn as they go. This leads to picking the wrong tool for the job due to lack of experience
  • arcturus17 4y ago
    > 1. UI development is hard to do well. Throughout my career I've seen complexity explosions in C++/Win32, C#/WPF, and JS UIs so this isn't a new phenomenon The people who complain about current front-end complexity are almost always back-end devs or people who don't touch front-end. However, almost every veteran dev who has developed UIs across many media and environments repeats your point.
  • prettyStandard 4y ago
    Long time front end developer here. This is pretty accurate. I would rank your issues a little differently though. I think what's different here from other front end development are items 4 and 3. So 4, 3, 1, 2; I guess.
• ss48 4y ago
  I think the Frontend is mostly what gets promoted by Sales and Marketing when selling the product. The complexity results in trying to exactly meet what they request, or give them enough to talk about being new in the product. Performance improvements for the most part can only take up a few lines. New features, on the other hand, can take up countless pages if needed.
• forgotusername6 4y ago
  Expectations have increased a lot in web development. When I first started working, web front ends for business applications were ugly. They were designed to do the job and nothing more. They might also be hard to use without a manual. These days the designs I get given look pretty and have simplified interfaces for the user. The designs never use native elements and often invent novel UX interactions. Back when I started, the go to front end wasn't a web app either. It was some GUI on windows which involved pretty much the same level of complexity as we have today on current web apps. So maybe the question isn't really "why did front end development explode in complexity?" But really "why do we expect front end development to be simple when asking for complex UX?"
• shivekkhurana 4y ago
  1- As @tgflynn mentioned: historical complexity The web was made for publishing text, not making rich apps. But it turned out to be exceptionally good for publishing SaaS. So we continued to pigggy back on it. Working directly with the DOM is too verbose, hence nobody wants to touch it. 2- Service oriented architecture When mobiles became a thing around 2008, normal MVC apps with some AJAX would not cut, because mobile phones needed their own UI. Hence REST based approach became more popular. Things like React and Angular (or Backbone and Knockout) filled that void. 3- UI is an evented runtime I think of UI as a small Kafka because it needs to handle events (from the user, from the browser window, from OS etc). This makes managing state tricky. To manage this complexity, the community comes up with libraries like Redux. This creates a gap for developers working at a smaller scale. With a small app, you might not run into issues arising due to event management, you might not run into race conditions. But since big companies use a particular library, small companies start using it too. This adds to the bloat. Is there a fix ? I think so. But it will include developers thinking outside the browser (or maybe the browser starts thinking outside the DOM?). Libraries like Hyperview and DearImgUI exist and are being used in production. Games are a good example. A game engine can render a complex scene with 100s of moving entities at consumer grade hardware. At the same time websites suffer when rendering large list views. At the end, FE is a political landscape. A large majority of developers and companies are happy with the current state of tooling. Unless an influential figure pushes for a better UI standard, we will continue to write React.
  • treis 4y ago
    >Working directly with the DOM I think this is the fundamental problem. The data structures you work with are different from the data structures displayed. Almost every framework out there is there to solve this problem in a different way.
    • deleted 4y ago
      [deleted]
• nonethewiser 4y ago
  Consider how desktop apps have basically disappeared. They're all in the browser now. Also, ask yourself what the difference in UX is between serving templates vs. something like React. Are you not getting something in return? There may be some artificial inflation but think about websites from 10 years ago.
• bell-cot 4y ago
  It's a combination of: - Fast Fashion for web sites. Users are kinda like kids in a toy store, always jumping to the newest & coolest & shiniest things. OR - at least the suits making the calls are far-too-often convinced that they need the newest & coolest & shiniest web site, to compete for users. - One-upmanship among young male web developers, who always want to be working with newer / cooler / yet-more-complex technology than the next guy. And how very convenient that newer, cooler, and more complex technology tends to pay far better, whether it's needed or not.
• codeptualize 4y ago
  I disagree with the premise, things have gotten a lot simpler. I think you need to make distinction between website and web application. The latter came later and is by definition a lot more complex, I assume this is mainly where the premise originates from. But having gone through building websites with frames, tables, png's for box shadows and border radius, jQuery and php based web apps, and having spend many days making my grunt/gulp/webpack config work and supporting IE, I can with great certainty say things have never been easier than they are now. Now, is it necessary [to build webapps]; Yes. Usability expectations have gone up, the level of details and polishing has gone up, more interactivity, and more sophisticated visual elements. Webapp now do things native applications could not do back in the day.
  • eloisant 4y ago
    Web applications don't all have to be Single Page Apps. That's where most of the unnecessary complexity comes from. Unneeded SPA.
    • codeptualize 4y ago
      That's not less complex, that's moving complexity to a different place with different problems and constraints.
• dmitriid 4y ago
  People wanted applications and app-like behaviour in the browser. And browsers are uniquely uneqipped to deal with that: - the core if the web has been, is, and will forever remain a system of displaying static text with a couple of images. You as much as look at it funny, and it needs to re-layout and re-render the entire screen - there's no standard library to speak of - there are no standard widgets and controls to speak of (https://open-ui.org/ https://open-ui.org/ is twenty years too late) - there are no easily accessible ways of handling state - almost every single API that the web provides is either underngineered, or overengineered, or badly designed, or all of them together - the web rarely provides a comprehensive and/or a generic solution or an API. It's a hodgepodge of one-off hacks often needed to cover deficiences in other hodgepodge hacks So, to make the web even remotely app-like, you need to solve for all these issues, and that's before you even start writing a single line of app logic. And on top of that you have language evolution and people wanting to use features of tomorrow today.
• ojr 4y ago
  Most of the state of application used to live on the backend but now that has transition to the frontend. Dealing with the state of application is difficult because of edgecases and side effects, React can handle many different domains mobile, tv, and website. Of course development will be more complex with more target domains.
• glintik 4y ago
  The main reason is easy “to plug and play” various tools, i.e react, websockets, graphql, webpack etc. That’s not related to frontend only, but kubernetes devops are also crying from complexity.
• o_m 4y ago
  I've done frontend since IE6 was the major browser. Back then most of the time was spent using hacks to work around the limitations. No rounded corners, no opacity, no grid, etc. As it got easier, with better adoption of the web standards and better tooling, frontend-devs were able to do more. But I feel as REST and GraphQL got more adopted a lot of the complexity moved from the backend to the frontend. The frontend part is easy these days, but working with the backend is the hardest part of being a frontend developer.
• wslh 4y ago
  Frontend was always complex, being web, mobile or desktop apps. It is following similar cycles from decades ago. Winamp[1] in 1997 made their own UI using custom draw in Windows because those components and level of customization didn't exist in the standard API. We can historically observe these cycles of complexity and technology changes only looking at Windows toolkits: Win32, MFC, QT, Silverlight, Windows Forms, WPF, etc. But the other reason is that we don't have stable tools and the right abstractions to build a UI/UX for dummies so there is lot of reinvention. Because nobody built a good UX/UI for dummies that hides this vast complexity? [1] https://en.wikipedia.org/wiki/Winamp https://en.wikipedia.org/wiki/Winamp
  • chrisco255 4y ago
    Indeed, the devs who dismiss the complexity are the ones least suited to solve for it.
• MrLeap 4y ago
  Most of it seems about resolving the tension between javascript, peoples opinions, the DOM, and the role of the server. Also there's the whole fractal of tool chains, transpilers, frameworks, libraries and design patterns that exploded out of people manipulating DOM strings to do something to a webform and feeling yucky about it.
• abraxas 4y ago
  90% of small and medium apps could be redone with a simple UI toolkit that gives you a box of widgets and callbacks. I built a geoscience 3D application in the mid 90s with FLTK and it was the last time I made something UI based where I didn’t feel that the UI toolkit was getting in the way of getting the work done. Assuming a lot of complexity in anticipation is the wrong approach 99% of the time.
• layer8 4y ago
  HTML and CSS weren’t designed to be general-purpose GUI description languages. HTTP wasn’t designed to be a client-server GUI application protocol. JavaScript wasn’t designed to be a serious application programming language. And the continued evolution of those technologies hasn’t focused enough on substantially changing that state of affairs. For example, a lot of basic UI controls still have to be custom-implemented and custom-styled by each app. CSS layout and styling is still a byzantine minefield. The ecosystem of tooling and libraries and frameworks remains highly fragmented. A staggering amount of manpower is being wasted away in bespoke frontend development.
  • samwillis 4y ago
    > HTML and CSS weren’t designed to be general-purpose GUI description languages Maybe not, but they are now, and are incredibly diverse in what that can achieve. > HTTP wasn’t designed to be a client-server GUI application protocol. Again, maybe not, but it is now with Websockets, http2 and webRTC. > JavaScript wasn’t designed to be a serious application programming language. Also maybe not initially but it is now incredible capable and amazingly only 50-100% slower than C! We now have WASM that let you reuse a vast amount of code from desktop too. > basic UI controls still have to be custom-implemented and custom-styled by each app Even with native gui toolkits developers are having to constantly build custom widgets for their specific use case. HTML gives us a baseline of widgets what work everywhere from desktop to mobile on all OSs. Would I like more? Yes, but what HTML gives us is the ability to build our own really easily, in an accessible way. > CSS layout and styling is still a byzantine minefield. I disagree, flexbox and grid layout are incredible and solve all the issues with the older box and float model. > The ecosystem of tooling and libraries and frameworks remains highly fragmented. True, and it can be a barrier to entry for someone new. However newer tooling such as Vite and ESBuild are incredible, fixing menu of the warts of the older tools. But it would also say the the the amount of tooling options available is a testament to the success of the web platform. > staggering amount of manpower is being wasted away in bespoke frontend development. Most people don't want the web painted in the same shade of magnolia. Plus all those supposed "wasted" hours pay hundreds of thousands peoples salaries, supporting family and contribute to a vibrant economy. The web platform is one of the greatest inventions of all time, and so incredible successful. It's so diverse in its capabilities and surprisingly performant at that. Honestly it's far better than people often give it credit form.
• eloff 4y ago
  I think the principal reason is the browser now has sufficient features, broadly deployed, that we swung back towards thick client architectures. So the frontend gets more complex because it’s doing more. It’s not the first time in the history of computers that this happened. Personally, I’m a grumpy backend developer, I don’t like it. I’m doing a side project now where I’m trying out old school server side templates (Jinja2 in rust, compiled using Askama ) with a little JavaScript to make it so I can replace parts of the page via Ajax calls. It’s so light and so fast, I’m really enjoying it so far. Pretty much all the state is on the server.
• anon291 4y ago
  As I've said elsewhere, frontend development is limited only by the limits of human imagination, whereas backend development is limited by the constraints of backend systems. For example, there is an absolute answer to 'what's the most efficient big O runtime I can achieve for sorting this data set'. There is no absolute answer to 'what is the complexity of drawing an aesthetically pleasing button and modeling its interactions to maximize user joy?'
• jlangenauer 4y ago
  I think it's something analogous to Jevons' Paradox. Jevon's Paradox, originally written about the use of coal, noted that as it become more efficient to use a resource, the end result was generally not that less of that resource was used, but in fact more. I think the same thing has happened in frontend development: Tools which were written to make development easier have not had the effect of making it easier to do frontend development, but have made it possible for outside factors (product managers, customers etc) to demand ever more from frontend devs.
  • vikingerik 4y ago
    That's it. It's induced demand. Build roads with more capacity, and more cars will appear to use them. Build frameworks with more capabilities, and more tickets will appear to use them.
• liveoneggs 4y ago
  React must be used for all websites- no matter the cost, no matter the implications, no matter the practicality. How else will you hire any developers? They explode if not writing JSX. If something doesn't work out there is yet another react-centered solution to your problem. Server side react can probably fix it. Tailwinds can fix that other thing. These websites must, obviously, be hosted on kubernetes clusters. They must also be behind three or more load balancers. Never attempt to cache anything. Redux is managing state and state can't be cached. I realize you didn't say "React" in your question. redis has to be installed, even if not used.
• gilbetron 4y ago
  There are a lot of salient points made in this thread, but one other aspect is that frontends are the end of a dependency chain, that is roughly like pipelines->databases->middleware->webservers->frontend. The tail end of such an architecture can be more easily change, because less depends on it, usually the only thing is the user's eyeballs. In that situation, more variety proliferates because there aren't as many constraints. Less constraints usually translates to a diversity of approaches, which is what we see in the frontend world.
• myth2018 4y ago
  Anwering Q1: a number of reasons, the most important being: 1) programmers' immaturity, we're always looking for new toys; 2) excess of venture capital fuelling too many new projects, opening space for new stuff to be used instead of the old, stable and boring ones; 3) product/design people asking for increasingly insane UI frills, influenced by trends started by big tech's products. Q2: it depends. If you think of what users need and pay for, yes, it is HUGELY inflated; if you think of the actual requirements we receive, maybe it's not that inflated -- at least part of this complexity is needed in order to build such truckload of eye candies. It's so disheartening to see such a gigantic waste of effort. But that's the current state of our field.
• hirako2000 4y ago
  Because expectations have gone up and a developer can't even take on coding some pages without prior input from some UX enginner who is likely assisted by some UI designer. Because we don't have just 1 or 2 desktop web browser mostly rendering text anymore. We've got 3 or 4 major browsers that most managers want to support all, even though one has over 50% user adoption, and could be installed within 2 mins if not due to IT administrators locking everything in and shipping almost nothing to browse the web. Each of those "major browsers" with their own same but not the same implementation for mobile, across many different sizes from tiny low rez screen to worry about to phablet/tablet factors, that can rotate of course, so landscape and portrait please, packing videos, photos, and scalable graphics often within the same visible area. One would think that's enough headache to deal with, but fonts aren't treated equals, and remain proprietary so text won't be the same across windows, linux, OSX and android. No. You may pick one system font that is called the same so should be the same, but it isn't actually the same, at least last time i checked it wasn't. Oh, and the highest speed consumer bandwidth out there is something like 400Mb/seconds, and the lowest might well be a under 100kb. Both want the best possible, so full HD clip and MB pixels pictures for one, and low def steaming and scaled down pics for the other. And throw something in between to make the average bandwidth users also happy. Oh, and since we got the cloud and aws is "cheap" demand super quick agile delivery of course. Co pilot and soon gpt codex will make it no-excuse to be late on those over optimistic estimates.
• cplusplusfellow 4y ago
  I think the better question is why haven’t we made front end development toolkits less complex (by pushing a lot of the complexity into the browser itself)?
• indymike 4y ago
  It didn't. It just moved to the web. User interaction Is lots of edge cases.
• toldyouso2022 4y ago
  Tech companies get a lot of subsidies (directly and indirectly) so they develop inefficient practices. When people don't have profit and loss incentive, where incentive means they are not removed by the market due to losses, human psychology tend to favor bigger, complex things.
• orwin 4y ago
  Question 1: On average, yes, but not as much as people think. Question 2: both? I started my "career" with an internship job where i had to write deploy some cakephp+sencha extJS with windows server 2004 and IIS (~2013/2014). The frontend part were "easy" but tedious, it was tables upon tables, a bit of jquery just because, absolutely hideous css (i think at the end i added bootstrap twitter classes on Sencha extJS). the "backend" was handled a bit like today, with a bit of backend work in the "View" part of the MVC (because Sencha ExtJS). Hard to find bugs induced in this "backend" work, because the only tooling you had were the old devtools, the only documentation you had with the official one (and a bit of SO/blogs, but not that much), and since typescript didn't exist, you had a lot of weird type/casts bugs. I recently started a new job were i also have to do some short interfaces for my step functions, served by lambda (mostly). I had to learn react and typescript from scratch, and thought i wouldn't be productive in months. I was productive after a week, and after a month could confidently say i'm fluent with React router and props, and passable with typescript (Complex union type threw me off for more time than i like to admit). I still don't know if i understand ExtJS :/ By the way: the documentation isn't that much better now, with all the shitty blogs and stuff like "tutorialpoint" on google frontpage, but you can search code patterns through github and gitlab, and this help immensely.
• cjf4 4y ago
  Most of the answers here are pointing to things like inefficiencies, short-sightedness, and over engineering, but I'm not seeing the positive side. The web is an incredible distribution channel. With decent engineering, anyone can make an app that has access to an enormous marketplace with very little capital costs. The past 20 years of software have been dominated by this distribution model so it's easy to take for granted, but compared to pre-web distribution that involved manufacturing and much larger differences in user platform, it makes sense that the world is trying to squeeze as much software as possible into this model. With that comes complexity.
• trashburger 4y ago
  Some scattered thoughts: Just today, I built a complex order editing form in vanilla Javascript with AJAX. It's over 900 lines of Javascript where half of the code is state management boilerplate, painstakingly ensuring the correct effects are run when the user changes an order line's quantity or picks another product. We currently can't use libraries with our stack, so it was necessary to write it like this, but it made me yearn for the frameworks. The frontend landscape isn't more complex than it needs to be, it's as complex as we need it to be. We take many things for granted in our modern stack. Sure, Javascript has come very far in many areas, but it also lacks many things that are regularly needed and the tooling covers for that. Things like state management, functional composition of layout and form validation are things that Javascript simply doesn't (and probably shouldn't) provide, and that's why we have libraries/frameworks for those. I see many people bashing on Redux in the comments section. Redux can be overkill if you're writing a single-page (like, actually one page) website, but as soon as you need to manage user credentials and state that needs to be persisted across many pages (think shopping cart), Redux becomes indispensable for me. Sure, you can use something like useReducer, but it doesn't really compare once you add redux-toolkit to the equation. I agree with the general sentiment about the npm ecosystem. Like with anything else, taking "don't reinvent the wheel" to the extreme causes chaos because the entire world is not a monorepo and we have to rely not breaking one another (which fails often). My rule of thumb for whether I should reach for an npm package is "can I write this correctly and with tests in an afternoon?". Things like arbitrary-precision decimals fail that test, but many others simply go into utils.js. To summarize my thoughts and make myself a bit more coherent: The frontend tooling is as complex as we need it to be. Evaluate what you need and build your stack with that. Don't join any cargo cults, both for and against framework use.
  • aka878 4y ago
    “We currently can't use libraries with our stack” Interesting. Could you share the reason?
    • trashburger 4y ago
      I misspoke, meant we can't use frameworks. We have Webpack setup, but the HTML is currently Django templates, and the project right now has too tight a deadline to reshape the frontend into something that more conventional frontend frameworks expect.
• jackconsidine 4y ago
  A host of reasons but it's my opinion that the calculus of what you can develop for what resources simply workout, and that math trumps the regrettable bloat that a portion of the population notices. You can look at the complicated tooling of '23, the increasingly niche roles ("React state management expert"), the bundle sizes, the expanse of the browser spec and wonder how this trend is sustained, but there's a flip side to all of this: it's easier today than ever to develop well-utilized, sophisticated software with a team. That last part is important- since teams build most of the well-trafficked web applications out there it will be the limiting factor in economic equations. And all this specialization and bloat is conducive to concurrency (see Conway's law [0]). I'm reminded of an Economist article I read that asserted that better engineering often doesn't solve a traffic problem since the pain of traffic will approach the threshold of what people will tolerate. People who don't drive because of traffic start driving until the commute is nearly the exact same. [0] https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law
• izietto 4y ago
  Because browsers don't support server-side declarative views natively yet. FE development wouldn't even be a thing if web servers could respond with something like <script> const [count, setCount] = useState(0); </script> <template id="counter"> <div> <p>You clicked {count} times</p> <button onClick={() => setCount(count + 1)}> Click me </button> </div> </template> <counter></counter>
  • nassimsoftware 4y ago
    Would it be possible for browsers to support this? Is it not currently the case due to some constraint? What would be that constraint?
  • itworkslikethat 4y ago
    But... This is FE development, you think the backend devs would like to be writing this? Back when we all did MVC we had FE and BE devs anyways.
    • izietto 4y ago
      Follows my experience. Context: I'm a Rails full-stack developer, I started developing web apps 12 years ago. I still consider myself a full-stack developer, even if I'm a BE dev right now, since now we have FE and BE in the company I work for. 12 years ago, there were no FE/BE devs: there were only full-stack devs. We used to struggle maintaining tons of imperative JQuery/Prototype/MooTools/you-name-it JS code built on top of server-side declarative HTML. It was an hell of development/maintenance. Imperative code was pretty easy to write at the beginning, but after 2000 JS LoC you had half of the view implemented in JavaScript. end-to-end testing tools were almost inexistent, so there was no way to avoid regressions on the messy JS code you wrote. After 10000 JS LoC you were pretty f*ked. This workflow was unsustainable for any web app that aspired to appear "modern". In a couple of years, FE frameworks (AngularJS was the first among popular ones) started facing this problem. They offered you a declarative way to implement dynamic HTML views. Moreover, companies killed two birds with one stone: they could totally divide FE and BE, so to hire way more developers as junior developers are better suited to work for FE, and reserve the senior ones, with more experience and better payed, for BE. This is another crucial aspect of BE/FE devs division. Now, to answer to your question: > But... This is FE development, you think the backend devs would like to be writing this? We (BE devs) had done that for years. But now we'll fight hard against going back to full-stack, but only for our advantage: in this way, we can get treated way better and get payed way more.
• deostroll 4y ago
  Complexity is one end of the spectrum. Browser APIs for various stuff like animation, video, audio, webgl, etc is not that easy for developers to consume. Often most of these features have their own set of sub-complexities and concepts. For e.g. drawing/animation on the canvas is relatively simple, than doing stuff with 3d animation; the latter involves lighting, viewer perspectives, etc. And developers don't need all of these browser features every time; much less for the same project. But from a framework POV those features need to be there. Because, as a framework developer you cater to a relatively wide developer profiles. So far we've talked about browser APIs and how a framework seems to lend support to them. Building web apps are a whole different affair. When concepts such as optimization, and, page-load speed kick in you'd definitely think of tools that abstract away the common chore of such optimizations. Again these optimizations have their own set of options, and, hence complexity. So today the whole affair may seem complex. But really its not artificial. There was a need and hence a solution. To anyone relatively new to web development all this might seem complex. And at some level, even we humans also unjustly decide we need to have some features because "others are also doing it". This also increases complexity in maintaining those solutions. Bottom line is, it is a relative illusion, and, it just echoes the state of modern browsers, and, modern web development trying to be vogue.
  • deleted 4y ago
    [deleted]
• Sakos 4y ago
  There are a lot of great answers here, I'll just point out one thing that I think is important. It feels like a lot of the complexity around frontend development comes from managing and maintaining state, particularly between different components. State management is easy when you just have a single JS script embedded in HTML. But when you decide you want a structure that is more class-like where you can reuse components, it's suddenly incredibly difficult to share state between components and ensure changes (no matter the source) are propagated reliably and are also properly reflected in the DOM. You have this whole other layer in HTML that is awkwardly and haphazardly bound to the JS side which just makes things so much more complicated to the point where React makes its own DOM instead.
• Apreche 4y ago
  At first, only devils used JavaScript. Then jQuery/AJAX/Web2.0 made it permissible for it to be used for good. Then Apple killed Flash. Clients and employers still demanded fancy web sites that weren't just hypertext and images. Browsers still only supported JavaScript. Node and npm enabled front-end devs to build and share. All the tiny problems that front-end devs used to deal with, like minor browser incompatibilities, were papered over with layers and layers of abstractions until they naturally ended up with frameworks like React/Vue/Angular. Then the cart came before the horse, and there has only been incremental progress since then because JavaScript is still JavaScript, and the ecosystem is too big to escape. Anyone who tries to avoid the complexity of the existing front-end tooling soon finds themselves reinventing many many wheels.
  • hn_ltl-ftc 4y ago
    May I take advantage of your (presumed) typo, to henceforth refer to myself as a JavaScript Devil? That's good enough for a business card/avatar tag/equivalent, IMO--yeah, I love it!
    • Apreche 4y ago
      Not a typo. In the ‘90s JavaScript was only for devils who tried to make annoying pop-up ads and such.
• clever-leap 4y ago
  Because many devs now specialize only in frontend and many succumbed into new ideologies of what is right - like using React and Webpack instead of seeking simplicity in design.
• 5350-uiop-1130 4y ago
  i think, in order: 1. the mainstream adoption of AJAX 2. node + node development community (top 5% of node/npm contributors - also Google see 4.) 3. agencies trying to sell over-engineered BS to their clients 4. Chrome/Google 5. influx of non-CS/nerds into FED (commoditization of knowledge, process and perceptions.)
• lagrange77 4y ago
  I'm not planning to join the 'artificially bloated vs. necessary' debate, but i think the web platform is a very open platform. Sure, there are highly complex toolchains for the web, but you are not obligated to use them. If you want to, you can use vanilla JS (if at all), raw WebGL and even Wasm.
• soft_dev_person 4y ago
  Because complex applications are now delivered as web apps instead of as desktop applications, and these require complex tooling to maintain. Then everyone wanted to use the same tools in other areas (I guess), where it is probably not necessary in a lot of cases. You see similar trends elsewhere (e.g. cloud, k8s), perhaps CV building is the real reason. Then again, a lot of the complexity is mostly optional these days. But knowing how to avoid it is tricky, given the amount of tutorials online that will happily convince you to use webpack, redux and whatever else that was made for bigger problems as if they should be used everywhere. I don't envy young programmers these days, the amount of stuff to wade through is just mindblowing.
• dec0dedab0de 4y ago
  Because we took a platform for linked documents and grew it into a platform for applications. If the web were still documents, or if it started as a platform for applications, then it wouldn't be as complex. Another reason is that the languages and tooling to do these things are always easy to start and painful to master, leading to too many sort-of capable people dreaming about how to do it better.
• mike_hearn 4y ago
  In many cases it's probably not necessary. There's a lot of low hanging simplification fruit available in at least two areas: • Internal/enterprise apps. Instead of writing a full web app write a desktop app using one of the many new frameworks for it and connect directly to your database. Use views, row level security and other RDBMS features to implement declarative ACL logic, and stored procedures as a thin RPC layer when necessary. Benefits: eliminate the whole web tier, no SQL injection (users log into the db as themselves), no load balancers (client side can fail over between replicas), use non-JS languages over the whole stack without transpilation, give users ultra-low latency UI without lots of work, feed output of your SQL library direct to the UI toolkit, no browser compatibility bugs. • Eliminate mobile/web duplication. Use Jetpack Compose/Kotlin Multiplatform/Flutter/etc to bring your mobile app to desktop and keep all the frontend codebases synced. If we assume by frontend you mean exclusively web apps, complexity seems to have come from several places: 1. A desire to use something better than JS (typescript, coffeescript, kotlin, whatever). 2. HTML5/JS's failure to provide a components model leading to it being layered on top with npm, webpack, react, etc. 3. A desire to eliminate state-management related bugs via FP techniques. 4. A much wider recognition that latency is important, causing practices that were once routine to be now officially frowned upon and creating piles of complexity through optimizations. 5. Assumption/desire that websites will work on mobile/tablets, even if a native app exists, causing a lot of work for responsive design. 6. Lack of anyone other than Google incentivized to really improve the platform, causing an explosion of tiny GitHub projects that each seek to solve a micro-problem which then get cobbled together into ad-hoc per app "frameworks". Compare to the Apple stack, the Microsoft stack, the Android stack, the Java standard library etc where a lot more stuff comes out of the box and they try to solve app development end to end. The question of whether this complexity is necessary is always relative. Many apps have a captive user base who are much more sensitive to feature throughput than looks or how quickly the app loads. Things like server side rendering+rehydration are just a distraction there but they often come along for the ride due to the industries preference for using FAANG freeware over buying platforms that could then be more tuned for the customer need.
• askthrowaway 4y ago
  Frontend is inherently complex and becoming more complex because we build more dynamic web apps. PM and designers don't know what works and keep changing the product until they get something acceptable, which will also mean much more moving parts for developers until the product matures. The complexity will stay and get bigger, we need to a way to control it and be able handle it. The first step is to abstract frontend development (be it web, mobile, desktop or even VR) into concepts then introduce a system to build apps with these concepts.
• WandaVision 4y ago
  Unpopular biased opinion. Frontend development is mostly done by people who are into visual things and less into logic. Unlike backend engineering, where people working are primarily choosing technology based on logic/merit and less by visual appearance. This leads to the adaptation of large number of garbage frameworks in frontend primarily because their landing pages look visually appealing. After some time frontend developers will find some new framework with a better landing page and move on to that. And the cycle repeats.
  • lagrange77 4y ago
    What garbage frameworks are you referring to for example? The popular ones i know involve a fair amount of logic and real SWE, aiming to free the visual guys from implementing their own garbage code.
  • oliwarner 4y ago
    You're discounting interface work. User experience, etc. That isn't just making things pretty, but finding the best ways to display data, get input, etc.
  • tjansen 4y ago
    Hmm... in the early days of HTML+CSS, there were a lot of visual people in the field. Some of them wrote some JavaScript, but stopped when things got too complex. These days they are doing UX design or create designs in Figma, and don't really touch code anymore.
    • adql 4y ago
      Many of people that did only frontend (HTML+CSS+JS) also moved to full stack, with usually dreadful results. From manager POV it's great, they don't need to manage 2 teams and can move people from frontend to backend as needed. and then you end with chmod 777 like in old bad PHP days. But hey we put that in container now!
  • karaterobot 4y ago
    > Unlike backend engineering, where people working are primarily choosing technology based on logic/merit. Sometimes I wish I could do the crying-while-laughing emoji on HN. Backend devs have biases and get tricked into making the wrong choices just like everyone else.
• rubyfan 4y ago
  mid-2000s I think it all started with the rise of AJAX and "Web 2.0". In the beginning it was just sort of gimmicky for visual effects and experience and we were all scratching the surface of what browsers could do. 2006-2009 server side frameworks were in vogue but most were slow and sometimes memory intensive. In the pursuit of creating highly interactive experiences that also scale many of us were optimizing website architectures around cached components of varying vintage and write frequency. By 2009 we were solving for performance + scale + interactivity challenges using client side rendering for highly interactive components. During that period I can remember doing isomorphic rendering of mustache templates in server side Ruby and client side Javascript. 2010-ish Node was starting to gain traction and lots of attention went to Javascript. I think post-2010 many were pushing web app architectures to more client side business logic as web browsers became more and more capable. Backbone.js, SproutCore (now Ember.js), Knockout.js and others were on the scene by then and I think most other frameworks are inspired or derivative approaches meant to solve for their shortcomings. 2014-ish I think everyone was pushing responsive web. Apps got fatter and needed CDNs now more than ever. Websockets start to gain maturity. Cloud-services really start to gain traction beyond EC2 type deployments. 2015-2016 is the inflection point where client side frameworks start to get stupid complex, i.e. I can no longer read the source code of a web page easily, simple read only sites have a loading screen and/or need to download 1MB+ for reading a basic page.
• rajangdavis 4y ago
  To summarize my experience, state is hard, phones got introduced as a target, and browser code became fun to write. Is the complexity artificially inflated? It depends on the app you want to make.
• azangru 4y ago
  > Why did Frontend development explode in complexity? The browsers became more capable (as someone said in another comment, they are effectively shooting for operating systems now), and more ambitious projects became possible. Consider such web apps as: - Google Maps - Google Docs - Google Meet - Youtube - Adobe Photoshop online - Figma (or Penpot) - Miro (or Mural) - Excalidraw (or diagrams.net, or lucid charts) - Slack (or Discord) - ...etc > Is that complexity necessary or artificially inflated? This entirely depends on the product. You need the complexity for some products; and not for others.
• haspok 4y ago
  I recently transitioned to a "full-stack dev" role (using React on FE), and honestly, it is much _simpler_ than I expected. I had the opinion before that FE is lacking the breadth of BE development, but of course, without actual experience in the matter I might have missed something. Now that I'm 2 months in, I still don't see the complexity, actually, if anything, React makes stuff so much _simpler_ due to its leaning heavily towards FP (to me, the class-based approach of React seems more complicated than the hook-based, for example, deciding what `this` points to at any given time in Javascript is no small feat - with functions/closures, you don't have this problem). There is depth for sure, handling all the possible errors and edge cases requires care and attention, just like in the BE. To me the only shock so far was how low level all the stuff is, I mean come on, we had Delphi in the past millenium already, creating a form with a text field and connecting it to a field in a data structure was a solved problem back then... a "one liner" if you will, now you have to independently manage the state and handle events for each field? Come on, there must be a higher level library that solves this!
  • chrisco255 4y ago
    There are probably 15k npm libraries that solve that very thing. I think this is part of what people struggle with and complain about WRT web dev. There are so many choices for libs and frameworks it can be hard to know which one to pick and which dragons you'll find along each path. FWIW if you're using hooks and React, React Hook Form is good: https://github.com/react-hook-form/react-hook-form https://github.com/react-hook-form/react-hook-form
• zitterbewegung 4y ago
  Frontend development has risen as an alternative so that it's much easier to not program for native frontend system but instead hiring "fullstack" developers and or purely frontend developers. The complexity of these frameworks correspond with applications that are either web first and or electron based. The complexity is necessary in certain situations but at this time it is very artificially inflated because of the fact of ease of hiring and that most people and or frameworks that propagate by word of mouth or just following what others in the industry do.
• deleted 4y ago
  [deleted]
• tjansen 4y ago
  Back in the days of mostly static HTML, and maybe some simple JS for effects, you didn't need much complexity in the Frontend. Most logic was in the backend. That logic has moved to the Frontend, and so has the complexity. Yes, Frontends are more complex than ever before. But at the same time, backends have never been simpler. Most backend devs just implement some simple CRUD APIs for the Frontend code. The UIs also have become more complex. In early web apps, you submitted a form and got feedback only after submission. The expectations for modern web apps are much higher. Everything has to be evaluated as soon as possible, possibly while the user is entering it. Responses should show up immediately, so there is a lot of caching in the frontend. It all adds up.
• adql 4y ago
  first v8 for speed then node.js - it allowed to do complex code generation stuff to happen on backend and on one side erase some incompatibility problems, on other to just do stuff that wouldn't be possible if JS was only run on frontend. We also got faster machines that could handle the buckets of garbage average JS framework asks browser to do and internet speed that made 2MB JS blob the norm and not something you'd be fired over.
• perrygeo 4y ago
  The question itself might contain a partial answer. If "frontend" and "backend" are assumed to be two completely separate disciplines, the architecture is going to reflect that (Conway's law). It's possible that building a website as a wholistic product (ala Ruby on Rails) is inherently less complex because it eliminates an artificial boundary. We see backend teams struggling to build APIs and frontend teams struggling to consume those APIs. Many of the technical problems, communication overhead, and complexity seem to lie at this API boundary. Consider what if the software team (singular) just created HTML UIs directly from the DB and eliminated the middleman? I'm looking at things like HTMX and phoenix live view as a potential solution.
  • wankle 4y ago
    "Consider what if the software team (singular) just created HTML UIs directly from the DB and eliminated the middleman? I'm looking at things like HTMX and phoenix live view as a potential solution." In the enterprise, data transit, processing and management architecture is more complex than save this text in the database; just as decent UI and UX is more complex than a text field and input button.
    • gls2ro 4y ago
      In the enterprise sometimes things are complex and sometimes things are getting complex when you take a team of 100 people and ask them to build a new system they will build a huge system and discuss for months about reliability, error handling, remote storage, and a lot more needed systems. Each specialisation will define some constraints that will only be needed when their system is 3 years old but present it as if you dont start with that it will be hard to add it afterwards. Thus if you ask a 100 people department to create a new web app it will create a web app that will provide enough work for 100 people.
• rjha 4y ago
  * The increase in complexity is unavoidable as well as accidental (creep due to marketing). Some of it is necessary to address the increased sophistication of the web. Just compare what we can do today to what we used to do in 1996 with cgi and perl. * It is not that native GUI libraries like Qt or SDL or GTK are super easy. GUI are event driven and composed and need to be in sync with the user wishes and as such have a programming model that is different from a top to down execution of instructions. * The biggest challenge with the current state of front end development though is that there are no standards and no stability on a YoY basis. What I learned to do with PHP in 2005 is still valid. I can still use those tricks and whip something useful. What I learned to do with tables in mysql 3.x is still useful with mysql 8.x. However the world of Javascript frameworks is one of shifting sand. What I learned with Javascript framework X.1 will be obsoleted by X.2 and will be obsoleted by X.3. No guarantees for time investment is challenge #1. angular 1.x -> 2.x, Vue 2.x -> 3.x are some examples that come to mind. Think of all the wasted effort. That is the killer. Humans are good at making peace with whatever crap is thrown at them. I do not think technology is the reason here. It has more to do with hype cycles and trying to catch developer's attention in a competitive market with new buzzwords. * There is a lack of simple tools like what visual basic used to do. Sure, everything is async and we are in an event driven world but frameworks could have provided a common core to enable simple use cases. bootstrap library is a case in point. I can get decent results with bootstrap without knowing the intricacies of css. However I am hard pressed to find a suitable Javascript framework.
• BartjeD 4y ago
  In my opinion the complexity is caused by the amount and the combination of technical choices, design choices, and process pipeline choices. ... Long story short is that a web app is cross-platform (browser) program and that very quickly gets quite complicated requirements. Of which security, dependency management and frameworks are a big part. Because you need to know about them, and how they work etc.. Long story / ramble: A simple static website can be as simple as a bit of HTML with CSS. But when you introduce workflows and users it isn't long before security comes around the corner. And that introduces a lot of complexity, which frameworks and packages help with. (Don't roll your own) So the security packages comes with typescript. Which makes you adopt typescript and adds a bit of complexity over JS. (But also typesafety! I'm a fan FYI) And then you want the website work as a progressive web app, so you need a service worker. More complicated. You then might want to add some sort of isolation of CSS, or use Sass or some other framework. To help with code re-use and avoid breaking things as the app gets larger. Also more complicated. Then your PO says you need to have async workflows and let the user know when something starts and is done, with push messages. So you need a background worker and push messages. And we're not even talking about the technical issues, like not all browsers supporting certain API's or certain styles. Or updates to package X breaking package Y, needing a package patch. Not to mention keeping up with the evolving syntax and language capabilities. HTML, Javascript, Typescript, CSS, SASS etc... They all keep changing and evolving.
• Xeoncross 4y ago
  'Backend' work has had longer to be refined. Backend developers are much more likely to pass leetcode and algorithm questions and have decades and decades of material and languages to draw from. We don't use 1st generation stuff to build anymore. Once 'frontend' (i.e. browser dev) has close to that much time to cook we'll have a lot better experience with typed language support native in browsers and/or a proper green threads. I mean, just look at everything that came out of the past ~10 years alone: Coffeescript then Typescript, LESS, SASS, most bundlers, push notifications, webworkers hot reloading, websockets, webrtc, SSE, free/default-on certs, all the component frameworks like bootstrap, tailwind, material ui etc... While browsers have been around for a while, the ability to use the browser as a full-featured UI is pretty recent and most people working in this area seem to be pretty young.
• grumblingdev 4y ago
  Transpilation. Imagine if TypeScript/JSX was available native in the browser requiring no transpilation step, and we dropped support for any package requiring some exotic transpilation. You could easily step through your entire codebase first and thirty-party without battling source-maps or minified files. Libraries that required adding a compilation step and a complex dev server would be shunned. Having this compilation step in place means it's easy to just pile on tons of functionality, import hooks, AST transformations, etc. which causes the complexity.
• remote_phone 4y ago
  Too many different platforms to support which causes engineering issues. For web, you need to support multiple browsers and infinite number of screen sizes. For mobile, you need to support iOS and android and multiple different OS versions and screen sizes. You also want to minimize platform-specific code, which often causes you to roll your own way of doing things. From an engineering point of view you don’t want your code based to diverge, which would cause supportability issues and/or lengthen and complicate developing new features. It’s basically a nightmare for any moderately successful company that doesn’t want to alienate any customers.
• ceres 4y ago
  There are two reasons I can think of: 1. The most popular front-end frameworks (e.g. React and Angular) are created by large orgs which naturally leads to extensive codebases as they’ll need to have many use cases. 2. Every new and shiny front-end framework is good for job security since having it on a resume makes you more hireable. I suspect it’s also why some developers practically force startups to switch their front-end codebase to the next shiny framework - resume padding. As a solo dev I wasted a few years using (and hating) these new frameworks for my Django projects because it’s what everyone was recommending. Then it hit me when I realized that they were meant for large dedicated front-end teams to increase their productivity. If you’re a solo developer, they actually hurt your productivity. That’s why I’m so happy with htmx. I can get my sanity back!
• imnotreallynew 4y ago
  Related question: what would the folks here recommend for someone that wants to keep the frontend “stupid simple” while not resorting to writing everything in pure HTML/CSS/JS? I’ve heard mithril.js recommended before but I’ve yet to try it. I have experience with Angular, React, and a bit of Ember and the amount of code and “magic” involved is absurd.
  • sibit 4y ago
    Personally I've had great success with adding Web Components to server side rendered projects. It's really simple to just bind a class to the custom element and attach a few event listeners. If you need something a bit more complex rendered on the client side you can use mithril or similar libraries like lit-html. When I need to hydrate a state I JSON encode the model as a data-state attribute and I decode it when the Web Component's connectedCallback method fires.
  • wildrhythms 4y ago
    I've been enjoying building Web Components via lit-html for my recent projects: https://lit.dev/docs/v1/lit-html/introduction/ https://lit.dev/docs/v1/lit-html/introduction/
  • nfRfqX5n 4y ago
    React is simple
• drbojingle 4y ago
  The shift from thin client to fat client forced the frontend to deal with greater state, sync and cache issues. The build ecosystem has multiple steps and langs. The visual fidelity and complexity of UI makes it difficult to test requiring us to deal with e2e testing with new tools. All that to say this: we wanted cutting edge language features, beautiful UI and didnt want the page to flash white when we did something so we stopped switching pages and handled state on the front-end. Not sure it was all worth it tbh.
• asciimov 4y ago
  XKCD 927 - Standards - https://xkcd.com/927/ https://xkcd.com/927/
• beardedman 4y ago
  The lack of objectivity around this is absolutely astonishing from a community such as this. It exploded with complexity because frontend complexity exploded. Simple. Absolutely no people expected an "API call" from a frontend application 20 years ago, now people expect loading indicators on buttons (that make API calls) after pressing them. Just have a look at the comments on the recent Standard Notes / React Native post. https://news.ycombinator.com/item?id=34197613 https://news.ycombinator.com/item?id=34197613
  • satyrnein 4y ago
    In my experience, people don't start out with the goal of loading indicators on buttons. It's usually the mistaken idea that avoiding a page reload will make the action faster. Instead, you now have a slow Ajax call, and the button appears broken, so now it needs a loading indicator.
    • chrisco255 4y ago
      "a slow AJAX call"? What is even meant by that. Async JS is not slow. It's only limited by the user's connection speed and amount of data to be transferred and server response speed. This is a few dozen milliseconds but can be optimized down to sub 10 ms (the server and latency is the bottleneck not JS). A full page reload will of course take longer because instead of one tiny JSON object you have to send the full HTML back down the wire, and the screen also completely repaints and sets up a whole new DOM structure in memory for the same components.
      • satyrnein 4y ago
        I was referring to the server being the bottleneck, as you mention.
  • hbrn 4y ago
    A slight caricature of your take: It took us 20 years and immense complexity to start displaying loading indicators on buttons.
• blueprint 4y ago
  because people didn't learn properly how to build object oriented code with objects. instead they made up the excuse that it's implicitly complicated when in reality they just aren't very good at factoring
• milansuk 4y ago
  Sure developers have a hard time handling all that HTML, CSS, Javascript and connections(DOM, etc.) between them, but I see a much bigger problem in browsers. There are actually only a few browsers and most of them are based on chromium(or Webkit). Why? Because web standards are huge! Their complexity is so big, that even great programmers have a hard time creating browsers from scratch. The latest example of this is probably Ladybird[0]. Andreas Kling and others have worked on it for years("Just under 1000 days for a bunch of hackers to build a new JavaScript engine"[1]) and they know it will require way more time to just catch up the Chrome[2]. A year ago I started to build SkyAlt[3], which doesn't have anything to do with the web. It's not just a browser, but also an IDE where you can create apps with few lines of code or just drag and drop stuff on canvas. It's written in C and it's only 25K LOC. Compiling takes a few seconds and binary is under 1MB. There are tons of features that need to be built, but I like its simplicity(relative to the web). [0] https://github.com/SerenityOS/serenity/tree/master/Ladybird https://github.com/SerenityOS/serenity/tree/master/Ladybird [1] https://twitter.com/awesomekling/status/1596783757125898243 https://twitter.com/awesomekling/status/1596783757125898243 [2] https://twitter.com/awesomekling/status/1595387284035145729 https://twitter.com/awesomekling/status/1595387284035145729 [3] https://github.com/MilanSuk/SkyAlt https://github.com/MilanSuk/SkyAlt
  • wildrhythms 4y ago
    Well said. I've been following Andreas building Ladybird, and it has been an eye-opener to see the complexity of what is effectively an operating system built on another operating system.
• peterhunt 4y ago
  Early react team member here. The popular react/webpack/npm stack is probably what the OP is talking about. It was popularized because the Instagram web team used webpack and npm in 2013 so we recommended it alongside react in the early days. I was TLM of the team when we made these decisions. There are three main points I want to add to the conversation. 1. UIs actually have a lot of complexity. The number of states they can be in is often higher than what you see in other disciplines of software engineering. They also have to contend with managing data fetching over unreliable networks, including balancing bundle size. Additionally they are notoriously hard to test because “does this feel right to a user” is hard to encode programmatically. 2. The grass isn’t greener on the other side. I see a lot of people complaining about the needless complexity of the frontend stack but I don’t think they’ve worked in a modern backend engineering or data engineering project. Modern backend eng is a morass of kubernetes configuration, needless microservices and overuse of async queues, for example. Feels a lot like frontend in terms of accidental complexity. So I’d argue that this is less of a frontend problem and more of an industry wide thing (cynically, it might be a ZIRP thing) 3. With that said there certainly is needless accidental complexity in frontend and I am convinced content marketing is 100% to blame. An easy way to hire engineers is to create an open source project and write a blog post convincing people to use it. This is good for the company and good for the careers of the engineers who worked on it, but can cause people to needlessly complicate their tech stack if they can’t cut through the noise.
  • _8j50 4y ago
    What is ZIRP?
    • peterhunt 4y ago
      Zero interest rate policies :) Sometimes companies have too much money and they overhire.
      • rubyfan 4y ago
        I think you typo'd Zero interest rate policies https://www.investopedia.com/articles/investing/031815/what-zero-interestrate-policy-zirp.asp https://www.investopedia.com/articles/investing/031815/what-...
• c-smile 4y ago
  I would not say that Web UI is that more complex than desktop UI. In principle. It is media that changed quite a lot - spectrum of devices that we need to show our UI on. We had pretty much fixed 80x24 character terminals, then we had 640x480 pixel grids, sometimes 800x600 and more. But at that times you can still assume that pixel is presented to the user as a square of 1/96 x 1/96 of inch. Such fix allowed us to use UI designs nailed down to pixels grids. That was time of flourishing WYSIWYG UI editors. Alice, designing her UI in Delphi (or VB) editor, can be sure that Bob will see it in the same way. Her cool 16px icons and bitmap fonts will make Bob and friends happy. When we needed some "extremely cool" stuff at that time we were providing bitmapped skins. Remember WinAmp (https://skins.webamp.org/ https://skins.webamp.org/)? Time is passing by and we have now huge variety of devices with different pixel densities (96ppi, 192ppi, 300+ ppi) and pixel grid sizes - from watches to wall sized TVs. But we still want to show the UI on all of them in reasonable manner. The solution is to change paradigm an so to use a) vectors for UI definitions and b) flexible/adjustable UI definitions that are detached from pixel grids. Web, as a UI platform, desperately needed vector UI with flexible layouts as the very same web page needs to be presented on all platforms|devices in reasonable manner. And so it was the first one that departed from fixed layouts. So UI design have changed from simple 2D painting (physical brushes and canvas, paint.exe ... Delphi/VB/Glade IDEs) to procedural and rule (layout, style) definitions. We speak now in quite different UI language and that's what was changed really.
  • TheOtherHobbes 4y ago
    Web UIs should have been procedural from the start, but HTML's design confused semantics and visualisation. CSS was supposed to clarify this, but CSS isn't procedural either. So js was added to the mix to fill the gaps in what CSS can't do. But js doesn't componentise well, so React was invented as yet another layer to "simplify" everything else. So now we have a "proper" frontend dev language which sits on top of a virtual DOM which is still based on HTML etc. All of this could have been avoided by making Web 1.0 procedural and explicitly extensible and not baking content styling into HTML's semantics. There would have been some small additional complexity and it might have been harder for beginners to learn initially. But the current stack is far beyond non-developers anyway. I suspect there would have been at least a fighting chance of replacing everything with a single standard library that runs faster and could easily handle everything React does more simply and elegantly, including resolution-dependent rendering - probably something like iOS/Android, but even simpler, and using the browser explicitly as a VM/secure container.
• newbieuser 4y ago
  for most libraries, I think people in core teams cause it. eg react is destroying the potential of hooks more and more with each release. and it's weird that no one of them said, "what are we doing right now, does this stuff really have to be this complicated", but I guess that's exactly what open source development culture is today. we know best and you should use it.
• brimstedt 4y ago
  The main reason is because we shoehorn complex apps/ui's into a browser that wasn't made for it. It's not the UI is very complex , or that there are ton of frameworks with different maturity levels. It's because the browser and thus html/CSS was made for documents. If we made a "browser" made for apps, where we didn't need to transpile to js, and didn't need to cater for incompatible browser versions, but could concentrate on what really matters we wouldt have such a big problem
  • chrisco255 4y ago
    You could do this now with HTML canvas and web assembly, but you won't, because the web already has a rich feature set of accessible and search engine friendly features. > but could concentrate on what really matters we wouldt have such a big problem Curious for someone who dismisses the complexity of front end, what you think really matters in creating a cross platform UI application experience that works on all devices?
  • rrrrrrrrrrrryan 4y ago
    I'm old enough to remember when Flash and Java were hailed as the future of application development because they were "cross platform." Your "browser made for apps" isn't the dream you're imagining - today's SPAs are miles better, whether they run in-browser or are packaged up as Electron apps.
  • steve1977 4y ago
    So, something like Java applets?
• deleted 4y ago
  [deleted]
• thedonkeycometh 4y ago
  [dead]
• manv1 4y ago
  On the web side you need to synchronize the DOM, the visual state (which is mostly related to the DOM), the user's state, and the backend state using a protocol that's stateless. Really, the browser side stuff is the real PITA. It's a hacked together piece of shit written by people who were too clever by half. And it's designed to be used/driven by less-than-skilled individuals. But in the end one big problem is there aren't a lot of ways to model a UI effectively. One given screen can have multiple states and behaviors that are state dependent, and the tools really aren't there. How do you specify "animation like x/y/z" on a screen? There are tools for designers, but they're don't really work when handing that off to development. What I've seen is people printing out prototype screens and annotating everything, but that's obviously janky.
  • indigochill 4y ago
    > How do you specify "animation like x/y/z" on a screen? And not just "a" screen, but screens of all dimensions and even physical interfaces (but mostly, desktops vs phones, which are completely different). I've only dabbled mostly amateurishly on web frontend, but personally I think I'd prefer to serve totally different files to someone based on the form factor of their device rather than deal with reactive frontend frameworks. Heck, I already serve both Gemini and HTTP.
• danr4 4y ago
  My answer is market demand: 1. users demanding (whether unknowingly or not) better ui, quick updates 2. developers demanding “make it for me” tools 3. Companies “demanding” engineers to stand out
• GartzenDeHaes 4y ago
  Developers are smart people who enjoy solving complex, interesting problems. If you give them a simple problem, very often they will find a way to make it interesting.
• blub 4y ago
  Several reasons: 1. Lack of skills. Front-end has evolved from web design. If people like to criticize software engineering as “not real engineering” then front-end is the farthest thing from engineering that exists in software engineering. One can see this in the programming languages, the code reuse (libraries, packages, etc), the tools and the attitude. 2. Too much ambition. At the same time I don’t think I’ve ever seen a community so driven by reaching their goals at any cost. Once apps kneecapped web sites the community had a major identity crisis which they solved not by doubling but by tripling down on HTML, CSS, JS and the like. Standards, common sense, performance, usability, privacy be damned. Because of point 1, the solutions they built were also just good enough to not completely fall apart. This is also why everything’s being rewritten in the web. 2. Too much money. Unfortunately companies like Google and Facebook made an immense amount of money ruining privacy for everyone and they could do this faster, better and out of sight with web apps. They poured money into web technologies like their lives depended on it (because they did) and in the end managed to squeeze a round peg into a square hole: the fundamentally mediocre web managed to displace more worthy technologies and entrenched itself. Every few years some poor soul realises the reality of their professional existence and writes a blog post or comment asking something along the lines of “Why is front-end so terrible?”. But there’s too much money in the status quo, so they either get gaslighted, or subtly dismissed and the cycle repeats anew. And that reality is that you can polish a turd. With enough manpower, motivation and money you can really make it shine. But underneath, it still stinks and people will figure it out. :-) Note: I got out of front-end in the 00s and then out of back-end a year later. Since then I’ve watched this never-ending train-wreck with amusement and amazement, but also sadness when realising how many real apps are replaced by soulless Electron shells.
• irrational 4y ago
  I think it is artificially inflated. The web took off to such a degree that that is where all the high paying jobs were. So people came over from other places and brought their complexity with them and imposed it on web development. The fact that you now have to have a build system to create a website is like something taken straight from application development.
• cnotv 4y ago
  It's actually quite elementary and obvious if you have been in the market long enough: from websites it shifted to web apps, which have a different type of and higher complexity. Beside that, also the websites got more complex, as a wider range of people started to use them, as well as different types of devices, languages, purpose and so on.
• baron816 4y ago
  I keep seeing this type of thing popping up. The short answer is because people are expecting more from the web. What interests me is why are so many people perturbed by this. If I look through my bookmarks, pretty much everything could be server side rendered without any need for JS. It’s all stuff like HN or news sites. I wonder if the OP and others who have asked this before see the same thing: the consumer internet sites they most visit don’t need complex JS. But that doesn’t describe all sites. There are plenty that do require a lot of complexity.
• rglover 4y ago
  > Is that complexity necessary or artificially inflated? 100% inflated and ego-based. How do I know? After years of struggling to understand the increasingly complex front-end space, I decided to build my own full-stack framework [1] to check my own opinions weren't left-field. Here's the harsh truth: it doesn't need to be as complex as it's made out to be. Not even close. I can speculate as to why (ego, job security, etc) but ultimately the punchline is that all of the APIs and a lot of the code under the hood are pointless Rube Goldberg machines. People don't want to hear that because they're invested emotionally in a lot of these tools, but from direct experience doing multi-year research and building of a framework, it's all a scam. [1] https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick
• ergonaught 4y ago
  Because business cares about business and moves too fast to get it right or waste time on values, and by the time enough people might object the network effect or inertia or tech debt or whatever you want to call it has become The Way It’s Done and nobody can stop long enough to fix that.
  • pixl97 4y ago
    Business is in competition with other business, not in competition with 'doing things right'. Forcing businesses to 'do things right' is called regulation and will get you lots of subcomments on how that's bad here on HN.
    • ergonaught 4y ago
      It’s the same situation for business vs academia, business vs standardization processes, business vs anything.
• revskill 4y ago
  I think because of NodeJS. All modern toolings are built upon NodeJS.
• throwaway9870 4y ago
  I think the natural evolution of programmers is to become more capable of building complex systems until you reach the realization that just because you can build it, doesn't mean you should. You then think hard about how to build as simple system as possible. The front-end space hasn't historically struck me as filled with a lot of grizzled systems programmers that have learned this lesson, so we get what we have today. Eventually they will learn and thinks will start becoming more minimal.
• rgovostes 4y ago
  In my teens, I could regularly churn out a small GUI program after school in an application like HyperCard, or later REALbasic (now Xojo). I remember writing a saved game editor for Psion Boy[1] which had an editable list of inventory items, fields for character stats, and buttons for saving and loading game files. I have many more years of experience programming now yet I could not make the same program nearly as quickly. Fire up Xcode and then fumble with storyboards or SwiftUI or IBOutlets? Start writing functional React components on a Bootstrap grid with some live reload script injected into the browser? Modern frontend tools enable improvements like accessibility, internationalization, cross-platform compatibility, touch screen support, etc. But they have really extinguished my excitement to build anything beyond the command line. 1: https://macintoshgarden.org/games/psion-boy https://macintoshgarden.org/games/psion-boy
  • pixl97 4y ago
    I have one more thing to add to your benefits of web front ends. Security. At least some security separation between the application and the users operating system. If I loaded the save game in a web app, I would at least have some assurity that the application was only going to get access to that one file, being the web browser is going to enforce that. With a binary thing are far more terrifying, every file I have permission to is up for grabs. Running it on my primary machine is a no go for the most part. I'll have to load it in a VM if I really want to use it. With this said Windows 10+ has the Windows Sandbox feature that very few people know about, but there is still a fair amount of friction there compared to a browser.
• player2121 4y ago
  Browser capabilities exploded dramatically as well as hardware, this is why we have Figma and virtual machines running in the browser. So the answer to this question seems obvious to me. It would be odd if UI complexity stayed the same.
• aww_dang 4y ago
  Has anyone else reached the point of annoyance where they feel that moving to egui + WASM makes more sense? At least the app won't be married to the browser.
• deleted 4y ago
  [deleted]
• seti0Cha 4y ago
  I'm more of an ops and backend guy, but I used to do a lot of web development in the early days of the web - assembling HTML, a sprinkling of javascript, hand-rolled CSS and embedded styles. In a certain way it was very simple, but in another it was horribly complicated. Sure, the pages we built were simple compared to today, but the tools we had were extremely crude and building a large website required some pretty clever things to stay maintainable. After I started doing more backend stuff, I lost touch with the evolution of Javascript and its various frameworks and I believed everything had become very complex. Recently, however, for fun I've been tinking with TypeScript and Vue and I have to say, it all seems way easier than how we did it back in the day. CSS seems far more reliable, HTML now has sane ways to lay things out, Typescript/Javascript has evolved wonderfully, and these modern frameworks that isolate components from each other and bundle code, style and layout together are almost a pleasure to use. Sure, there are some concepts you have to learn, and there's so much magic happening behind the scenes it's terrifying. But I'm building stuff I would have spent days on in a matter of hours now and I have no idea what I'm doing. What I'm noticing now though is that now that frontend development has become a lot more about coding and a lot less about knowing arcana, frontend coders seem to be going through growing pains that are a lot like backend coders have already gone through. For example, it's funny to me to see discussions about how to handle components needing to access shared data. Should you pass the down down through the component hierarchy or have a single global data object that components can interact with, and I'm thinking, next stop, a dependency injection framework. I'm not sure I'm actually right about that, since I've only just played around a little bit. I'd be interested if others would agree with that assessment.
  • tomwheeler 4y ago
    This is my experience as well and I agree with your point. 25 years ago, I had to know which parts of HTML, JavaScript, or CSS did or didn't work properly in different versions of Netscape, Internet Explorer, and a few other browsers. This also varied by platform. Internet Explorer 4.x varied significantly between the 16-bit version on Windows 3.11, the 32-bit version on Windows 95/98, and the surprisingly decent version they released for the Mac. "Graceful degradation" was the goal on my team, so it wasn't so much about building functionality with JavaScript as it was about using it to make things more convenient when possible, without breaking things otherwise. For example, we would use client-side validation to save a round-trip to the server, but server-side validation would ultimately catch the problems if a client had JavaScript disabled. Keeping those validation rules in sync was a pain, because the server-side code was written in a different language from the client-side code. I do think that frontend development is more complicated than it needs to be these days, but understanding the evolution, I can certainly see why it reached this point.
• bdcravens 4y ago
  Failure to stop and consider how much of it can be pushed to the backend.
• sircastor 4y ago
  I started my Web Dev career in 2005, around the time "Web 2.0" started to pickup steam. It was (In my recollection) really the beginning of the Web Application model. Users were starting to expect web pages to do more, and be more than "click a link, go to another page" I'm certain any developer from that era has a story about writing tools to make their own life easier. Prototype and jQuery were popular as they abstracted a lot of the obnoxious stuff you had to do over and over again. And the story goes on from there. The complexity is a story of trying to simplify for the developer, and then trying fix the costs of the overhead from those simplifications. As for your second question. It's not necessary of course, but if you don't use these frameworks and tools, sooner or later (I think) you're going to be engineering a solution yourself.
• taeric 4y ago
  Complexity in software typically comes from codebases made for multiple teams. When you have multiple teams, this is unsurprisingly a benefit. When you don't, you typically get one team pretending to be many, and the needs of the other personas will be guessed, not known. Web frontend work starts at a disadvantage because of the css/html/js divide. If you actually have distinct designers/authors/coders, it works as designed. If you have a small team, it doesn't. To the typical disasters that we are all used to and have probably been responsible for. The best symptom of this, to really demonstrate, is when you don't know what tools a contributor needs other than a text editor.
• hn_ltl-ftc 4y ago
  I'm going to attempt to give some fact- & data- based answers, as there seems to be too much ideological axe-grinding in (many of) the existing responses (as is, unfortunately typical on HN it seems, when discussing Front End Development). Even if my attempt seems...boring? (And sorry for the length; hopefully it makes up for that a bit in quality...?) HN: "Why did Frontend development explode in complexity?" Answers: 0) It's not ONE thing--it's a combination for forces/trends/factors... 1) The underlying technologies have become more complex (at least CSS and JavaScript have, but much less so w.r.t. HTML). For example: Flex layout, Grid layout, calc(), variables, etc., in CSS. Async/await, destructuring assignment, import(), optional chaining, spread operator, yield, ...more in JavaScript. 2) Customers and Users 'see' something that looks complex (whether inherently or accidentally), using Web technologies, so they are increasingly conditioned to expect that any application (regardless of complexity) can be build/delivered using Web technologies. A few examples, off the top of my head: https://www.figma.com/ https://www.figma.com/ https://docs.google.com/ https://docs.google.com/ https://www.onshape.com/en/ https://www.onshape.com/en/ 3) HTML is--egregiously--impoverished! Quick, when was that last time you saw a non-trivial LOB application (or even most CRUD applications) that did NOT need some sort of data-grid style presentation? Well, luckily we have the HTML5 data grid control for that...oh wait, F** me! And then there's less common needs, like a 'tree control'. Or more common needs like: a robust dialog control (with proper focus mgmt., etc.). To PROPERLY implement (documented, rigorously tested, styleable, i18n support, accessibility support, DOM attributess, JS API exposure, and on and on) just one of those is weeks, even months of work. Sure, if you're only creating something for your own project, you can take short-cuts. But how much effort--and complexity--has been foisted, collectively, on Web application Developers, because the BROWSERS don't have a complete control set??? Arguably, the HTML control set is not much richer (except in styling) than what one could do on a 327X terminal; which is 1960s-vintage technology! HN "Follow up question : Is that complexity necessary or artificially inflated?" 3) Short answer: YES. Long answer: as the technologies mature (whether the built-in troika of HTML/CSS/JS; or the add-on stacks), and as Developers become more experienced at delivering applications with 'Web stacks', what I've experienced is that some of the accidental complexity is decreasing. But certainly FOMO and RDD, and similar self-serving imperatives are a factor in having artificial complexity. For example now that 'legacy' browsers are no longer a concern/constraint for many projects, the complexity of Babel, and Webpack are often no longer needed. Or, at worst, can be replaced by more: modern, simpler, and generally performant tools. Example: https://vitejs.dev/guide/why.html https://vitejs.dev/guide/why.html Also consider the madness which is the global namespace + cascade approach of CSS to selecting where/how styles get applied. There are (? were) benefits to this approach when CSS was exclusively being used for a relatively small number of styles that needed to be applied, consistently, to a large number of pages (i.e., via a rel link to a SHARED stylesheet). But those days are LONG gone! There have been numerous attempts to address that madness, traditionally via naming conventions, for example: https://en.bem.info/methodology/naming-convention/ https://en.bem.info/methodology/naming-convention/ https://www.keycdn.com/blog/oocss https://www.keycdn.com/blog/oocss But those approches are (IMO) tedious; and experience has shown they are not scalable, on multiple axes (application complexity, project longevity, team size, experience level diversity). So Developers added tooling, such as SaSS, to attempt to overcome the weaknesses of CSS for large/complex projects. That's been at least a partial success. BUT, at the cost of additional complexity in the tooling and build chain. Maybe even having to have an additional language run-time for some tooling like that! Just having two 'newish' features of CSS: variables, and the calc() operator can potentially reduce a lot of the traditional usage of things like SaSS. In some cases, the need for tools like that goes away completely! That's a win, for reducing artifical complexity. Another example is the strict scoping of style selectors in Vue's single file components: https://vuejs.org/api/sfc-css-features.html#scoped-css https://vuejs.org/api/sfc-css-features.html#scoped-css Just that one feature alone, completely eliminates the traditional CSS madness, but without the weakness of the conventions (like BEM and O-OCSS), and with minimal (and pre-configured/included) tooling. CLOSING THOUGHTS: state management is still very complex; at least for non-trivial, and at least moderately interactive applications. In my experience (and I was designing, and implementing, complex GUIs _long_ before the Web was a thing), at least some of that state management is necessary (inherent), for those non-trivial & interaqctive applications. The best we can do is to research and investigate, and try-out various approaches to minimizing the _accidental_ complexity that our state management approach/library/etc. adds to the inherent complexity. I'm somewhat adverse to making recommndations on specific technologies, but I'd suggest that Developers who are contemplating a Web applicatiion with demanding state managment needs take a look at the following state managment library: https://tanstack.com/query/v4/docs/react/overview https://tanstack.com/query/v4/docs/react/overview Comment: it addresses a LOT of the pain points that many Web Developers/Projects encounter. Moreover, I've had some very positive experience with the predecessor project to this one (i.e., React Query). N.B. If you're going to be using: Vue, Svelte, or Solid.js (i.e., NOT React), then make sure to click on the drop-down menu in the UL corner of that page!
• shireboy 4y ago
  I agree it's gotten too complicated. In my mind, the evolution has gone like this: 1) Plain HTML/CSS, built using desktop tools like FrontPage/Dreamweaver 2) Server-side scripts (CGI/ASP/ColdFusion) to dynamically generate HTML/CSS. Javascript or VBScript for "Dynamic HTML". 3) Javascript wins, VBScript dies. Javascript idiosyncratic between browsers. Flash fills niche for dynamic client UX that generally works on most browsers. 4) iPhone happens. Safari won't support flash. Devices that do support flash or a subset have terrible battery life. 5) Javascript has matured. jQuery patches remaining cross-browser issues. 6) Server-side frameworks like ASP.NET, Ruby, PHP, NodeJS mature. 7) JS further matures. cross-browser without jQuery feasible, but binding to JSON is still clunky. Frameworks like Angular, Vue help with databinding and other common problems developing JS/CSS/HTML clients. 8) If you solve enough problems, you end up with a framework to build a complete client, transpiled from various languages (TypeScript, SASS/LESS, some markup). Angular, Vue, React, and other SPA frameworks evolve further. 9) Some UX/SEO/perf issues with SPA approach. SPA frameworks evolve to support server-side rendering. 10) Static sites generated by frameworks reduce the need for server at runtime. Build the site and host on cheap CDNs ...and this is where we are now. As someone more used to ASP.NET + Vue/Angular, I'm still having a hard time transitioning to server-side rendering, WebPack, etc. It just feels like too much ceremony and too many dependencies. I think the industry is waiting for some solution that is low-dependency, widely adopted, open. I haven't found my perfect platform yet, but feel it looks like this: Put a few files in source control and very easily spin up sites that look ok by default but are easy to customize. It supports building sortable/filterable grids,lists, and forms against some server API (REST/GraphQL/etc) with minimal code and and simplifies auth. It also has a rich ecosystem of components.
• bob1029 4y ago
  > Is that complexity necessary or artificially inflated? Totally unnecessary in 99% of cases. There are outliers where this front-end/back-end state division madness makes sense (i.e. gigantic apps managed by gigantic teams), but most web properties are not this big. To be clear - the division of state between client & server is where almost everyone is struggling. State management is usually the hardest part of any complex app. When you have 2 piles of it to worry about, you make life much harder. In my view, the happy-path solution has been out there for a while. Frameworks that utilize a web socket (or similar bi-directional messaging abstraction) to directly relay user events & DOM updates. This can eliminate nearly 100% of client-side state. If you keep the logical representation of all clients' views server-side, you will have a much easier time keeping things synchronized (because there will be nothing to sync except the session cookie). I started this journey with Blazor (server-side), which really helped to solidify the concept and its pros/cons. Now, I have a custom framework that achieves approximately the same outcome, but with much better alignment to my problem domain & requirements. I add my middleware and work directly with HttpContext these days. Life is so much easier when you don't have to deal with layers upon layers of opinionated indirections.
• carapace 4y ago
  There's a common pattern I've seen over and over. When people learn a new thing they tend to go through a creative phase with it. The first time I noticed it was in a programming class I took in school. We were learning in Pascal. (It was cute!) When we got to the lesson on changing output colors, for the next week it was like some unicorn barfed rainbows all over our screens. People like to play. (Remember blink tag? Scrolling marquee?) What you're seeing in the JS Frontend space is (in my considered opinion) a combination of the effect of: 1) Lots of people learning to program by messing around with JS, and 2) Folks willing to pay people to mess around with JS. So you have a volcano of creativity combined with a tidal wave of money... The results were inevitable. > Follow up question : Is that complexity necessary or artificially inflated? No, and yes. It's not necessary (for the vast majority of sites) so it's definitely (IMO) artificially inflated. The good news is that you can end-run all the introduced complexity by using e.g. Elm lang ( https://elm-lang.org/ https://elm-lang.org/ ), or just sticking to simple "plain vanilla" JS systems. The only reason to use something other than Elm is if you enjoy some other particular system (I hear good things about "htmx" https://htmx.org/ https://htmx.org/ )
• z3t4 4y ago
  Because the people with the least experience choose what tech to use, or they get paid to use a specific tech.
• cies 4y ago
  Shitty ducktape-y standards (most notably JS that was initially designed in 10 days). But it still became the standard for x-platform SaaS UIs: point your browser to a URL and go! So a lot was demanded of these shitty standards (HTML, CSS and JS) and in oder to push them to the max a lot of "frameworks" emerged helping you with that. First jQuery, then Knockout, ..., React, ... > Is that complexity necessary or artificially inflated? I'd say it's organically inflated: no one did it on purpose. Every one tries to make it simpler. I'm a big fan of Elm, which GREATLY reduces the complexity or browser apps... for me. And still I prefer server-side-rendered if possible (or I have to manage the state on both ends, which also increases complexity).
• rr808 4y ago
  I'd love a web based framework that worked as well as VB or Delphi worked 30 years ago. Is that really asking too much?
• lucidguppy 4y ago
  Alan Kay thinks the internet and TCP/IP is awesome - but the web is horrible. He's coming from the small-talk world where you have an incredibly powerful environment that's self enclosed. He sees the browser and javascript as a step back to technology that was developed in the 1970s. The dom+javascript just isn't as powerful and so every attempt to improve shows some defect that a good plurality doesn't like and then they redo everything over again. We're basing everything on a language that was originally functional but was disguised as an OOP language because some executives thought JAVA was the next big thing. We're forcing a document object model to be a human interface model. We're stuck in this local maxima of power and functionality and all these attempts won't work because they're incremental. We need a quantum leap about what we think the human interface of the internet should be - and it shouldn't be the browser.
• osynavets 4y ago
  Because http stateless And preserving state was not intended by design
• datacruncher01 4y ago
  From where the web started to now, the complexity makes sense. There were tons of browsers all implementing html, css, and javascript with their own quirks not to mention their own additions. For example, the father to all modern live websites, XMLHttpRequest is a Microsoft invention that was originally intended for Outlook web mail. Honestly, it's more of the speed of design that drove the complexity. Everyone had some specific niche that they picked up and due to the volume of demand for web development there was bound to be many different approaches tried. Eventually, that's going to mature down to a few different standards. That's already happening with web browsers, for practical purposes we have three current browser engines today, down from who knows how many.
• Alifatisk 4y ago
  It feels to me like we are heading towards unifying our tools. Look at Vite & Rome for example.
  • deleted 4y ago
    [deleted]
• sibeliuss 4y ago
  All I have to say to this is we recently rebuilt our admin tools application and the team responsible have been all backend / devops engineers. Stack is React and GraphQL. Without having any real FE experience this team has been absurdly productive. Rewind the clock a bit and it would have been a nightmare. From this experience alone I can conclude that the complexity issue the OP is citing is mostly an illusion, assuming there's someone around who can help guide tech choices at the beginning. There's simply no way a team of non FE engineers could build this stuff so well, and so quickly, a decade ago.
  • gitfan86 4y ago
    Things are getting better, but it is still pretty easy to get into a circular dependency of NPM packages that makes it really hard to upgrade
    • sibeliuss 4y ago
      Yeah, I definitely know this through painful experience, but historically library upgrades in non-trivial apps have always been difficult. It is what it is, and its the same in every stack.
• culebron21 4y ago
  I'd say this is the result of huge investment bubble in IT companies, where nobody cared enough of efficiency of workforce. Everybody seems to care of hardware efficiency, because it's very measurable. For example, if CPU is overloaded, an extra virtual or dedicated machine costs a lot, or a daily script works 10 hours and may result in serious troubles -- everybody gets bothered. But if you add complexity and devs must work a month instead of 1 week on a simple task -- this passes under the radar, because devs unlike CPUs are busy 100% time always. That projects start to take longer, probably gets attention, but many just considered hiring an extra guy. This probably lead many to consider heavy and complex projects, like Airflow, worthy -- because the costs were not considered seriously, and apart them, the selling point (configuration with some clicks, and launching a task by a click), was in a favorable false dichotomy.
• thinkxl 4y ago
  My theory and personal opinion. In the past, we didn't have complex UIs, we did, but we dealt with them differently. For example, in the era of forms and limited Ajax, keeping the DOM synced with the state took a lot of work. The complexity we see today results from different ideas of how to deal with that _synchronicity_. Keep in mind that there's no way to do it natively; the only way to do it is to manually keep the state in sync. The complexity we see today results from the abstractions people have created to accomplish that, e.g., jQuery, Sammy, Backbone, Knockout, Angular, Ember, React, Vue, Svelte, etc. Enterprise and FAANG required optimizations for different reasons, scale, collaboration, distribution, etc. Programmers wanted to use paradigms to represent things and apply optimizations on the web, and JavaScript wasn't enough. So, they created CoffeeScript, Flow, TypeScript, ReasonML, etc. These tools became popular in the FAANG, wrote posts about them, then people of all industries adopted them. To use all these cool tools, people created bundlers—each with its configurations, patterns, and philosophies—gulp, Rollup, Webpack, etc. At this point, the web skyrocketed in complexity from the days of HTML, CSS, and JavaScript when one of the complex tasks was to make rounded corners with images and cool layouts with tables. Of course, you can still build complex UI without these tools and use JavaScript alone, but you will end up abstracting your patterns and paradigms into reusable bits. Additionally, some developers attempt to use as little JavaScript as possible; one great example of a complex UI trying that is https://sourcehut.org https://sourcehut.org.
• hilti 4y ago
  NPM is the Instagram for developers. They produce mostly wrapper packages around standard APIs in order to get some fame. It would be much better if they teach people how to achieve basic stuff without already-baked-in APIs. I'd assume that 80% of the available packages are completely unnecessary, i.e. "I need to set a cookie ... let's download this NPM package" or "I need to make two AJAX requests in order to fetch some JSON ... there are two more NPM packages" I'm writing happily spaghetti code, use PHP, SQLite, Vanilla JS, HTML5, server-send-events, cron jobs and bash scripts to create fast and useful web applications. Last note from today: I saw a tutorial on YouTube how to auto-generate a .m3u playlist for a folder containing hundreds of MP3. It involved of course downloading NPM packages, create a NodeJS cli script etc. My 3-second solution was this (built in tools coming with almost every OS) #!/bin/bash ls -1 *.mp3 > playlist.m3u
  • rrrrrrrrrrrryan 4y ago
    Any link to that YouTube tutorial? It's hard for me to imagine someone who presumably knows how to create CLI scripts not independently coming up with a solution very similar to yours.
• 71a54xd 4y ago
  People realized they were being easily replaced by puppy mill dev bootcamps - skilled members of the market responded, the rest is history.
• hbrn 4y ago
  A lot of complexity is coming from big corporations producing frameworks and methodologies optimized for huge (bloated) teams / codebases. The reality is that most teams in the world are not huge and never will be.
• fredefdef 4y ago
  To sell new end user computer?
• rrrrrrrrrrrryan 4y ago
  Frontend development happens at the tail end of long pipeline of requirements gathering by product and design folks. To meet the requirements foisted upon them, frontend devs tend to gravitate toward tools and frameworks that allow for maximum flexibility. And greater flexibility comes with greater complexity. If you looped in frontend devs earlier in the requirements gathering phase, you might be able to (drastically) simplify a lot of the frontend work (e.g. "if we design this UI flow slightly differently it will require way less development"), but I understand this goes against most of the software development best practices which are currently en vogue.
• spcebar 4y ago
  Regarding frameworks: Things like frameworks have utility in large scale web applications where you need to manipulate a lot of data on screen on the fly. Using the right framework for the right thing can make development and maintenance fat cheaper and faster. That said, using a framework because other companies are using frameworks is definitely an unnecessary layer of complexity, and most websites don't need to be using React or the like. Regarding UIs and Designs: companies want their sites to look nice and so they hire designers who may or may not be trained to design for the web. Print design and web design are very different disciplines. You can end up with really strange and poorly performing sites when a design doesn't match up with the reality of browser rendering. Regarding sites that have huge payloads: this is almost always a product of management/marketing input, and payloads end up ballooning when someone says "can we just add an X pixel" or "can we try this one new piece of tracking software." Is the complexity there necessary? Probably not, but when multiple stakeholders have say, this is probably going to happen.
• marstall 4y ago
  Web 1.0 was very simple programatically: 1. user requests page 2. program generates page 3. user clicks on something. 4. * entire page is regenerated * Javascript was terribly incompatible across browsers, so it was avoided. Then in 2004 or so, jQuery made it seem easy and desirable to do more than just regenerate the whole page when a user took an action. This introduced all the complexity you see today. React is just the apotheosis of a long sequence of tools whose purpose was to reduce the complexity introduced by jQuery (and "Ajax"). One way to look at it.
• kokizzu2 4y ago
  just use svelte for SPA XD it's just like normal html with autoreactivity
  • kokizzu2 4y ago
    for MPA https://github.com/kokizzu/svelte-mpa https://github.com/kokizzu/svelte-mpa
• trog 4y ago
  My conspiracy theory of choice is that all these big front end frameworks have been developed and heavily funded & pushed by (primarily) Google and Facebook specifically to make it so people are forced to run client-side JavaScript to get even the most basic functionality in every website, this ensuring tracking and ad code can get delivered.
• poulsbohemian 4y ago
  I started a project in October. Spent part of November and through December building prototype frontends to decide which way to go - the whole next / nuxt type debate, looked at svelte and Laravel. Finally came to the conclusion that since I was using Django for the backend anyway, there really wasn’t anything that couldn’t immediately be done just as well with Django templates. Sure, maybe at some point I’ll need to integrate some other frontend tools, but by that time I will have tested market fit and I will have customer feedback that tells me if I actually need something different for my UI. All of these front end frameworks add a ridiculous amount of complexity and brittleness for unclear advantage.
• dusted 4y ago
  Unpopular opinion: Because people started thinking it'd be a good idea to treat the browser like an operating system instead of an ardent renderer of interlinked hypertext documents..
• mmcnl 4y ago
  Because the web distribution model for apps is extremely cost efficient. This has caused exponential growth in web app development. To support this, frontend frameworks have grown almost exponentially as well. Every corporate app is a webapp nowadays. This wasn't the case 10 years ago. When we talk about web development, we are now not just talking about websites but about apps as well. So the industry has changed significantly. UIs always have been complex btw. A lot of different states, and keeping backend and frontend in sync is hard too. So many edge cases need to be considered, orders of magnitude more than in the backend. The UI is also your first line of defense against unexpected user input. Summarized: (1) app distribution has shifted to the web, (2) UIs are complex
• riveralabs 4y ago
  This might be a bit of a stretch but I believe native mobile apps is what triggered complexity in web apps. The bar was raised and users were expecting performance and experience equal or better than native mobile apps.
• nunez 4y ago
  IMO it's because the bar has gone up, especially from customers. 10 years ago, your social app didn't need to have sub-second response time worldwide while collecting literally everything about user journeys to drive engagement and serve ads, thwart DDoS via scraping or client-side crypto mining attempts, be compatible with mobile and desktop browsers, or be insanely visually appealing and deal with even bigger markup and stylesheet languages that, again, must seamlessly work on mobile and desktop. you didn't really need to have a mobile app that communicates well with frontend. Also, consumer internet bandwidth, disks, and computers are way faster and cheaper now in the US and Europe than it used to be (and even in developing countries with the proliferation of Starlink). we have facebook machines AND PHONES running m2/a15 Apple Silicon that rivals workstation-class compute at a fraction of their CPUs TDPs. So customers will demand more because they can demand more. Could we collectively just stayed frozen in 2013 or 2010 when life was simple and browsers weren't operating systems? sure. but clearly the push for more things is working as every tech company is worth more than they used to be back then, even after accounting for today's climate. TL;DR: capitalism?
• assertnotnull 4y ago
  1. Browsers evolve but the JS ecosystem is competitive so instead of using the brain power to find a common solution to problems we end up with a grid of benchmark of frameworks about how fast it refreshes. I still see job description mentioning Redux while you don't need it 99% of the time or even never. 2. Frontend dev is actually Blog/Video/Trend based development. Simpler tools exists but yeah.. I guess there is a market that feeds on this complexity.
• gloosx 4y ago
  The Barrier (tm) has lowered substantially. Let's be honest guys, it is really hard to hire an engineer whom understands the virtues of modern system, and how simply you can work out the most complex logic with it. It is possible to make beautiful, simple frontend systems today using React and a handful of k8s microservices, just the man who does it is invisible. It is possible to keep integration cost practically free, but these men who keep it are sought with fire. It is possible to use our tools just how they were designed to be used, avoiding bad and worst patterns, but only few of us mastered our tools. You just need to hire one engineer if you are not and engineer and you didn't walk their shoes for decade and hope for the best of luck. The Javascript and React are not strict tools at all, so they will allow a lot of people to fool you into thinking they are too good.