9 ms·

It's disheartening to explain this over and over again, but these frameworks are a-ok because user's expectations for the web have grown astronomically. The com

It's disheartening to explain this over and over again, but these frameworks are a-ok because user's expectations for the web have grown astronomically. The complicated web is here because users insist on interaction, and if any web page has more than around 10 interactions on it, the resultant complexity is best handled by a framework. I recently got to do a jQuery job for a client-- it wasn't a pleasant blast from the past but a kludgey swamp to slog through. The build pipeline complaint also strikes me as hollow. Create React App outputs folder you can drag and drop onto a server and serve, same for Angular and I would assume Vue. Yes, it is a lot of JS from a ton of NPM libraries, but that's the trade-off when you get an entire ecosystem of code for free. If your application is security critical then consider either writing your own libraries or hosting security vetted copies of the libraries. The real reason to leave this industry is that it's all the same work at the end of the day. Despite what application you build, whether it's a social network, a security application or collaborative tool like Figma or Trello, it all runs together as a mish-mash of views, data and DOM elements. Unless you're really invested in the product, it becomes hard to maintain enthusiasm. You can only roll a CSS library, or auth scheme or API library so many times before you're ready to start some new adventures in coding.

catmanjan 6y ago
>user's expectations for the web have grown astronomically Have they? I don't see that in my user stories
- deleted 6y ago
  [deleted]
- paul_f 6y ago
  Users just want it to work. I think the problem is too many developers trying to impress each other for status. IMO, what matters most is coding efficiency, how fast can business problems be solved with a low enough error threshold.
  - danjac 6y ago
    It's a combination of whimsical requirements from PMs and designers, plus FOMO and resume-driven development among developers. None of which have anything to do with actual end-user needs.
    - throwawayzRUU6f 6y ago
      There's also a Large Corp dynamic, where to maintain consistent user experience across the product portfolio, a common UI platform is built. The platform is then mainly driven by the requirements of the most dynamically interactive applications, leading to a complexity creep - even though most of the products could be simple CRUD web pages.
    - paul_f 6y ago
      "resume-driven development" I think you nailed it.
  - peruvian 6y ago
    Companies overhire devs after raising money so it looks like they're doing a lot of interesting stuff. PMs and managers need to find stuff for these devs to do, hence they come up with overcomplicating their existing tech, redesigns, etc.
  - why_Mr_Anderson 6y ago
    And on top of that, most users want it to work the same it worked yesterday. Nothing drives me up the wall more than neverending stream of updates for anything and everything, be it PC, mobile, web, even cars. I understand it's great for job security and/or resume-filling, I just wish those developers would consider the difficulty of,for example, trying to explain to 60 years old nurse why the thing that worked yesterday doesn't work anymore or why it suddenly behaves differently.
sneak 6y ago
> It's disheartening to explain this over and over again, but these frameworks are a-ok because user's expectations for the web have grown astronomically. I'm pretty sure that this is not true. You can ship great webapps without any of that overcomplicated nonsense. We're using one such right now.
- richeyryan 6y ago
  Hacker News is purposely utilitarian and that's fine but I don't think general audiences would tolerate it. You have to manually check if someone responded to your comment. I don't think its too unreasonable to say that most users expect a notifications system on a platform like this. Editing a comment takes you to a separate screen and leaves you there once you're done, you have to manually navigate back to the discussion you were on. Reddit lets you edit your comment in place and continue from where you left off straight away. These features could be feasibly implemented using jQuery or plain JavaScript but the more niceties like that you add, the more you can make the argument for UI frameworks.
  - sneak 6y ago
    It seems to me you're confusing HN's lack of some common forum features with the way that those features would be implemented; I would imagine that if HN did get, say, notifications, they would largely work without javascript, or some big complicated frontend build process. old.reddit.com is another good example. Not everything needs to be an SPA.
    - richeyryan 6y ago
      The parent suggested HN as an example of an application that didn't need a lot of client code. I think its still fair to say that it doesn't have many of the features that ordinary users have come to expect. Old reddit is a much more reasonable suggestion. It is fairly feature rich and is used by a large group of users. It seems to deliver ~340KB of Javascript. It's pretty nicely minified so I can't tell what its all related to but at least some of it must be related to the interactivity that HN is missing. Like I said in my previous comment, you can do as old Reddit did and build up Javascript to solve these problems but at some stage it might make sense to jump to an SPA. Reddit made that decision. I think many would argue that they prefer old Reddit which is fair enough. I think its hard to say if the Reddit team made the decision based on a legitimate and provable technical need and their old solution just wasn't cutting it or if they went the SPA route because "its what everyone else does" and "its easier to hire React devs".
jamil7 6y ago
You're not wrong, I think most in this thread won't debate that user expectations are ever increasing. I think the issue is that the complexity doesn't scale with the perceived benefits and it feels totally out of whack right now. There's also a lot of cargo-culting going on with massively complicated tools like Gatsby being deployed to build blogs and static marketing pages.
mac_was 6y ago
Agree!
tomiplaz 6y ago
> The complicated web is here because users insist on interaction Do they, though? Or is it the product managers who insist on such things? I'd put more weight on them. Some of it might be backed by user data, but generally it feels like they're pushing things unjustifiably or for wrong reasons.
ryanbrunner 6y ago
This is a common response to complaints about front end complexity, but how true is it, or how true does it have to be? We're posting on a very successful website that could have easily been built in the early 2000s in terms of technology, if not earlier. In my day job, I write server-generated HTML for a growing and successful startup, without React, front-end frameworks or a particularly complicated front-end build setup (we do use AJAX, but in the "deliver server-rendered HTML and inject into the DOM" sense), and the user experience is comparable with many other web apps I use, some of which are almost certainly full-fledged SPAs, and is well-loved by our users. My team's productivity is easily double what I've experienced at jobs using the latest and greatest technologies. Could I use this approach to build Google docs? Probably not, but then again, that's not what I'm building, and I don't need a tool capable of building that.
- j45 6y ago
  There's no shortage of hn clients with increased interaction and none have seemed to be used more than the site itself. Too often interactivity can seem forced where the primary use is consumption of information, like hn. The lack of distractions in the ui allows folks to focus on the conversation to some extent in a way that might be different.
- ZephyrBlu 6y ago
  > we do use AJAX, but in the "deliver server-rendered HTML and inject into the DOM" sense Injecting HTML into the DOM is literally what React does... You can even server render that HTML and then hydrate the DOM with interactivity after the fact. I don't understand why people make the distinction between server rendered and client rendered HTML when React can do both anyway. The main value of React is being able to easily manage client state and efficient updating of the DOM. If not a framework, how do you add interactivity to your pages? Vanilla JS?
  - ryanbrunner 6y ago
    > Injecting HTML into the DOM is literally what React does... The key part of that phrase is "server-rendered", not AJAX. Which yes, is possible with React as well, but it's incredibly rare to see a React app that utilizes actual browser navigation for the majority of it's interactions (posting forms, sessions via cookies, little to no JSON interaction). There's certainly nothing stopping me from using React as a templating language, I don't but whatever, it's a fine choice. When I'm talking about "React apps", I guess I can be a bit more precise and say apps where control flow is dictated by the front end and the backend largely serves as an API (and maybe occasionally bootstraps a view). > If not a framework, how do you add interactivity to your pages? Vanilla JS? Mostly, yeah. We used a bit of Vue early on, but didn't see much benefit, there's still some code kicking around due to be transitioned. We'll use Stimulus when it makes sense, otherwise it's just vanilla JS and maybe helper libraries (checking our package.json, the only libraries we're using that aren't for CSS or third-party things like stripe are stimulus, codemirror, debounce, trix, and vue).
alpaca128 6y ago
User expectations or client expectations? So far I haven't met a user who asked for ads, unmuted autoplaying videos, popups, tracking, loading screens, and UI that's basically broken by design. Did Google really redesign Google Images' UI due to popular demand? I doubt it, because the new one only works 80% of the time when I try to use it. Most websites that are obviously built using modern frameworks and shiny layouts don't let me open links in new tabs, not to mention they're a nightmare for screenreaders and similar tools. And considering how often terms like "responsive" are thrown around it is staggering how easy it is to break many of those sites just by resizing the browser window. In some aspects I'm definitely not the typical user, but to quote Adam Jensen: I never asked for this.
- goodoldneon 6y ago
  IMO, phone apps changed users’ expectations for websites. They want the same interactivity on Facebook.com that they get on the Facebook app. Same with Kayak (or whatever travel site people use these days). Same with Google Maps. However, the vast majority of sites are totally fine as static pages, as long as the user has a fast connection that makes loading between pages imperceptible.
  - CaptArmchair 6y ago
    Well, this goes even deeper. Historically, the Web started out as hypertext: static text documents which were interlinked. But right off the bat, there was this drive to create "Rich Web Applications": the browser as an alternate to applications which you don't need to install on a "gatekept" operating system (Windows and OSX). Flash, Silverlight, Java Web Applets,... All those browser plugins were exactly meant to achieve this. But none of them quite fully lived up to the potential of the idea. There's a good reason why Microsoft in the 90's wanted to dominate the browser market: because it was a potential threat to lose control over what users could or couldn't do with their computers. Things changed when mobile devices landed, and Google jumped into the browser market. Suddenly, building a web experience no longer wasn't as "trivial" as making sure your CSS worked on Explorer, Safari and Firefox. At the same time, the "Application Wars" moved into the mobile realm where there was this battle between "native applications" and "web based applications". The latter was the notion that you could get the same functionality without having to install an app from an app store on your device. Those dynamics of competition were - and still are - a driving force behind innovation that made browser engines ever more powerful and complex. "Front-end" as a dedicate discipline didn't truly exist before the 2010's. You were a web master, a web developer, a web designer or something of the sort. But as soon as that complexity did hit, "front end engineering" became a specialization. Where it is really a cottage industry build on top of those complex browser engines, API's and sprawling specifications. For better or worse. > However, the vast majority of sites are totally fine as static pages, as long as the user has a fast connection that makes loading between pages imperceptible. Exactly. And that's still a completely valid use case. The problem is how the industry has shoehorned an entire generation of front-end developers into believing that you need all those gizmo's to write HTML, CSS and JS. When you're a budding front-end engineer and you land your first job from your internship, you're not even going to question the tools used by your employer. You're just going to use them because all you see is a big black box of complexity and nobody explains the history that has created that box. I think that's why people will, like the author, ultimately drop out. When writing code for a living turns into this obligatory, rote exercise of juggling this mass of dependencies and complexity, with little to no time or authority to question why they need all this in the first place.
j45 6y ago
Efficient interactions might not be the same as effective interactions. Most sites and apps want users to click and engage as much as possible, not necessarily the most efficiently.
braveyellowtoad 6y ago
Yeah agreed on all counts. React apps are a real joy to create. The UI just works like magic with reactive updates. Modern js tooling gives me a fun and effortless way to produce user interfaces.
itronitron 6y ago
complex UIs don't require complex frameworks
- ZephyrBlu 6y ago
  What _do_ they require?
  - itronitron 6y ago
    They require identifying all the interaction paths that a user can take through the application so that any function associated with an interaction can correctly update the state of the application's data model. Vanilla JS, HTML, and CSS.
    - ZephyrBlu 6y ago
      Do you think that's feasible for a website like Facebook? It seems like it would be much more difficult than using a framework.
      - objektif 6y ago
        Why would it not be possible? What cant you do with js that other fancy frameworks can?
        ZephyrBlu 6y ago
        I didn't say not possible, I said feasible. Pretty much anything is possible given enough time, but spending time building a complex application in vanilla JS, HTML and CSS doesn't seem like the most productive use of time when you can leverage a framework.
      - itronitron 6y ago
        Developers that have experience creating native applications are used to writing code that manages the application state and it's relation to UI interactions and data updates. In native-land, the UI frameworks are primarily the UI widgets and all of the application logic is written by the application developers in their chosen language. The corollary to this for web development is that HTML and maybe a few specialized graphics libraries like D3.js provide the UI thingies and the application logic (event handling, data fetching, etc.) is written in Javascript. I'm not familiar with the Facebook website but I can't imagine that it needs any particularly complex application logic under the hood.
YorickPeterse 6y ago
> It's disheartening to explain this over and over again, but these frameworks are a-ok because user's expectations for the web have grown astronomically. Users absolutely don't give a shit about you using Grunt, Gulp, Burb, Babel, and the billions of other tools. They just want to pay the meal they ordered online.
hexo 6y ago
In my not humble at all opinion - user expectations sank to absolute lowest minimum. Oh my, for example I never asked for smooth scrolling (I've actually disabled it in browser), instead someone insists on it and forces that on me with some javascript. Thanks, but no thanks. I can't even have my own scrollbars from system theme most of the time (why even this?!). What we have now is ultra slow interaction because of tons of JS. Constant cpu usage and battery drain. And most importantly boundless memory hogs such as oh so great interacting facebook that easily eats 2.5gigs of memory. And don't get me started about "effects", animations, fades, stolen keyboard shortcuts, right clicks and every other bit that throws accessibility out of the window.
- compscistd 6y ago
  A lot of these gripes seem to be aimed at either poor imitations of well designed and implemented marketing pages or just straight up poor designs. From my experience as a front ender, I want to make the user experience as welcoming as possible instead of replacing native scrolling, stolen keyboard shortcuts, etc. It’s a designer that tries to impose their mock-up on browser defaults and only with front end pushback do we get a mediocre middle ground. There are certainly poor front-end led sites but I think that can go away quickly after some experience in the field. Design is largely shielded from that if they stay in the land of Sketch or Figma instead of interacting with the real web. This problem is as old as time: even in print, it takes experience and planning to visualize a digital composite as a physical object that lives up to your expectations.
jiofih 6y ago
This is the story you want to believe in. I was doing the exact same kind of interactive apps 10 years ago without any of this crap. Some things are easier, but their are not worth the 10x complexity.
twuersch 6y ago
> user's expectations for the web have grown astronomically. Agree with everything you're saying, except for this. I do user research as a job, which means that it is my day job to methodically interview and observe people using everything from web sites to apps to enterprise software. So far, I've had the privilege of doing so with more than 100 users. What users expect is things that work quickly and reliably to get their job done, and then get out of the way. It doesn't matter whether they're booking a flight, buying cell phones or working in a complex workflow system. Nobody, on the other hand, really wants bloated pictures, autoplaying videos, and dozens of different features without practical use - except for marketing people and managers.
vagrantJin 6y ago
> user's expectations for the web have grown astronomically. The complicated web is here because users insist on interaction, Nope Im going all on anecdote. Consider my SO is a youtuber and spends her days doing research for her videos, as do her friends on Tiktok and Insta. Not once has she ever mentioned any expectations despite my asking. She didnt even care about the cool "web app experience" from YT. I don't even think she cares about what I do. Just because we over-engineer things to justify our absurd but nice salaries in the name of maintainability and More speed - more power does not make the mountain of dung smell any better.
tootie 6y ago
Having been around since the pre-CSS days up to the time of attempting to hack my own build pipeline with the YUI compressor, using npm is like a dream. The first batch of tools like grunt were very rough around the edges and hard to use, but the pace of improvements has been extremely impressive. > Unless you're really invested in the product, it becomes hard to maintain enthusiasm. +100 for that one. I spent a lot of time working on some absolutely bleeding edge crazy tech for a shitty client who made some stupid luxury product for rich people. Now I'm working on some 10 year old crufty web app for a non-profit that produces something of genuine public benefit and I'm more satisfied with my work than I have been in a long, long time.
tim333 6y ago
As a user I much prefer old style sites like HN, Wikipedia and the old Reddit to the javascripted up ones for most stuff. And I've got a readability extension to turn monstrosities like bloomberg.com into something like a relaxing page of text.
jariel 6y ago
" The complicated web is here because users insist on interaction, " OR - the means by which we produce systems is vastly more complicated than it needs to be. In other words: HTML is designed for nice, light pages, but it's otherwise a steaming hot mess upon which to build single-page apps etc.. We are building the future on a few layers of archaic tools and the result is massively leaky abstraction. So yes - our toolsets will inevitably expand to make all sorts of useless complexity - that will always be the case. But for doing basic/cores stuff, it should be possible to avoid the trap.
collyw 6y ago
My place is implementing stuff in React, not for any reason, just because. I have suggesting that server side rendering might make things simpler, but it just assumed that we need React in this day an age.
brailsafe 6y ago
I agree, but I'd add that what really gets bland is just how uninteresting the outcome of all the complexity is in most things. For example, a NextJs app normalized into a hundred components, using redux, styles in js, webpack probably, npm scripts, jest, etc.. with the ultimate output being a probably barely responsive mediocre looking standard webpage with a navigation that doesn't work on a device you didn't anticipate because you re-invented links
asdofindia 6y ago
This. Every tool that the author complains about serves a purpose and are optional. Using frameworks can help avoid the complexity of configuration too. https://asd.learnlearn.in/use-a-framework/ https://asd.learnlearn.in/use-a-framework/

catmanjan 6y ago

>user's expectations for the web have grown astronomically Have they? I don't see that in my user stories

deleted 6y ago
[deleted]
paul_f 6y ago
Users just want it to work. I think the problem is too many developers trying to impress each other for status. IMO, what matters most is coding efficiency, how fast can business problems be solved with a low enough error threshold.
- danjac 6y ago
  It's a combination of whimsical requirements from PMs and designers, plus FOMO and resume-driven development among developers. None of which have anything to do with actual end-user needs.
  - throwawayzRUU6f 6y ago
    There's also a Large Corp dynamic, where to maintain consistent user experience across the product portfolio, a common UI platform is built. The platform is then mainly driven by the requirements of the most dynamically interactive applications, leading to a complexity creep - even though most of the products could be simple CRUD web pages.
  - paul_f 6y ago
    "resume-driven development" I think you nailed it.
- peruvian 6y ago
  Companies overhire devs after raising money so it looks like they're doing a lot of interesting stuff. PMs and managers need to find stuff for these devs to do, hence they come up with overcomplicating their existing tech, redesigns, etc.
- why_Mr_Anderson 6y ago
  And on top of that, most users want it to work the same it worked yesterday. Nothing drives me up the wall more than neverending stream of updates for anything and everything, be it PC, mobile, web, even cars. I understand it's great for job security and/or resume-filling, I just wish those developers would consider the difficulty of,for example, trying to explain to 60 years old nurse why the thing that worked yesterday doesn't work anymore or why it suddenly behaves differently.

sneak 6y ago

> It's disheartening to explain this over and over again, but these frameworks are a-ok because user's expectations for the web have grown astronomically. I'm pretty sure that this is not true. You can ship great webapps without any of that overcomplicated nonsense. We're using one such right now.

richeyryan 6y ago
Hacker News is purposely utilitarian and that's fine but I don't think general audiences would tolerate it. You have to manually check if someone responded to your comment. I don't think its too unreasonable to say that most users expect a notifications system on a platform like this. Editing a comment takes you to a separate screen and leaves you there once you're done, you have to manually navigate back to the discussion you were on. Reddit lets you edit your comment in place and continue from where you left off straight away. These features could be feasibly implemented using jQuery or plain JavaScript but the more niceties like that you add, the more you can make the argument for UI frameworks.
- sneak 6y ago
  It seems to me you're confusing HN's lack of some common forum features with the way that those features would be implemented; I would imagine that if HN did get, say, notifications, they would largely work without javascript, or some big complicated frontend build process. old.reddit.com is another good example. Not everything needs to be an SPA.
  - richeyryan 6y ago
    The parent suggested HN as an example of an application that didn't need a lot of client code. I think its still fair to say that it doesn't have many of the features that ordinary users have come to expect. Old reddit is a much more reasonable suggestion. It is fairly feature rich and is used by a large group of users. It seems to deliver ~340KB of Javascript. It's pretty nicely minified so I can't tell what its all related to but at least some of it must be related to the interactivity that HN is missing. Like I said in my previous comment, you can do as old Reddit did and build up Javascript to solve these problems but at some stage it might make sense to jump to an SPA. Reddit made that decision. I think many would argue that they prefer old Reddit which is fair enough. I think its hard to say if the Reddit team made the decision based on a legitimate and provable technical need and their old solution just wasn't cutting it or if they went the SPA route because "its what everyone else does" and "its easier to hire React devs".

jamil7 6y ago

You're not wrong, I think most in this thread won't debate that user expectations are ever increasing. I think the issue is that the complexity doesn't scale with the perceived benefits and it feels totally out of whack right now. There's also a lot of cargo-culting going on with massively complicated tools like Gatsby being deployed to build blogs and static marketing pages.

mac_was 6y ago

Agree!

tomiplaz 6y ago

> The complicated web is here because users insist on interaction Do they, though? Or is it the product managers who insist on such things? I'd put more weight on them. Some of it might be backed by user data, but generally it feels like they're pushing things unjustifiably or for wrong reasons.

ryanbrunner 6y ago

This is a common response to complaints about front end complexity, but how true is it, or how true does it have to be? We're posting on a very successful website that could have easily been built in the early 2000s in terms of technology, if not earlier. In my day job, I write server-generated HTML for a growing and successful startup, without React, front-end frameworks or a particularly complicated front-end build setup (we do use AJAX, but in the "deliver server-rendered HTML and inject into the DOM" sense), and the user experience is comparable with many other web apps I use, some of which are almost certainly full-fledged SPAs, and is well-loved by our users. My team's productivity is easily double what I've experienced at jobs using the latest and greatest technologies. Could I use this approach to build Google docs? Probably not, but then again, that's not what I'm building, and I don't need a tool capable of building that.

j45 6y ago
There's no shortage of hn clients with increased interaction and none have seemed to be used more than the site itself. Too often interactivity can seem forced where the primary use is consumption of information, like hn. The lack of distractions in the ui allows folks to focus on the conversation to some extent in a way that might be different.
ZephyrBlu 6y ago
> we do use AJAX, but in the "deliver server-rendered HTML and inject into the DOM" sense Injecting HTML into the DOM is literally what React does... You can even server render that HTML and then hydrate the DOM with interactivity after the fact. I don't understand why people make the distinction between server rendered and client rendered HTML when React can do both anyway. The main value of React is being able to easily manage client state and efficient updating of the DOM. If not a framework, how do you add interactivity to your pages? Vanilla JS?
- ryanbrunner 6y ago
  > Injecting HTML into the DOM is literally what React does... The key part of that phrase is "server-rendered", not AJAX. Which yes, is possible with React as well, but it's incredibly rare to see a React app that utilizes actual browser navigation for the majority of it's interactions (posting forms, sessions via cookies, little to no JSON interaction). There's certainly nothing stopping me from using React as a templating language, I don't but whatever, it's a fine choice. When I'm talking about "React apps", I guess I can be a bit more precise and say apps where control flow is dictated by the front end and the backend largely serves as an API (and maybe occasionally bootstraps a view). > If not a framework, how do you add interactivity to your pages? Vanilla JS? Mostly, yeah. We used a bit of Vue early on, but didn't see much benefit, there's still some code kicking around due to be transitioned. We'll use Stimulus when it makes sense, otherwise it's just vanilla JS and maybe helper libraries (checking our package.json, the only libraries we're using that aren't for CSS or third-party things like stripe are stimulus, codemirror, debounce, trix, and vue).

alpaca128 6y ago

User expectations or client expectations? So far I haven't met a user who asked for ads, unmuted autoplaying videos, popups, tracking, loading screens, and UI that's basically broken by design. Did Google really redesign Google Images' UI due to popular demand? I doubt it, because the new one only works 80% of the time when I try to use it. Most websites that are obviously built using modern frameworks and shiny layouts don't let me open links in new tabs, not to mention they're a nightmare for screenreaders and similar tools. And considering how often terms like "responsive" are thrown around it is staggering how easy it is to break many of those sites just by resizing the browser window. In some aspects I'm definitely not the typical user, but to quote Adam Jensen: I never asked for this.

goodoldneon 6y ago
IMO, phone apps changed users’ expectations for websites. They want the same interactivity on Facebook.com that they get on the Facebook app. Same with Kayak (or whatever travel site people use these days). Same with Google Maps. However, the vast majority of sites are totally fine as static pages, as long as the user has a fast connection that makes loading between pages imperceptible.
- CaptArmchair 6y ago
  Well, this goes even deeper. Historically, the Web started out as hypertext: static text documents which were interlinked. But right off the bat, there was this drive to create "Rich Web Applications": the browser as an alternate to applications which you don't need to install on a "gatekept" operating system (Windows and OSX). Flash, Silverlight, Java Web Applets,... All those browser plugins were exactly meant to achieve this. But none of them quite fully lived up to the potential of the idea. There's a good reason why Microsoft in the 90's wanted to dominate the browser market: because it was a potential threat to lose control over what users could or couldn't do with their computers. Things changed when mobile devices landed, and Google jumped into the browser market. Suddenly, building a web experience no longer wasn't as "trivial" as making sure your CSS worked on Explorer, Safari and Firefox. At the same time, the "Application Wars" moved into the mobile realm where there was this battle between "native applications" and "web based applications". The latter was the notion that you could get the same functionality without having to install an app from an app store on your device. Those dynamics of competition were - and still are - a driving force behind innovation that made browser engines ever more powerful and complex. "Front-end" as a dedicate discipline didn't truly exist before the 2010's. You were a web master, a web developer, a web designer or something of the sort. But as soon as that complexity did hit, "front end engineering" became a specialization. Where it is really a cottage industry build on top of those complex browser engines, API's and sprawling specifications. For better or worse. > However, the vast majority of sites are totally fine as static pages, as long as the user has a fast connection that makes loading between pages imperceptible. Exactly. And that's still a completely valid use case. The problem is how the industry has shoehorned an entire generation of front-end developers into believing that you need all those gizmo's to write HTML, CSS and JS. When you're a budding front-end engineer and you land your first job from your internship, you're not even going to question the tools used by your employer. You're just going to use them because all you see is a big black box of complexity and nobody explains the history that has created that box. I think that's why people will, like the author, ultimately drop out. When writing code for a living turns into this obligatory, rote exercise of juggling this mass of dependencies and complexity, with little to no time or authority to question why they need all this in the first place.

j45 6y ago

Efficient interactions might not be the same as effective interactions. Most sites and apps want users to click and engage as much as possible, not necessarily the most efficiently.

braveyellowtoad 6y ago

Yeah agreed on all counts. React apps are a real joy to create. The UI just works like magic with reactive updates. Modern js tooling gives me a fun and effortless way to produce user interfaces.

itronitron 6y ago

complex UIs don't require complex frameworks

ZephyrBlu 6y ago
What _do_ they require?
- itronitron 6y ago
  They require identifying all the interaction paths that a user can take through the application so that any function associated with an interaction can correctly update the state of the application's data model. Vanilla JS, HTML, and CSS.
  - ZephyrBlu 6y ago
    Do you think that's feasible for a website like Facebook? It seems like it would be much more difficult than using a framework.
    - objektif 6y ago
      Why would it not be possible? What cant you do with js that other fancy frameworks can?
      - ZephyrBlu 6y ago
        I didn't say not possible, I said feasible. Pretty much anything is possible given enough time, but spending time building a complex application in vanilla JS, HTML and CSS doesn't seem like the most productive use of time when you can leverage a framework.
    - itronitron 6y ago
      Developers that have experience creating native applications are used to writing code that manages the application state and it's relation to UI interactions and data updates. In native-land, the UI frameworks are primarily the UI widgets and all of the application logic is written by the application developers in their chosen language. The corollary to this for web development is that HTML and maybe a few specialized graphics libraries like D3.js provide the UI thingies and the application logic (event handling, data fetching, etc.) is written in Javascript. I'm not familiar with the Facebook website but I can't imagine that it needs any particularly complex application logic under the hood.

YorickPeterse 6y ago

> It's disheartening to explain this over and over again, but these frameworks are a-ok because user's expectations for the web have grown astronomically. Users absolutely don't give a shit about you using Grunt, Gulp, Burb, Babel, and the billions of other tools. They just want to pay the meal they ordered online.

hexo 6y ago

In my not humble at all opinion - user expectations sank to absolute lowest minimum. Oh my, for example I never asked for smooth scrolling (I've actually disabled it in browser), instead someone insists on it and forces that on me with some javascript. Thanks, but no thanks. I can't even have my own scrollbars from system theme most of the time (why even this?!). What we have now is ultra slow interaction because of tons of JS. Constant cpu usage and battery drain. And most importantly boundless memory hogs such as oh so great interacting facebook that easily eats 2.5gigs of memory. And don't get me started about "effects", animations, fades, stolen keyboard shortcuts, right clicks and every other bit that throws accessibility out of the window.

compscistd 6y ago
A lot of these gripes seem to be aimed at either poor imitations of well designed and implemented marketing pages or just straight up poor designs. From my experience as a front ender, I want to make the user experience as welcoming as possible instead of replacing native scrolling, stolen keyboard shortcuts, etc. It’s a designer that tries to impose their mock-up on browser defaults and only with front end pushback do we get a mediocre middle ground. There are certainly poor front-end led sites but I think that can go away quickly after some experience in the field. Design is largely shielded from that if they stay in the land of Sketch or Figma instead of interacting with the real web. This problem is as old as time: even in print, it takes experience and planning to visualize a digital composite as a physical object that lives up to your expectations.

jiofih 6y ago

This is the story you want to believe in. I was doing the exact same kind of interactive apps 10 years ago without any of this crap. Some things are easier, but their are not worth the 10x complexity.

twuersch 6y ago

> user's expectations for the web have grown astronomically. Agree with everything you're saying, except for this. I do user research as a job, which means that it is my day job to methodically interview and observe people using everything from web sites to apps to enterprise software. So far, I've had the privilege of doing so with more than 100 users. What users expect is things that work quickly and reliably to get their job done, and then get out of the way. It doesn't matter whether they're booking a flight, buying cell phones or working in a complex workflow system. Nobody, on the other hand, really wants bloated pictures, autoplaying videos, and dozens of different features without practical use - except for marketing people and managers.

vagrantJin 6y ago

> user's expectations for the web have grown astronomically. The complicated web is here because users insist on interaction, Nope Im going all on anecdote. Consider my SO is a youtuber and spends her days doing research for her videos, as do her friends on Tiktok and Insta. Not once has she ever mentioned any expectations despite my asking. She didnt even care about the cool "web app experience" from YT. I don't even think she cares about what I do. Just because we over-engineer things to justify our absurd but nice salaries in the name of maintainability and More speed - more power does not make the mountain of dung smell any better.

tootie 6y ago

Having been around since the pre-CSS days up to the time of attempting to hack my own build pipeline with the YUI compressor, using npm is like a dream. The first batch of tools like grunt were very rough around the edges and hard to use, but the pace of improvements has been extremely impressive. > Unless you're really invested in the product, it becomes hard to maintain enthusiasm. +100 for that one. I spent a lot of time working on some absolutely bleeding edge crazy tech for a shitty client who made some stupid luxury product for rich people. Now I'm working on some 10 year old crufty web app for a non-profit that produces something of genuine public benefit and I'm more satisfied with my work than I have been in a long, long time.

tim333 6y ago

As a user I much prefer old style sites like HN, Wikipedia and the old Reddit to the javascripted up ones for most stuff. And I've got a readability extension to turn monstrosities like bloomberg.com into something like a relaxing page of text.

jariel 6y ago

" The complicated web is here because users insist on interaction, " OR - the means by which we produce systems is vastly more complicated than it needs to be. In other words: HTML is designed for nice, light pages, but it's otherwise a steaming hot mess upon which to build single-page apps etc.. We are building the future on a few layers of archaic tools and the result is massively leaky abstraction. So yes - our toolsets will inevitably expand to make all sorts of useless complexity - that will always be the case. But for doing basic/cores stuff, it should be possible to avoid the trap.

collyw 6y ago

My place is implementing stuff in React, not for any reason, just because. I have suggesting that server side rendering might make things simpler, but it just assumed that we need React in this day an age.

brailsafe 6y ago

I agree, but I'd add that what really gets bland is just how uninteresting the outcome of all the complexity is in most things. For example, a NextJs app normalized into a hundred components, using redux, styles in js, webpack probably, npm scripts, jest, etc.. with the ultimate output being a probably barely responsive mediocre looking standard webpage with a navigation that doesn't work on a device you didn't anticipate because you re-invented links

asdofindia 6y ago

This. Every tool that the author complains about serves a purpose and are optional. Using frameworks can help avoid the complexity of configuration too. https://asd.learnlearn.in/use-a-framework/ https://asd.learnlearn.in/use-a-framework/