10 ms·

Front-end is harder than back-end

45 points by erikvdven 3y ago

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.

goralph 3y ago
Perhaps you’re a better BE developer.
NicoJuicy 3y ago
Try microservices Either way, for everything the following is valid: "You're more comfortable with what you're used too" :)
muttantt 3y ago
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.
codingdave 3y ago
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.
bob1029 3y ago
What ever happened to developers who are capable of doing both concerns? Is this an unreasonable position to have now?
- alex_lav 3y ago
  If you'd like mediocre and/or simple enough software, sure!
  - tkiolp4 3y ago
    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.
    - runarberg 3y ago
      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.
      - yjftsjthsd-h 3y ago
        HN has a great UI; not chasing fads and keeping things simple is a positive.
        runarberg 3y ago
        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.
    - isbvhodnvemrwvn 3y ago
      It's definitely ran by backend engineers judging by piss poor mobile experience (tiny buttons) and contrast ratios.
    - alex_lav 3y ago
lmiller1990 3y ago
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/dom-size/ https://developer.chrome.com/en/docs/lighthouse/performance/...
devdude1337 3y ago
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
- erikvdven 3y ago
  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.
alex_lav 3y ago
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.
- runarberg 3y ago
  > 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.
  - alex_lav 3y ago
    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.
tkiolp4 3y ago
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.
- runarberg 3y ago
  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.
- fiedzia 3y ago
  > 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.
cell9840179419 3y ago
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.
logicalmonster 3y ago
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.
- catchnear4321 3y ago
  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.
- gremlinsinc 3y ago
  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.
fiedzia 3y ago
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).
scyzoryk_xyz 3y ago
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.
jdlyga 3y ago
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.
sdflhasjd 3y ago
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.
nathants 3y ago
just gonna leave this here: https://reagent-project.github.io/ https://reagent-project.github.io/
lylejantzi3rd 3y ago
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).
jwells89 3y ago
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.
genjii931 3y ago
Isn't this obvious?
- erikvdven 3y ago
  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).
feoren 3y ago
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.
- KptMarchewa 3y ago
  > 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.
  - fqwert 3y ago
    > 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.
flashgordon 3y ago
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).
gumballindie 3y ago
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.
baron816 3y ago
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.
hakunin 3y ago
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.
resonious 3y ago
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 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.
- jakelazaroff 3y ago
  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.
bmodone 3y ago
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.
ChrisArchitect 3y ago
Tell HN:
miguelmichelson 3y ago
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.
dave333 3y ago
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.
oops 3y ago
> I'm a back-end developer > Back-end feels so much straightforward. Well duh! Practice and experience will do that.
lukaszkups 3y ago
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 https://github.com/topics/dom-recycle
sunny--tech 3y ago
“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

45 points by erikvdven 3y ago

goralph 3y ago

Perhaps you’re a better BE developer.

NicoJuicy 3y ago

Try microservices Either way, for everything the following is valid: "You're more comfortable with what you're used too" :)

muttantt 3y ago

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.

codingdave 3y ago

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.

bob1029 3y ago

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

alex_lav 3y ago
If you'd like mediocre and/or simple enough software, sure!
- tkiolp4 3y ago
  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.
  - runarberg 3y ago
    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.
    - yjftsjthsd-h 3y ago
      HN has a great UI; not chasing fads and keeping things simple is a positive.
      - runarberg 3y ago
        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.
  - isbvhodnvemrwvn 3y ago
    It's definitely ran by backend engineers judging by piss poor mobile experience (tiny buttons) and contrast ratios.
  - alex_lav 3y ago

lmiller1990 3y ago

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/dom-size/ https://developer.chrome.com/en/docs/lighthouse/performance/...

devdude1337 3y ago

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

erikvdven 3y ago
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.

alex_lav 3y ago

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.

runarberg 3y ago
> 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.
- alex_lav 3y ago
  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.

tkiolp4 3y ago

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.

runarberg 3y ago
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.
fiedzia 3y ago
> 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.

cell9840179419 3y ago

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.

logicalmonster 3y ago

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.

catchnear4321 3y ago
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.
gremlinsinc 3y ago
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.

fiedzia 3y ago

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

scyzoryk_xyz 3y ago

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.

jdlyga 3y ago

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.

sdflhasjd 3y ago

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.

nathants 3y ago

just gonna leave this here: https://reagent-project.github.io/ https://reagent-project.github.io/

lylejantzi3rd 3y ago

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

jwells89 3y ago

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.

genjii931 3y ago

Isn't this obvious?

erikvdven 3y ago
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).

feoren 3y ago

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.

KptMarchewa 3y ago
> 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.
- fqwert 3y ago
  > 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.

flashgordon 3y ago

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

gumballindie 3y ago

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.

baron816 3y ago

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.

hakunin 3y ago

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.

resonious 3y ago

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

jakelazaroff 3y ago
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.

bmodone 3y ago

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.

ChrisArchitect 3y ago

Tell HN:

miguelmichelson 3y ago

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.

dave333 3y ago

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.

oops 3y ago

> I'm a back-end developer > Back-end feels so much straightforward. Well duh! Practice and experience will do that.

lukaszkups 3y ago

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 https://github.com/topics/dom-recycle

sunny--tech 3y ago

“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