9 ms·

The biggest problem facing the front-end space today isn't so much of complexity of a particular library, rendering technique, or view/model architecture, but r

The biggest problem facing the front-end space today isn't so much of complexity of a particular library, rendering technique, or view/model architecture, but rather lots of bad ideas glued together, creating nightmare scenarios for companies trying to maintain products. A micro dependency system with never ending breaking changes to glue different tools and libraries together - bad idea. Using un-opinionated "libraries" that don't scale well, but at scale - bad idea. Technology organizations trying to stay relevant by simply adopting every next hyped fad out there, rather than stepping back to get a bigger picture of what the front-end space actually needs - bad idea. The list goes on, for quite a long time. And all of these issues are further exacerbated by an army of junior developers entering the front-end development space, along with recruiters subscribing to buzzwords to hire them.

_djvl 4y ago
This! The problem is also that as our apps grow the server side part of it and the client side part of it grow at pretty much the same rate. For each new functionality added on the backend we end up writing more UI code. This is a problem. We need start thinking of how a UI frontend can be implemented as a separate app completely independent and agnostic to the backend. To the extent that I can simple take the same frontend code and plug it to any compatible backend and things will just work. We need to develop a frontend client that can work with any backend (your app, my app, her app). The UI across all apps is mostly the same and we keep rewriting the same JS/HTML (albeit using different JS libraries) each time we build a new app. This is the problem. Let's start thinking of how we can build a general-purpose frontend client which doesn't work on low-level details (JS/HTML) but on higher level abstractions.
eastbound 4y ago
Hiring is my problem. They all want to use NPM/React/any fad or not do front-end at all.
mckravchyk 4y ago
I use React and Svelte for different projects. I keep things really simple and it's rare that I need to rely on an external runtime dependency (build tools are another thing), if something is relatively small I will code it myself. I have also built my own state management library (not open sourced yet) that is literally exactly what I wanted out of state management, so I don't need to rely on gazillion plugins to make something possible, I just code it myself.
jimmont 4y ago
the primary solution to all this is to remove technologies which are not required and especially those that duplicate what the web as a platform provides (ie works in browsers/runtime directly); for example React has been technically obsolete a few years, yet that doesn't mean anyone understands what to do instead, regardless of whether those technical implementations were ubiquitous 1 year ago or 15 years ago; I find it remarkable to read job listings for up and coming concerns (eg Anduril, BioNTech, etc) basing their platforms on long outdated notions and implementations, which bring with them multiple vectors for risk to security and more (unnecessary) costs to developer productivity, complexity; SASS and npm/yarn are other obvious examples of tech that costs more than it benefits in modern work.
P5fRxh5kUvp2th 4y ago
Over the last 3 years I've started to feel more and more vindicated. I explicitly opted out of most web development when it turned into angular/react and later vue. I've done work in both angular and vue so I've not been able to avoid them completely, but mostly. And the reason was a fundamental disagreement with their approach. It has _always_ felt to me like people took a good idea (AJAX) and took it entirely too far. And they found themselves fighting fundamentally with the browser, so the industry's solution was to create new standards such as the history API, when the REAL solution was to just not do what they were doing. Does react bring legitimate good ideas? Probably, somewhere, but thank god we're starting to see the light at the end of the tunnel. imo the best thing to come out of it all is typescript.
dmix 4y ago
Any project that changes often is going to break often. When it involves dependencies that are constantly upgrading or being added it doubly adds risk of breakage. Test coverage and being conservative with adding new dependencies/concepts is always a valuable culture to develop for any frontend team working with junior devs. A good CTO/senior dev can clamp down on this behaviour.
hinkley 4y ago
To me one of the unsung skill sets of the industry is tool selection. The ability to look at a tool and imagine how it’s going to behave for different pay grades of coworkers, different specialties, and to predict how that will pan out in the future. Sometimes you pick the simpler tool, and hope it has legs. Sometimes you tweak your product roadmap to dovetail with the tool’s. Sometimes you push to get 25% of a feature set released so you can make progress. Sometimes you temporarily add another tool, and sometimes you fork for a while. What most people just do though is measure power of the system, ignoring the Principle of Least Power for third party code, if not in fact for the entire project. Approachability is often better than power. Quickly knowing what a tool can or cannot do is generally more productive and results in less politics (who hasn’t worked on a project where person A keeps criticizing Group B for not knowing the framework can just do the thing they wrote, but it’s not immediately obvious that it can? That’s someone tearing down the team to boost their own ego. I don’t like it. I liked it even less when I was the one doing it. Don’t be That Guy, he’s an asshole)
- _glass 4y ago
  Yes, and even though a lot of tech companies killed the architect role, this is exactly the job function assigned to architects, or more specifically enterprise architects in a lot of more traditional companies.
  - hinkley 4y ago
    I haven’t had a lot of luck with architects. In one case I came to a company that got rid of their architect and hired me and another person to replace him (to be fair they were too small to warrant a full time role anyway, not sure what they were thinking). Especially in the post refactoring era, they tend to have an inaccurate account of what the code is actually like and make bad calls based on bad info. It’s a responsibility that works better when the people have their hands in the code. I’ve had better luck with Architecture as a job description shared by the lead developers. In large enough companies they have Staff Engineer that scratches that itch with perhaps slightly less people skills (though I really don’t recommend it).
arcturus17 4y ago
I agree with everything you say, but I'm in the camp that thinks that front-end is stabilizing. I feel many web projects can go a long way with something like NextJS, a few classic libs (eg, lodash/underscore/ramda), maybe a few libraries for handling data if you really need them. The design frameworks (MaterialUI, Tailwind, etc.) are also fairly stable. Perhaps that's one dependency too many for some?
- sph 4y ago
  I've heard that the frontend is stabilising since jQuery came out. Now it's the React devs saying it, but this time for real.
  - arcturus17 4y ago
    Nearly 10 years after the release of the library, React is by far the most commonly used framework according to the 2021 SO dev survey. It is also the number 4 most loved. [1] I'm a React dev as much as I am a Python or C# dev. I reach for tools that I know I can build in and hire for. It's been years since I use React with a single command line to kickstart a CRA or Next app, and take it from there. Yes, there are pitfalls once you start building anything non-trivial, but so does Django which has been around since 2005 and by virtue of being back-end should be more stable.
- CharlieDigital 4y ago
  Next.js is really bad, IMO and perpetuates more bad practices. Both Target.com and Walmart.com are Next.js apps. Both utilize SSR to render the pages (view the markup in the network tab). Both then STILL send the full data model to the UI (check the `__NEXT_DATA__` on Walmart.com and `__TGT_DATA__` on Target.com) because Next.js doesn't quite offer the right amount of control over what to send back (compare this to Astro.js, which does offer control over which data is needed for the client-side binding). Next.js handling of images is ugly. It creates tag soup for responsive images instead of using native HTML and CSS capabilities (again, compare it to Astro.js and it's night and day). Their stunt and exaggerated numbers with Turbopack further contributes to fracturing the front-end community and introduces Yet Another Tool instead of plugging into Vite.
heather45879 4y ago
I like to go back to the basics. It irks me that folks don’t think HTML/CSS/JavaScript are good enough as-is—but nowadays the default browser capabilities are incredible compared to a decade ago. We basically have a full programming environment and add WASM to the mix! Back in the day the frameworks were first-and-foremost a platform compatibility solution. People often have it ingrained in their psyche that reinventing the wheel is evil, but it’s not—we do it all the time when we write paragraphs. It’s of course tempting to grab a library but there’s a learning curve and an often hidden long-term cost with using libraries.
- alerighi 4y ago
  In a modern web framework you still have HTML and you still have CSS files. The problem is JavaScript and in particular the way that you interact with the DOM: browsers use an imperative API, that this day is obsolete, and makes writing web applications a mess rapidly, and produce spaghetti code difficult to modify and isolate. While practically all modern frameworks use a functional approach: you have the component, that has an internal state, a function to render DOM elements from that state, and if you need to update the view you don't directly manipulate the DOM elements, but update the component state, that causes the framework to call again the render function that updates the DOM elements as required. That is so much simpler, because you don't have to ensure that the state of the application is aligned with the state of what the user sees on the screen!
  - resonious 4y ago
    I definitely see the elegance of the modern reactive approach, but in practice I'm not sure how much better it really is. I still see spaghetti code, and I still see stupid bugs in production. Doesn't seem to matter whether it's JQuery or Vue. Right now I'd bet that careful architecture and thorough testing are still #1 for making good software.
    - danielvaughn 4y ago
      It does often turn into a weird kind of spaghetti when it comes to things that are inherently imperative. Sometimes hooks make me feel like I’m trying to follow a Tarantino script.
_the_inflator 4y ago
As the old saying goes: "We have a new framework that will make the existing ones obsolete." This makes n+1, not 1. An agency usually deals with different customers, different settings. What I achieved by migrating dozens of apps to a Angular only frontend, is a platform. Reusable components, devs that can easily switch projects. This is the one and only framework we use, monoculture. This is a beast, we could abstract away certain processes and developed a No Code Editor on top of the component platform. This Editor handles alone 100+ apps. No pain what so ever with migrating from Angular version to version. Best decision ever, so many benefits, even in abstract logical terms, for example, we could simply compile into any other framework by rebuilding some of the components in another framework. You won't get these benefits, if you fall for fad after fad. Monocultures help in certain settings.
- tartoran 4y ago
  I could see Angular working out great for certain type of projects and teams. I used it for one project for front end and didn’t dislike it at all. Unfortunately I see Angular relegated in favor of React mostly..
  - pjmlp 4y ago
    Angular is still the go to framework in Java and .NET shops when a SPA is part of the project. It is kind of changing in Sitecore projects, because they have a collaboration deal with Vercel, and are pushing Next.JS/React as the main framework for headless CMS workloads.
papito 4y ago
Back in the day we had this mantra - "complexity kills". Boy, did it take us another decade to learn the same lesson - AGAIN.
shanebellone 4y ago
I agree with the dependency commentary. Tech should value supply chain. Development is slower but Power comes from ownership. I'm also anti-JavaScript, at least in abundance. I noticed this in gaming as well as software... engineers always build for the best hardware. Despite everyone knowing that extremes (in the wild) are a minority. I believe tech needs to focus on building better 4-cylinders rather than expanding cubic inches.
- imbnwa 4y ago
  Partly think that's why there was some dismay at Deno's decision to tunnel packages from NPM, a contingent of folk who wanted a reset on the JS ecosystem and (lack of?) culture

_djvl 4y ago

This! The problem is also that as our apps grow the server side part of it and the client side part of it grow at pretty much the same rate. For each new functionality added on the backend we end up writing more UI code. This is a problem. We need start thinking of how a UI frontend can be implemented as a separate app completely independent and agnostic to the backend. To the extent that I can simple take the same frontend code and plug it to any compatible backend and things will just work. We need to develop a frontend client that can work with any backend (your app, my app, her app). The UI across all apps is mostly the same and we keep rewriting the same JS/HTML (albeit using different JS libraries) each time we build a new app. This is the problem. Let's start thinking of how we can build a general-purpose frontend client which doesn't work on low-level details (JS/HTML) but on higher level abstractions.

eastbound 4y ago

Hiring is my problem. They all want to use NPM/React/any fad or not do front-end at all.

mckravchyk 4y ago

I use React and Svelte for different projects. I keep things really simple and it's rare that I need to rely on an external runtime dependency (build tools are another thing), if something is relatively small I will code it myself. I have also built my own state management library (not open sourced yet) that is literally exactly what I wanted out of state management, so I don't need to rely on gazillion plugins to make something possible, I just code it myself.

jimmont 4y ago

the primary solution to all this is to remove technologies which are not required and especially those that duplicate what the web as a platform provides (ie works in browsers/runtime directly); for example React has been technically obsolete a few years, yet that doesn't mean anyone understands what to do instead, regardless of whether those technical implementations were ubiquitous 1 year ago or 15 years ago; I find it remarkable to read job listings for up and coming concerns (eg Anduril, BioNTech, etc) basing their platforms on long outdated notions and implementations, which bring with them multiple vectors for risk to security and more (unnecessary) costs to developer productivity, complexity; SASS and npm/yarn are other obvious examples of tech that costs more than it benefits in modern work.

P5fRxh5kUvp2th 4y ago

Over the last 3 years I've started to feel more and more vindicated. I explicitly opted out of most web development when it turned into angular/react and later vue. I've done work in both angular and vue so I've not been able to avoid them completely, but mostly. And the reason was a fundamental disagreement with their approach. It has _always_ felt to me like people took a good idea (AJAX) and took it entirely too far. And they found themselves fighting fundamentally with the browser, so the industry's solution was to create new standards such as the history API, when the REAL solution was to just not do what they were doing. Does react bring legitimate good ideas? Probably, somewhere, but thank god we're starting to see the light at the end of the tunnel. imo the best thing to come out of it all is typescript.

dmix 4y ago

Any project that changes often is going to break often. When it involves dependencies that are constantly upgrading or being added it doubly adds risk of breakage. Test coverage and being conservative with adding new dependencies/concepts is always a valuable culture to develop for any frontend team working with junior devs. A good CTO/senior dev can clamp down on this behaviour.

hinkley 4y ago

To me one of the unsung skill sets of the industry is tool selection. The ability to look at a tool and imagine how it’s going to behave for different pay grades of coworkers, different specialties, and to predict how that will pan out in the future. Sometimes you pick the simpler tool, and hope it has legs. Sometimes you tweak your product roadmap to dovetail with the tool’s. Sometimes you push to get 25% of a feature set released so you can make progress. Sometimes you temporarily add another tool, and sometimes you fork for a while. What most people just do though is measure power of the system, ignoring the Principle of Least Power for third party code, if not in fact for the entire project. Approachability is often better than power. Quickly knowing what a tool can or cannot do is generally more productive and results in less politics (who hasn’t worked on a project where person A keeps criticizing Group B for not knowing the framework can just do the thing they wrote, but it’s not immediately obvious that it can? That’s someone tearing down the team to boost their own ego. I don’t like it. I liked it even less when I was the one doing it. Don’t be That Guy, he’s an asshole)

_glass 4y ago
Yes, and even though a lot of tech companies killed the architect role, this is exactly the job function assigned to architects, or more specifically enterprise architects in a lot of more traditional companies.
- hinkley 4y ago
  I haven’t had a lot of luck with architects. In one case I came to a company that got rid of their architect and hired me and another person to replace him (to be fair they were too small to warrant a full time role anyway, not sure what they were thinking). Especially in the post refactoring era, they tend to have an inaccurate account of what the code is actually like and make bad calls based on bad info. It’s a responsibility that works better when the people have their hands in the code. I’ve had better luck with Architecture as a job description shared by the lead developers. In large enough companies they have Staff Engineer that scratches that itch with perhaps slightly less people skills (though I really don’t recommend it).

arcturus17 4y ago

I agree with everything you say, but I'm in the camp that thinks that front-end is stabilizing. I feel many web projects can go a long way with something like NextJS, a few classic libs (eg, lodash/underscore/ramda), maybe a few libraries for handling data if you really need them. The design frameworks (MaterialUI, Tailwind, etc.) are also fairly stable. Perhaps that's one dependency too many for some?

sph 4y ago
I've heard that the frontend is stabilising since jQuery came out. Now it's the React devs saying it, but this time for real.
- arcturus17 4y ago
  Nearly 10 years after the release of the library, React is by far the most commonly used framework according to the 2021 SO dev survey. It is also the number 4 most loved. [1] I'm a React dev as much as I am a Python or C# dev. I reach for tools that I know I can build in and hire for. It's been years since I use React with a single command line to kickstart a CRA or Next app, and take it from there. Yes, there are pitfalls once you start building anything non-trivial, but so does Django which has been around since 2005 and by virtue of being back-end should be more stable.
CharlieDigital 4y ago
Next.js is really bad, IMO and perpetuates more bad practices. Both Target.com and Walmart.com are Next.js apps. Both utilize SSR to render the pages (view the markup in the network tab). Both then STILL send the full data model to the UI (check the `__NEXT_DATA__` on Walmart.com and `__TGT_DATA__` on Target.com) because Next.js doesn't quite offer the right amount of control over what to send back (compare this to Astro.js, which does offer control over which data is needed for the client-side binding). Next.js handling of images is ugly. It creates tag soup for responsive images instead of using native HTML and CSS capabilities (again, compare it to Astro.js and it's night and day). Their stunt and exaggerated numbers with Turbopack further contributes to fracturing the front-end community and introduces Yet Another Tool instead of plugging into Vite.

heather45879 4y ago

I like to go back to the basics. It irks me that folks don’t think HTML/CSS/JavaScript are good enough as-is—but nowadays the default browser capabilities are incredible compared to a decade ago. We basically have a full programming environment and add WASM to the mix! Back in the day the frameworks were first-and-foremost a platform compatibility solution. People often have it ingrained in their psyche that reinventing the wheel is evil, but it’s not—we do it all the time when we write paragraphs. It’s of course tempting to grab a library but there’s a learning curve and an often hidden long-term cost with using libraries.

alerighi 4y ago
In a modern web framework you still have HTML and you still have CSS files. The problem is JavaScript and in particular the way that you interact with the DOM: browsers use an imperative API, that this day is obsolete, and makes writing web applications a mess rapidly, and produce spaghetti code difficult to modify and isolate. While practically all modern frameworks use a functional approach: you have the component, that has an internal state, a function to render DOM elements from that state, and if you need to update the view you don't directly manipulate the DOM elements, but update the component state, that causes the framework to call again the render function that updates the DOM elements as required. That is so much simpler, because you don't have to ensure that the state of the application is aligned with the state of what the user sees on the screen!
- resonious 4y ago
  I definitely see the elegance of the modern reactive approach, but in practice I'm not sure how much better it really is. I still see spaghetti code, and I still see stupid bugs in production. Doesn't seem to matter whether it's JQuery or Vue. Right now I'd bet that careful architecture and thorough testing are still #1 for making good software.
  - danielvaughn 4y ago
    It does often turn into a weird kind of spaghetti when it comes to things that are inherently imperative. Sometimes hooks make me feel like I’m trying to follow a Tarantino script.

_the_inflator 4y ago

As the old saying goes: "We have a new framework that will make the existing ones obsolete." This makes n+1, not 1. An agency usually deals with different customers, different settings. What I achieved by migrating dozens of apps to a Angular only frontend, is a platform. Reusable components, devs that can easily switch projects. This is the one and only framework we use, monoculture. This is a beast, we could abstract away certain processes and developed a No Code Editor on top of the component platform. This Editor handles alone 100+ apps. No pain what so ever with migrating from Angular version to version. Best decision ever, so many benefits, even in abstract logical terms, for example, we could simply compile into any other framework by rebuilding some of the components in another framework. You won't get these benefits, if you fall for fad after fad. Monocultures help in certain settings.

tartoran 4y ago
I could see Angular working out great for certain type of projects and teams. I used it for one project for front end and didn’t dislike it at all. Unfortunately I see Angular relegated in favor of React mostly..
- pjmlp 4y ago
  Angular is still the go to framework in Java and .NET shops when a SPA is part of the project. It is kind of changing in Sitecore projects, because they have a collaboration deal with Vercel, and are pushing Next.JS/React as the main framework for headless CMS workloads.

papito 4y ago

Back in the day we had this mantra - "complexity kills". Boy, did it take us another decade to learn the same lesson - AGAIN.

shanebellone 4y ago

I agree with the dependency commentary. Tech should value supply chain. Development is slower but Power comes from ownership. I'm also anti-JavaScript, at least in abundance. I noticed this in gaming as well as software... engineers always build for the best hardware. Despite everyone knowing that extremes (in the wild) are a minority. I believe tech needs to focus on building better 4-cylinders rather than expanding cubic inches.

imbnwa 4y ago
Partly think that's why there was some dismay at Deno's decision to tunnel packages from NPM, a contingent of folk who wanted a reset on the JS ecosystem and (lack of?) culture