Front-end is harder than back-end

Perhaps you’re a better BE developer.

We've resisted many trends and sticking with AngularJS 1.8 in our 8 figure ARR SaaS. Customers have no clue we are running AngularJS and even if they did, our SPA is as snappy today as it was in 2017 when we launched v1 of our SaaS so why would anyone care?

Backend is a python Falcon REST API and there too we resisted internally calls for moving to newer async frameworks, port some parts to Go, etc.

Try microservices

Either way, for everything the following is valid:

"You're more comfortable with what you're used too" :)

It is just a question of what you are used to and where your experience lies. Things you have not done before are harder than things you have.

What ever happened to developers who are capable of doing both concerns? Is this an unreasonable position to have now?

How many total elements on the page? 1000 shouldn't be too bad. These guidelines recommend <1400 [0], although less is definitely better.

React in general is a bit of a pain, you may need to use `useMemo` etc. You probably want to find out what the bottleneck is, first. Computations? DOM elements? Re-rendering excessively?

It's certainly no harder than BE - it's likely just a lack of familiarity.

[0] https://developer.chrome.com/en/docs/lighthouse/performance/...

It’s not harder, it’s more tedious. We’re currently developing a somewhat sophisticated AI/Image Analysis system with OpenCV. While the backend is pretty straightforward it’s still not easy - reading papers about different AI models and implementing them is hard, but the path is clear to see so to say. The client app is using React and already has 3 times the lines of code compared to the backend (which is C++). Frontend has more moving parts that need to be integrated properly. We evaluated other tech for the client, like Qt or even ImGui on OpenGL, but the effort for the client would still be much higher than for the AI services. The only time I experienced a nice, less funky workflow doing frontend, was Delphi 6 and VCL

For you. Because you're new at it.

Also "Front End" and "Back End" are about as terrible of terms as one could come up with to describe the areas of work. It's like acting like building a house requires two jobs, "Inside Builder" and "Outside Builder". Both areas are actually many specific areas of expertise. For non-clientside-development I think the industry has just gotten more specific in job titles, ie now there are SREs, "Platform Engineers", "Microservices Developers", "Cloud Devs" etc. Some places have gotten into having more specific clientside titles, but IME mostly it's still pretty vague.

Also, meaning no disrespect to Javascript people, I think lots of trendy "modern" "frontend" tools make things harder. React flipflopping on styles + devs wanting to stay up with the trends + SPAs in general being somewhat of a bastardization of the technology, I think are decent examples to suggest that living in the JS realm is, in part, accepting that things are going to be hard sometimes for the sake of it.

You can still build featureful rails/jquery/htmx applications and, IME, outpace FE specific technologies in terms of feature output.

Backend is riskier. If you mess up the frontend, revert and redeploy. Easy. If you mess up the backend (data corruption, data removal, data leaking, etc.) you are in hell.

Ideally you should have no more than a dozen state driven components in a page. 1000 is a very large number for any state driven system such as React. Here are a few things. 1) use a custom spreadsheet component which manages its own state and you manage only one state 2) if not, use key to make sure you do not have a high component turnover on every event 3) provide file upload where they can create content elsewhere and upload to you

You are right. BE is declarative hence solid (pun) once put in place. FE is design, aesthetics, ease of use, beauty, culture, above all functional. Hence tougher.

I think being a great frontend developer is the hardest thing on the web.

You're dealing with crazy environments, far faster changing best practices, libraries, frameworks, and tooling, increasingly demanding audiences, and any imperfections on whatever you deliver are extremely noticeable.

If a backend developer does a database query that's a little inefficient, odds are nobody is going to even notice that.

If a frontend developer does some animation that's a little choppy and with bad timing, they might have the entire company management crawling up their ass the next day.

The issue is simple to resolve - most ui frameworks will have some sort of virtual table that only display and manage elements user will see, so just use that (react window does that, but there are table variants that are doing all the work as well). This is a limitation of a browser/UI/OS more then react, as any ui element comes with a cost, though you'd need to know someone who knows about browsers, ui libraries and operating systems to explain where the cost comes from exactly, and you won't be able to do anything about it anyway (that's the problem with the frontend).

The example has sort of derailed the conversation with many commenters here jumping to advise on how to solve your specific problem.

Speaking to the actual question - my own observation is that the “hardness” of something is entirely subjective. We have a physics math phd in my company who sees 3D modeling as hard because it is so tedious and dependent on clicking around UI’s. Under the same roof we have a couple of 3D modellers who spend all their time clicking away and they see all the complex math and physics simulation and it’s all tedious gibberish to them. One can’t imagine doing the other job.

Many people find the thing they do sort of easy. Many people make judgements about adjacent disciplines and think “I could do that”.

But generally yeah - I would agree that FED is hard and in many ways comprised of layers standards and strange caveats. But they do say that’s the case for any expertise-driven domain.

The categorization of developers into just 'front-end' and 'back-end' is an oversimplification that doesn't capture the full spectrum of roles in software development. There are many other specializations such as full-stack developers, who touch several different layers including the UI, as well as DevOps engineers, who focus on the deployment, monitoring, and maintenance of applications. Moreover, a large percentage of roles are more specialized like data engineers, security engineers, mobile app developers, and more.

One I remember is something a project manager once said...

I was working for an agency doing mostly apps and websites, one of our customers had a couple of projects running in parallel. One was sorting out an app that their own developers had made a pigs-ear of, and another - larger - project on new ground.

The customer's project manager called us up asking for some more resource for the larger project to keep to deadlines, it got to the point of trying to micromanage the other app project that wasn't theirs, and they blurted out:

"${app} doesn't even need a senior developer, it's just front-end!"

It wasn't eye-opening, we could already see what a state their other "front-end" projects were in, but hearing it from the horse's mouth was a little amusing.

just gonna leave this here:

https://reagent-project.github.io/

You're taking a specific example using React and generalizing it to the entirety of FE development. React works in such a way that it's easy to optimize individual components, but extremely difficult to optimize the entire system. Most FE frameworks, libraries, languages, and environments don't work that way.

I will grant you one thing: on the backend, you can use whatever languages and operating systems you want. On the frontend, you're pretty much stuck with javascript and the browser (css, DOM, event handlers, etc).

The thing about front end web specifically is that by default, devs aren’t equipped with tools that will guide them down “happy paths” for most things. The effects of this aren’t too visible for small projects and even large projects early on, but as in your example with table rows, that will change as soon as these projects meet even slightly demanding real world usage.

To be good at front end web, one needs to care deeply and sink a ton of time and energy into framework and component choice and understanding what’s going on under the hood. Gluing together whatever is shiny or trendy at the moment without deeper consideration is a surefire way to end up with something that technically works but is thoroughly mediocre.

Of course deeper understanding of the technologies being used is helpful in other types of front end as well, but it’s not quite as important there because they have well established conventions and best practices that cut past trouble of this sort. Point in case, in an iOS or Android app, the system stock table views with many rows won’t perform badly because as long as you’re using the APIs as designed, they recycle their cells right out of the box — no need to hunt down a special package or anything.

Isn't this obvious?

Hot take: the industry as a whole is very bad at both front-end and back-end. They both have their intrinsic challenges, but the discipline of software engineering is so immature that the self-imposed / accidental complexity dwarfs the essential complexity. We could all be doing much, much better at both.

Front-end technologies are not "progressing rapidly", they are thrashing. People are (rightfully) extremely frustrated with the limitations of the tools they have, so they (wrongfully) go off and invent new tools that get around those limitations, while inevitably re-introducing tons of difficulty in whatever the tools they're replacing were developed to avoid. It's just around and around. Developers aren't falling behind, they're simply getting dizzy. What they should be doing, instead of throwing out all the babies with all the bathwater and going and inventing their own giant frameworks with Blackjack and Hookers, is working on the theory of software engineering.

Our theories of software engineering are terrible, and I very rarely see discussions where I see actual theory-building. There are a lot of religious discussions, and a lot of slick new tools that let newbies make cool things quickly but always make complicated things harder. We need better theories of software engineering, not more new JavaScript frameworks and NoSQL database engines.

So don't worry about which one is harder than the other. It's an arbitrary line anyway, and it depends way too heavily on the specifics of the project. Realize that by and large, almost everyone is still shit at the entire stack.

For me as a backend eng the hardest part in fe (for me) is css! Back when I dabbled in iOS I found UI to be very easy (the layout part not the sexy looking part). On web I get very tempted with having to make something look like a modern app when a plain looking button would do and down i go into the rabbit hole of material UI and css and dependency management and versioning etc. Things like pagination etc I think are just standard problem solving abilities (for me).

Of course it is. Because front end libs are made by people that sometimes lack an in depth understanding of architecture and good design. It’s a self inflicted wound.

This is kind of like saying “physics is harder than math”. Well, there’s some parts of physics that are substantially harder than basic math, and vice versa. Frontend development, backend development, physics, and math are all very broad fields with wide ranges of associated challenges.

The difficulty is different. Front-end is very capricious, idiosyncratic, inconsistent. You have to deal with lots of annoyances, puzzles. You still might have some connectivity responsibilities, like restoring a web socket connection, managing local storage, integrating 3rd party SDKs.

But frontend doesn't need to deal with as many categories of failure modes as backend (imagine running out of file handles in *nix OS, or dealing with a deteriorating hard drive), doesn't need to worry about security to the same extent, and doesn't need to scale to many users. You know that you're running on a single machine, in (usually) a single thread. If you got it to work in all target devices, and handled low connectivity conditions, you're probably good.

On the backend, you might get it to work, but that's just step one. Now you have to make sure it's secure, make sure you handle all weird thread safety edge cases, db deadlocks from connection limits, and make it scale, which can take you very far from what you had when you just made it work. Running a feature at scale is an entirely different beast than making a feature work. Every backend function can turn into an iceberg of code, databases, queues, and other infrastructure to facilitate that feature.

React is crazy high in abstraction from what's actually happening. Your data goes through many "translation" steps before actually being rendered to the screen.

1. You have your signals and stuff - the actual data you want rendered.

2. React creates a virtual DOM tree thing out of your markup.

3. That virtual DOM gets turned into real DOM.

4. React gives the real DOM to the browser, who probably has to shift a lot of internal data around to accommodate changes.

5. The browser loops through its DOM and draws it on the screen (somehow - another black box).

This is a crazy amount of internal bookkeeping. Compare this with something like Dear ImGui (https://github.com/ocornut/imgui) where it's more like:

1. You have raw data in memory (just ints and char arrays).

2. You loop over your data, generating vertices for the GPU.

3. You give those vertices to the GPU to render a frame.

IMO this is way easier to reason about. It may seem "inefficient" as you're building up the entire screen from scratch for each frame. But if your content is static, who cares? You can draw one frame and leave it there for as long as you need. If your content is animated, you're probably already redrawing each frame from scratch anyway. At least you know that it's happening now that you've removed the endless layers of black box tree structures.