11 ms·

I'd like to add a bit more nuance. Modern frontend development provides many opportunities for failure. These failures often make their way into production. I,

I'd like to add a bit more nuance. Modern frontend development provides many opportunities for failure. These failures often make their way into production. I, personally, get great results with modern FE development. My users are happy. I am happy. It's all very successful. All the defenders of modern FE development will likely chime in with the same sentiment. I also get great results with C, which arguably provides even more catastrophic opportunities for failure. I wouldn't say "C is a failure", but I absolutely hate working in C, and I'm glad we've made improvements to systems programming. I think the point I'm moving toward is that we absolutely should strive to make better tools for delivering web content, but the reasons for failure are far more complex than the tooling itself. So, let's not frame things in black and white and call something that's been used with large amounts of success a failure. That's not very productive and is just flame bait. The real question is, "What's next?", how are we going to improve the current situation?

bjornjajeja 6y ago
I think a lot of it had to do more with business requirements than art or science. The business folks stroll in and make these generic one-click deploy type things to get sites up and running quickly, at the expense of being vetted by good artists and scientists. A good analogy I think is any person using MS publisher to create a book layout. Sure it can be done quickly because the software does the thinking; but should it? Good books have skilled typographers designing the proportions of the pages relative to text block, the fonts, et cetera. The end result is a book that one scarcely notices but feels very pleasant to hold and experience. We need websites that are subservient to their content; sites we scarcely notice but thoroughly enjoy. EDIT: one last point: I think part of the problem is also that browsers have an identity issue. E.G. they started as a static publishing platform, but now they are a full blown operating system with web assembly etc. As we know, anything that does too many things is inherently complex, and hence “bloated.”
darkhorse13 6y ago
>Modern frontend development provides many opportunities for failure I think this is the important thing here. Everything feels less stable, and more prone to breaking, on the modern web. You write some simple HTML, style it with CSS, and write vanilla JS for the parts that need it, and everything feels solid. You start a new project with a framework, and it seems like there is this whole area of your project that is essentially a black box, ready to break (or misbehave) any time.
- selimnairb 6y ago
  At some point, there is an irreducible amount of complexity. At that point, adding things like over-wrought frameworks to “make things easier” for the developer ends up pushing the complexity around, like an air bubble trapped under a screen protector.
  - toast0 6y ago
    There's necessary complexity, and then there's extra complexity. IMHO, a lot of frameworks just add extra complexity. Now that we're in the twenties, you don't need nearly the level of browser compatability shims like at the turn of the century. Sure, bleeding edge features need that, but most sites don't need any of that. Certainly news and shopping fit well enough with turn of the century browsers, so everything else is fluff (and retargetting, ugh). It's the same with a lot of server side frameworks; especially PHP frameworks. I've never been able to grasp what a PHP framework can do that PHP can't, other than burn 50ms of cpu before outputting anything.
    - cutler 6y ago
      Yes, we now have what everyone fought for in the 00s - browser support for web standards - as well as full ES6 support yet here we are with front-end devs falling like flies from burnout. It's like CPU speed bumps - all we do is just invent more complexity to whittle away the gains we've made. Makes me just want to revert to procedural PHP and jQuery/vanailla JS.
- martinald 6y ago
  This is a really rose tinted view of the world. Writing JavaScript works ok now the language and browser support has matured. 10 years ago it was a complete nightmare. Regardless without a framework it ends up with you reinventing core framework features anyway. Yes, a framework driven app is more complex if the page/app is extremely simple. But if it is of any complexity a framework driven app is going to be far easier to maintain and reason about in 99% of situations.
  - 6y ago
j-krieger 6y ago
I love modern frontend development. I can build apps that scale easily to hundreds of thousands of users. They are fast where they need to be fast, and building components means complexity lives only where it's needed. Static parts are rendered statically, dynamic parts are rendered dynamically. I can write all code for the entire stack in Javascript. The entire workflow is streamlined in a simple way (webpack really isn't that hard to grok). There are templates for every project imaginable. I don't need an entire VPS for my web-apps, just a simple static hosting service. My apps run on every system and any browser back to IE9 without any issues whatsoever. No complex build tools or linking process or debugging weird architectures needed. Compatibility issues are solved automatically in any modern build pipeline by adding vendor prefixes. New code is transpiled to old code for older browsers. Debugging modern front-end code is a breeze, there are an infinite amount of tools both for styling and the code itself. My modern frontend app takes seconds to build; QT apps I built in the past needed up to twenty minutes, just to check a simple change. No need for that with hot reloading. My users are happy too: They don't have to download an app which might not work on their specific system. Linux, Windows and Mac users alike can use it on their computers, laptops, tablets and phones without any issue. They can use the default environment a browser provides for an even better user experience (zooming, Screenreaders, upscaling fonts, copying images and text, preferences for dark mode, theming their browsers, saving credentials and auto filling them, sharing stuff, etc.). Integrating stuff from other companies has never been easier: Paypal, Stripe, Apple Products all provide a well tested and documented library for every framework out there. There are open source packages for anything, it's a FOSS dream. Building prototypes for anything is insanely fast, thanks to modern debugging tools in Chrome and FireFox. It's much better than people make it out to be.
- martinald 6y ago
  I agree entirely. The worst sites are imo the ones not using modern frontend technologies. I think people are forgetting how bad it used to be. Loads of jquery spaghetti code everywhere rerendering the page 1000 times with a nested for loop. Also, web applications have became so much more complex than they were (but still work!). Things like Figma would be unthinkable even a few years ago. And - even though it's running in a browser Figma feels far more responsive than Illustrator or Fireworks (RIP), plus it has a load of collaboration tools which these desktop apps don't have.
pytlicek 6y ago
Can't agree more on this...
1337shadow 6y ago
I think modern FE won over is primarily because it provides with Decorator OO, which has been recommended for GUI development including by the GoF for ages, which also matches perfectly with a tag-based declarative language such as HTML. As such, ditching the "HTML templates" paradigm was a no brainer for OO devs to start with. For many, "templates", their performance, their restricted mini language and all the boilerplate that comes with it, just had to die. But then, with Angular/React/etc, you now not only have 1 project on your hands but 2 different projects that must be compatible: the backend and the frontend. These 2 different projects ought to be in 2 different languages, unless you are developing backend in JS too - maybe there's even an ORM that can generate migrations these days for NodeJS ! But that wasn't the case last time I checked, also loosing the ability to have server side rendering without the additional effort of deploying a rendering server with all that comes with it. People ditched jQuery saying that vanilla JS was just fine, but it turned out not to be quite the case so there are still releases of jQuery, and at the same time NodeJS was released and npm and then Angular/React/etc which in my opinion created with two goals in mind 0. having OO components for GUI dev and 1. offer IoC to overcome the difficulty of dealing with custom component lifecycle like in jQuery which leaves you to monitor the DOM and instantiate / destroy each plugin by yourself. Idk if there are other reasons, but it seems to me that apart from that, that DHTML is still pretty much the same: you're adding some logic to change tags and attributes, anyway. Today we have a chance to break these silos again with the Web Components and ESM browser feature and W3C standard because it does solves elegantly the problems that React/etc seemed to be designed for and do no impose a frontend framework, you can just load the script in your page and start using <custom-tag your-option=...>... The browser will manage the Component lifecycle efficiently, and devs can use it in their templates without having to load a framework so everybody wins. This is also a chance to simplify our code, levitate by throwing away dependencies. Of course if you want to do full client side navigation with an API backend you still can, but you can make generic components that you will also be able to reuse in other projects that do not use a particular framework. You need no tool to make a web component, this is an example of a jquery plugin that was ported to a web component which has no dependency, with browser tests in Python: https://yourlabs.io/oss/autocomplete-light/-/blob/master/autocomplete-light.js https://yourlabs.io/oss/autocomplete-light/-/blob/master/aut... Webpack does a lot, still slow for development be we're seeing the light with Snowpack and esbuild, allowing to have webpack in production only (ie. to generate a bundle in Dockerfile) and benefit from actually instant reload thanks to ESM. So if you go for web components and snowpack, you get an extremely lightweight toolkit which I love that will work for every page that's not an overly complicated web app. But then I thought I actually don't have so much frontend code, it would be nice to have it along with the backend code, so we went for a python->js transpiler to develop web components in pure python which also replace templates, it was surprisingly fast to implement: https://yourlabs.io/oss/ryzom#javascript https://yourlabs.io/oss/ryzom#javascript Is this improving the situation or not depends on your POV, heck I'd understand if you even hold it against me, but the frontend development tooling is still evolving for sure, and I can see how the browsers are doing efforts (except Safari) to simplify DHTML development, because: “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.” – C.A.R. Hoare, The 1980 ACM Turing Award Lecture
antonzabirko 6y ago
You are confused about your comparisons because the largest reason for FE failure is bloated code, an unrelated problem to the dangers of C.
- caseymarquis 6y ago
  C is to Rust as Webpack is to ______.
macintux 6y ago
> My users are happy. Are they? I'm skeptical we can know that for any given website; specifically, accessibility is a huge pain point for so many sites, and it would seem difficult to know how many people are turned away from a site because it isn't set up to serve them.
davedx 6y ago
Personally I think most of the "failures" out there are caused by organisational issues not technology issues. Namely, marketing departments given all the power over what the website does and what's bundled with it (trackers, a bunch of heavy/intrusive marketing tools), and optimisation that values increasing revenue above increasing actual usability. (Sometimes these align; often they don't). You can make a SPA that's a joy to use and loads and runs extremely fast. Hardware has never been faster; browsers and application frameworks have never been as good as this (I'm talking about the web stack). It's really nothing to do with the tools or technologies that marketing insists it needs mixpanel, GTM, optimizely, hotjar, FB pixel, smooch, and god knows whatever else in order to do its job effectively.
postalrat 6y ago
Whats the business case for less JS? Recently the company I worked for started a project where it seemed pretty clear to me would be possible to develop with very little JS running on the frontend. But I couldn't convince anyone of it because no one saw enough benefit from doing it that way.
- redis_mlc 6y ago
  You could use this as a starting point: Since you have to validate on the server side for security reasons anyway, you're duplicating logic in javascript. But the real argument comes down to vanill-js vs bloat. Since I use vanilla-ja, the amount of js will always be minimal.

bjornjajeja 6y ago

I think a lot of it had to do more with business requirements than art or science. The business folks stroll in and make these generic one-click deploy type things to get sites up and running quickly, at the expense of being vetted by good artists and scientists. A good analogy I think is any person using MS publisher to create a book layout. Sure it can be done quickly because the software does the thinking; but should it? Good books have skilled typographers designing the proportions of the pages relative to text block, the fonts, et cetera. The end result is a book that one scarcely notices but feels very pleasant to hold and experience. We need websites that are subservient to their content; sites we scarcely notice but thoroughly enjoy. EDIT: one last point: I think part of the problem is also that browsers have an identity issue. E.G. they started as a static publishing platform, but now they are a full blown operating system with web assembly etc. As we know, anything that does too many things is inherently complex, and hence “bloated.”

darkhorse13 6y ago

>Modern frontend development provides many opportunities for failure I think this is the important thing here. Everything feels less stable, and more prone to breaking, on the modern web. You write some simple HTML, style it with CSS, and write vanilla JS for the parts that need it, and everything feels solid. You start a new project with a framework, and it seems like there is this whole area of your project that is essentially a black box, ready to break (or misbehave) any time.

selimnairb 6y ago
At some point, there is an irreducible amount of complexity. At that point, adding things like over-wrought frameworks to “make things easier” for the developer ends up pushing the complexity around, like an air bubble trapped under a screen protector.
- toast0 6y ago
  There's necessary complexity, and then there's extra complexity. IMHO, a lot of frameworks just add extra complexity. Now that we're in the twenties, you don't need nearly the level of browser compatability shims like at the turn of the century. Sure, bleeding edge features need that, but most sites don't need any of that. Certainly news and shopping fit well enough with turn of the century browsers, so everything else is fluff (and retargetting, ugh). It's the same with a lot of server side frameworks; especially PHP frameworks. I've never been able to grasp what a PHP framework can do that PHP can't, other than burn 50ms of cpu before outputting anything.
  - cutler 6y ago
    Yes, we now have what everyone fought for in the 00s - browser support for web standards - as well as full ES6 support yet here we are with front-end devs falling like flies from burnout. It's like CPU speed bumps - all we do is just invent more complexity to whittle away the gains we've made. Makes me just want to revert to procedural PHP and jQuery/vanailla JS.
martinald 6y ago
This is a really rose tinted view of the world. Writing JavaScript works ok now the language and browser support has matured. 10 years ago it was a complete nightmare. Regardless without a framework it ends up with you reinventing core framework features anyway. Yes, a framework driven app is more complex if the page/app is extremely simple. But if it is of any complexity a framework driven app is going to be far easier to maintain and reason about in 99% of situations.
- 6y ago

j-krieger 6y ago

I love modern frontend development. I can build apps that scale easily to hundreds of thousands of users. They are fast where they need to be fast, and building components means complexity lives only where it's needed. Static parts are rendered statically, dynamic parts are rendered dynamically. I can write all code for the entire stack in Javascript. The entire workflow is streamlined in a simple way (webpack really isn't that hard to grok). There are templates for every project imaginable. I don't need an entire VPS for my web-apps, just a simple static hosting service. My apps run on every system and any browser back to IE9 without any issues whatsoever. No complex build tools or linking process or debugging weird architectures needed. Compatibility issues are solved automatically in any modern build pipeline by adding vendor prefixes. New code is transpiled to old code for older browsers. Debugging modern front-end code is a breeze, there are an infinite amount of tools both for styling and the code itself. My modern frontend app takes seconds to build; QT apps I built in the past needed up to twenty minutes, just to check a simple change. No need for that with hot reloading. My users are happy too: They don't have to download an app which might not work on their specific system. Linux, Windows and Mac users alike can use it on their computers, laptops, tablets and phones without any issue. They can use the default environment a browser provides for an even better user experience (zooming, Screenreaders, upscaling fonts, copying images and text, preferences for dark mode, theming their browsers, saving credentials and auto filling them, sharing stuff, etc.). Integrating stuff from other companies has never been easier: Paypal, Stripe, Apple Products all provide a well tested and documented library for every framework out there. There are open source packages for anything, it's a FOSS dream. Building prototypes for anything is insanely fast, thanks to modern debugging tools in Chrome and FireFox. It's much better than people make it out to be.

martinald 6y ago
I agree entirely. The worst sites are imo the ones not using modern frontend technologies. I think people are forgetting how bad it used to be. Loads of jquery spaghetti code everywhere rerendering the page 1000 times with a nested for loop. Also, web applications have became so much more complex than they were (but still work!). Things like Figma would be unthinkable even a few years ago. And - even though it's running in a browser Figma feels far more responsive than Illustrator or Fireworks (RIP), plus it has a load of collaboration tools which these desktop apps don't have.

pytlicek 6y ago

Can't agree more on this...

1337shadow 6y ago

I think modern FE won over is primarily because it provides with Decorator OO, which has been recommended for GUI development including by the GoF for ages, which also matches perfectly with a tag-based declarative language such as HTML. As such, ditching the "HTML templates" paradigm was a no brainer for OO devs to start with. For many, "templates", their performance, their restricted mini language and all the boilerplate that comes with it, just had to die. But then, with Angular/React/etc, you now not only have 1 project on your hands but 2 different projects that must be compatible: the backend and the frontend. These 2 different projects ought to be in 2 different languages, unless you are developing backend in JS too - maybe there's even an ORM that can generate migrations these days for NodeJS ! But that wasn't the case last time I checked, also loosing the ability to have server side rendering without the additional effort of deploying a rendering server with all that comes with it. People ditched jQuery saying that vanilla JS was just fine, but it turned out not to be quite the case so there are still releases of jQuery, and at the same time NodeJS was released and npm and then Angular/React/etc which in my opinion created with two goals in mind 0. having OO components for GUI dev and 1. offer IoC to overcome the difficulty of dealing with custom component lifecycle like in jQuery which leaves you to monitor the DOM and instantiate / destroy each plugin by yourself. Idk if there are other reasons, but it seems to me that apart from that, that DHTML is still pretty much the same: you're adding some logic to change tags and attributes, anyway. Today we have a chance to break these silos again with the Web Components and ESM browser feature and W3C standard because it does solves elegantly the problems that React/etc seemed to be designed for and do no impose a frontend framework, you can just load the script in your page and start using <custom-tag your-option=...>... The browser will manage the Component lifecycle efficiently, and devs can use it in their templates without having to load a framework so everybody wins. This is also a chance to simplify our code, levitate by throwing away dependencies. Of course if you want to do full client side navigation with an API backend you still can, but you can make generic components that you will also be able to reuse in other projects that do not use a particular framework. You need no tool to make a web component, this is an example of a jquery plugin that was ported to a web component which has no dependency, with browser tests in Python: https://yourlabs.io/oss/autocomplete-light/-/blob/master/autocomplete-light.js https://yourlabs.io/oss/autocomplete-light/-/blob/master/aut... Webpack does a lot, still slow for development be we're seeing the light with Snowpack and esbuild, allowing to have webpack in production only (ie. to generate a bundle in Dockerfile) and benefit from actually instant reload thanks to ESM. So if you go for web components and snowpack, you get an extremely lightweight toolkit which I love that will work for every page that's not an overly complicated web app. But then I thought I actually don't have so much frontend code, it would be nice to have it along with the backend code, so we went for a python->js transpiler to develop web components in pure python which also replace templates, it was surprisingly fast to implement: https://yourlabs.io/oss/ryzom#javascript https://yourlabs.io/oss/ryzom#javascript Is this improving the situation or not depends on your POV, heck I'd understand if you even hold it against me, but the frontend development tooling is still evolving for sure, and I can see how the browsers are doing efforts (except Safari) to simplify DHTML development, because: “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.” – C.A.R. Hoare, The 1980 ACM Turing Award Lecture

antonzabirko 6y ago

You are confused about your comparisons because the largest reason for FE failure is bloated code, an unrelated problem to the dangers of C.

caseymarquis 6y ago
C is to Rust as Webpack is to ______.

macintux 6y ago

> My users are happy. Are they? I'm skeptical we can know that for any given website; specifically, accessibility is a huge pain point for so many sites, and it would seem difficult to know how many people are turned away from a site because it isn't set up to serve them.

davedx 6y ago

Personally I think most of the "failures" out there are caused by organisational issues not technology issues. Namely, marketing departments given all the power over what the website does and what's bundled with it (trackers, a bunch of heavy/intrusive marketing tools), and optimisation that values increasing revenue above increasing actual usability. (Sometimes these align; often they don't). You can make a SPA that's a joy to use and loads and runs extremely fast. Hardware has never been faster; browsers and application frameworks have never been as good as this (I'm talking about the web stack). It's really nothing to do with the tools or technologies that marketing insists it needs mixpanel, GTM, optimizely, hotjar, FB pixel, smooch, and god knows whatever else in order to do its job effectively.

postalrat 6y ago

Whats the business case for less JS? Recently the company I worked for started a project where it seemed pretty clear to me would be possible to develop with very little JS running on the frontend. But I couldn't convince anyone of it because no one saw enough benefit from doing it that way.

redis_mlc 6y ago
You could use this as a starting point: Since you have to validate on the server side for security reasons anyway, you're duplicating logic in javascript. But the real argument comes down to vanill-js vs bloat. Since I use vanilla-ja, the amount of js will always be minimal.