Front-end is harder than back-end | Hacker News Reader

Front-end is harder than back-end

45 pointserikvdven63 comments

Or convince me otherwise. I thought this would lead to an interesting discussion. I'm a back-end developer, currently constructing a front-end app in ReactJS. Ok, I must say I'm a newbie when it comes down to ReactJS. But as an example, it took me 20 minutes to realize that a table with 1000 elements, each having edit buttons, led to the slow response of displaying a modal. Now, I'm tasked with finding an effective solution to address this issue—whether it's through pagination, using react-window, or exploring other alternatives. And I haven't even found the cause whether it's the amount of event handlers, the size of the virtual DOM or something else. Back-end feels so much straightforward.

View on HN

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.

> 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.

I feel this is an obsolete view. React has been on top since what, 2017? It's extremely popular and there's nothing close to it. Now, data world... amount of new technologies there has way overtaken early 10s frontend.

> I feel this is an obsolete view. React has been on top since what, 2017?

React is obsolete. Cool kids are now using Svelte or Qwik.

Just to put things in perspective, here are last week’s NPM download numbers for those three frameworks[1]:

React: 21,879,845

Svelte: 722,312

Qwik: 11,702

[1] https://npmtrends.com/@builder.io/qwik-vs-react-vs-svelte

I think the hardest part for these new libraries is to build a solid ecosystem around them. React is the king for now and it will take many years to catch up.

What are some examples of fields in the theory of software engineering?

We have not reached the same level of usability as VB6, Delphi, and WinForms, where you can drag and drop buttons and textboxes onto a form, click to add some code behind them, and have stuff just happen.

Web front-end is horrific by comparison.

it seems appropriate to mention htmx ~ Essays: https://htmx.org/essays/

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 further away from the product you look, the less the company as a whole will manage to care.

but these things have a bad habit of forming loop-like structures, turning back in on themselves.

try being full stack. where you need to know both, albeit most full stack devs I know are really backend devs who know how to apply a UI to their backend in varying degrees of quality and complexity.

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.

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).

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.

Consider that those layers of abstraction exist for a reason? Let’s say you can’t see very well. This is what I hear when I enable VoiceOver on macOS and open Discord (either the web app or the desktop app):

1. “Discord, friends - Discord window, direct messages, selected cell”

2. “You are currently on a cell inside of a table. To navigate the cells within a table, press…”

3. (when navigating with the keyboard) “1 mention, $SERVER_NAME, cell” “$SERVER_NAME, cell” etc

And here’s when I do the same with a random Dear ImGui app I have installed:

1. “$APP_NAME, $APP_NAME window, $APP_NAME window”

2. “You are currently in a window”

3. (when navigating with the keyboard) [silence; no additional instructions]

So that Dear ImGui app is entirely unusable for anyone who needs a screen reader. This is something every React app — really every web app, period — gets basically for free.

And it’s not just screen readers, right? It’s different viewport sizes and alternate character sets and right-to-left text and user-defined fonts and searching through text on a page and the zillion-and-one other things that you either take for granted or don’t need at all but are crucial for millions of people.

Yes, if you could make a good UI by just filling a frame buffer with pixels, web browsers and React would all be hideously over-engineered. But we don’t live in that world.

This is a good criticism of ImGui, but feels like a false dichotomy. I don't think it's the many layers of DOMs and tree diffing that makes screen readers work well on browsers. Conversely, there's nothing about the ImGui abstraction that makes screen reader support impossible. ImGui already sees all of your text and buttons, so no reason why it couldn't send those to a screen reader as well as the screen.

All in all, I don't think "there is a reason things are the way they are" quite means "the way things are is actually the best they possibly could be".

Sure, I don’t disagree. Browsers and frameworks are extremely heavy. I do think there’s something to be said for having these affordances on by default. Screen reader support in Dear ImGui isn’t impossible, but that’s a super low bar that puts the onus on developers. Browsers do it out of the box! Our tools should lead us into the “pit of success”, where it’s easy to do the right thing and hard to do the wrong thing.

I don’t want to get too hung up on Dear ImGui. The official repo says that it’s meant as a developer tool rather than for building end-user UIs, so it’s not a fair comparison. My point is simply that all these things require layers of abstraction. Maybe the way things are isn’t the best way, but even the best-case scenario will be significantly more complex than what you described once you start adding in the things I mentioned.

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.

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.

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.

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

Oeh Delphi! That brings back some memories. But I hear what you're saying. I must say front-end has become more mature, but still, it can be quite frustrating so now and then.

More moving part is the right way to say it I guess. And perhaps: you have a user which interacts with it, so there is a lot to keep in mind regarding that as well: show loaders, what happens with y if they hit x and z, etc.

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.

Clients also have datastores, localstorage, sessions, cookies, indexdb, service workers, etc. Messing up a service worker is particularly annoying, but messing up storing an authtoken can also leave your users in a broken state.

On the backend you can (hopefully) revert from a backup, or conjure up a clever SQL query to patch things up. On the frontend however, well, you just have to wait for the user to call you to tell you it is broken, and then tell them—somehow—that they must delete the service worker.

Oh yeah, and you also have to deal with shipping a feature which brakes everything for users on 5 year old versions of Safari.

> If you mess up the backend (data corruption, data removal, data leaking, etc.) you are in hell.

True, but also tooling is better. I have seen a data corruption in a database only once in my life (at least in production). Finding some issue with ui is closer to norm then exception.

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/...

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.

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.

> It's like acting like building a house requires two jobs, "Inside Builder" and "Outside Builder".

Your anology is flawed. There are different tools and different skillsets involved. A more apt analogy is that building a house requires two jobs, a “carpenter” and a “cabinet maker”.

A back end developer need not concern them self with UX design, CSS animations, accessibility, browser compatibility, etc. and very seldomly with localization. These are all things a skilled web programmer will become an expert at if they are building websites served to tens of thousands of people.

Similarly a cabinet maker need not concern them selves with ventilation, load bearing walls, stud spacing, etc.

I...don't see how your analogy is any more or less flawed...but I also don't particularly want to debate about an analogy that aptly demonstrates a point: specializations exist.

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.

Both frontend and backend development come with their own challenges. However, I believe the industry has been grappling with unnecessary complexity for at least the past decade. Take React as an example: it's a library developed by Meta, which boasts a massive team of developers. But before tools like React, and even before Backbone, there wasn't a clear distinction between frontend and backend in web development.

This division is relatively new and, in many ways, has given rise to new challenges and job roles. Gone are the days when we were all considered full-stack developers, working seamlessly across layers of a web application. In reality, web development should be viewed holistically, even though there are multiple layers to it. The final product is singular and unified.

It's possible to simplify frontend development by selecting appropriate tools. For example, a combination of Rails with Hotwire and Stimulus, or similar setups in other frameworks, can make the process more straightforward.

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.

I think it may be that you are just not yet familiar with a few common front end idioms. I am sure most front end developers would be at least as out of their depth in the back end (spoken as a 30+ year front ender). Populating a display with a small initial data set either via pagination (good when the user needs to read or scan most of the rows e.g. a newsreader) or endless scrolling where scrolling down adds more rows, or just delayed population avoids a long initial response. Edit buttons for each row can probably wait until the user focuses on a row except for maybe a placeholder button facade. Large complicated data shouldn't be in a dialog.

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

If you'd like mediocre and/or simple enough software, sure!

You mean like HN? Afaik, HN doesn’t have separate people for the frontend and the backend. And yet HN is the best place for hackers.

HN is not a good user interface, it definitely shows that it is not being maintained by an expert in front end.

Tables for layout isn’t just an example of a dated web site, it is also an accessibility nightmare which no professional web developer would allow to leave their localhost.

HN has a great UI; not chasing fads and keeping things simple is a positive.

For fully able users with access to a screen and a mouse, perhaps so. However for users navigating with assistive technology things are not so simple. A UI is not only what you can see, it is also how different users on different devices interact with it. A front end developer know that and knows how to make a simple UI accessible to every user.

It's definitely ran by backend engineers judging by piss poor mobile experience (tiny buttons) and contrast ratios.

HN exists in spite of itself.

HN is absolutely "simple enough software"; that's one of its distinguishing features.

A substantial portion can handle both, but opt out of doing so due to the pay not matching up, instead getting less than those who specialize due to it mostly being a cost-cutting move from the employing company.

People underestimate either side. You can get very very deep in both of them, it's no longer just about putting HTML elements on the page, or sending back a response. They've both become oceans, from exploring 3D content to computing on the edge to an entire orchestration of tools to manage as little downtime as possible.

It feels like that's no longer possible. The gap is much wider than it was historically.

It is definitely possible, but it takes organizations that allows people to learn and practice both, and a developer culture that allows for developers to be multi-disciplinar.

So far what I've been seeing is whole teams that "don't believe in full-stack developers" so they box and typecast people who try to do both.

You gotta send the right message from the top to change this. I've had some FE developers that picked up BE and are doing great at it.

I guess I would respond to that by saying that both sides have moved. Really what was "back end" 10 or 15 years ago is closer to devops than what most would call backend.

Would you expect these new backend folks to be able to, take, say, a clean linux install and build a relatively full stack on top of that - Apache config, firewall, that sort of thing?

Yeah, that's definitely true. Today I see lots of backend devs who don't even know how to setup deployment in AWS using any of their services, let alone how to deploy to another cloud service or VPS/dedicated server.

I remember this changing around 2015 or so, when I started getting the first batch of devs that only knew how to deploy using the one single way they learned, and never updated that. I specifically remember one dev that was coding for 3, 4 years saying his dream was to make and deploy his own website. He never had a personal project.

Which is perfectly fine, don't get me wrong. The part I'm not a fan of is the culture against people who can do multiple things well. Which, funny enough, I am required to do in my job (I have to do most DevOps, plus mentor frontend and backend devs).

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.

Perhaps you’re a better BE developer.

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).

Putting aside opinion about FE vs BE difficulty - I had similar problem (but while working with Vue.js framework which is irrelevant anyway as you probably can use similar solution to any stack you need) and I've solved it via using something called DOM recycle, you can find an example here: https://github.com/topics/dom-recycle

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).

I can easily visualize a database with millions of records in an hour or so using a QTreeView, performance differences aren't even that big between C++ and Python. Then again, Qt has been around for almost 30 years to mature into what it is now. It seems to me that a lot of the GUI frameworks being used nowadays just didn't have the time to mature enough.

“OP uses a sledgehammer to build a bird house and complains it’s too difficult”

This is equivalent to using K8s to deploy a static site and complaining infra is the hardest of all. React isn’t the skeleton key for front end apps. Sometimes using simpler tools is the way to go and adding complexity when it becomes necessary

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.

> I'm a back-end developer

> Back-end feels so much straightforward.

Well duh! Practice and experience will do that.

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.

Try microservices

Either way, for everything the following is valid:

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

Tell HN:

Isn't this obvious?

Well, I've seen a lot of discussions which try to prove otherwise. But perhaps it also depends a bit on the level in Software Engineering? If you are new, it might be that back-end feels more complex.

But yeah, front-end even feels harder to debug at some points like the one I mentioned in the OP, at least for me. Not to mention the facts you keep overthinking what might be a good solution in terms of UX (in case that too many DOM elements is the issue of slow performance).

just gonna leave this here:

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

Reply on news.ycombinator.com