[HN Gopher] Front-end is harder than Back-end
___________________________________________________________________
Front-end is harder than Back-end
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.
Author : erikvdven
Score : 11 points
Date : 2023-08-28 21:24 UTC (1 hours ago)
| bob1029 wrote:
| What ever happened to developers who are capable of doing both
| concerns? Is this an unreasonable position to have now?
| gochi wrote:
| 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.
| alex_lav wrote:
| If you'd like mediocre and/or simple enough software, sure!
| tkiolp4 wrote:
| 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 wrote:
| 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.
| isbvhodnvemrwvn wrote:
| It's definitely ran by backend engineers judging by piss
| poor mobile experience (tiny buttons) and contrast ratios.
| lmiller1990 wrote:
| 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/...
| tkiolp4 wrote:
| 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.
| fiedzia wrote:
| > 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.
| runarberg wrote:
| 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.
| cell9840179419 wrote:
| 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.
| fiedzia wrote:
| 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).
| devdude1337 wrote:
| 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
| goralph wrote:
| Perhaps you're a better BE developer.
| muttantt wrote:
| 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.
| NicoJuicy wrote:
| Try microservices
|
| Either way, for everything the following is valid:
|
| "You're more comfortable with what you're used too" :)
| alex_lav wrote:
| 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 wrote:
| > 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.
| scyzoryk_xyz wrote:
| 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.
| codingdave wrote:
| 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.
| logicalmonster wrote:
| 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 wrote:
| 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.
___________________________________________________________________
(page generated 2023-08-28 23:01 UTC)