If you are a freelancer or working on a small team without backend developer, how do you handle those requests ? Do you give it a try or refuse or recommend someone else ?
Thus you eventually take a step into the back-end. I found it's not so bad. Actually, I discovered to like the back-end more. CSS is pain. Design is a pain. Although it can be fun sometimes as a form of artistic creativity.
> how do you handle those requests
>Do you give it a try or refuse or recommend someone else
Honestly, I'd be surprised if someone in the current year is strictly a front-end developer. Do they still exist? I'd consider getting someone on your team that is familiar with the entire tech stack.
Everyone here prefers to work on the backend tasks...
If you can program, are comfortable with data structures, and gain familiarity with Nodes APIs, and finally can set up a database the only real distinction then becomes programming and data. But let’s examine why people fail at this so very badly.
First, the compile target of the browser is the DOM. It’s an in-memory data structure. When you accept that reality and can actually write original code you no longer need large frameworks or vanity nonsense like jQuery. It’s just programming plus a standard data structure with a given API. If you cannot reach this pinnacle of clarity everything remains challenging and you will need other software to do it for you.
Second, you need to understand transmission to talk outside the browser even on localhost. There are several options available. HTTP 1.1 remains the primary standard and WebSockets remain the only full duplex option, but WebSockets are inherently session oriented while HTTP remains session less. If this is not your language you are not ready to write any kind of backend for any web app in any language.
That’s all there is to it, assuming you can program. I was writing JavaScript full time for 15 and almost never found developers who could do these things. It’s not challenging if you accept some minor level of self sufficiency.
It isn't fear. It is discomfort. It isn't specific to front-end developers, it is just part of being human. If you feel hesitant, ask someone to help you out to get rolling. If someone on your team feels hesitant to jump into your area, offer help to get them rolling.
While I’m not a back-end engineer per se, I do believe that AI makes the line between front and back blur in fun and interesting ways. Front-end can always rely on their favorite engineer from the other department to finish the job :)
J
Node is actually pretty easy. Framework 7 took me a few days. React takes a while. It's just this feeling of getting lost.
I bet both FE and BE web developers would fear a different thing, like game dev. Can you pick up an open source Ludum Dare game and hack something into that?
Because of state growing exponentially with number of ui elements and features.
This is why, for example, many beginners intuitively prefer focusing on backend.
So to your question - only really bad frontend developers have any real reasons to be intimidated by creating some crud api.
But the complexity of UI is not a matter of opinion or approach - it is a simple fact of having a far more complex state machine in simplest desktop app than in half of hi loaded services in the world (which are stateless, i.e. not having a state at all).
Frameworks and libraries help alleviate the pain and take care of low level dirty work, but they can’t remove the fundamental source of complexity.
The frontend of a high traffic web application will perform the exact same as if that frontend only had 1 user or 5000 at the same time. Any performance problems in front-end are self-inflicted, likely from over-complicated, bloated frameworks and a lot of resume driven development - it can happen in backend too but count the number of frameworks for JS vs Ruby or Python.
Now in my mind, I don't include UX design as part of a frontend developer role and really that has no bearing on actual code, its more about human computer interaction and psychology than what software is pumping out HTML and CSS.
i've worked on services with 1-2M requests per minute - most of them were stateless, and usually are (in a "typical" web company like big e-commerce apps, twitter, etc.)
This doesn't mean they are easy to implement and operate, but they lack one huge source of complexity (in a mathematical sense, i. e. entropy) - the state.
This piece is usually delegated to a database/middleware level and is spread over multiple more or less independent services dealing each with its own tiny slice of state.
On UI (i.e. app with few screens, buttons and meaningful interactions between them - not a dumb statically generated blog) the complexity of state grows rapidly and there is no magic DB to shove it into.
Because the state machine is the core of the app work - user interaction is literally a walking through transitions of state machine.
IMO if you are working on a standard business CRUD app, frontend is the more difficult and dirty work.
I don't see an issue admitting if something is not within my expertise.
In general I recommend someone more suitable if it's not within my expertise. It helps to build trust and the client will get be better off.
I'm exclusively a frontend developer now, and I LOVE it. But it wasn't always that way.
Back in the 90s, I started as just a "programmer"/"web designer" (there wasn't a clear difference back then), chasing volunteer gigs on Craigslist as a teenager, which turned into unpaid internships and then one-off paid gigs for small businesses. That was back in the days of Perl/cgi-bin and eventually PHP, etc. Through the years, I learned a lot of typical backend stuff (databases, Bash, protocols, APIs, HTTPS, caches, DNS, virtualization, etc.), but also learned HTML/CSS/JS as they were invented and improved. I pretty much self-taught most of it, which was a lot easier to do then because things didn't move as fast, my younger mind was more plastic, and -- importantly -- people were willing to give juniors a chance.
For most of that time we didn't really have the option of specializing, and my first full-time web dev job (around 2013) had only 2 programmers for the entire small ecommerce company. The two of us were responsible for everything from the frontends (in AngularJS 1.0 and PHP/Laravel + jQuery + Bootstrap at the time) to the backend (Redis + Varnish + PHP Postgres + glue code + a homebrewed CMS we wrote in AppleScript and Filemaker because that's what the boss was used to, sigh) to random IT things like managing our email server (until we insisted on a migration to GMail), SPF rules, firewall, fail2ban, DNS, etc., macOS backups, etc.
We had various monitors (Monit, etc.) set up to detect whenever a particular daemon crashed (and they crashed a lot, because we were noobs), but we'd auto-restart it or failover to the other VM on the other coast, running off a slaved DB, rsync on a timer, and a synced Redis cluster. I think we somehow achieved something like less than 2 hours of downtime a year, which was pretty good for two junior self-taught devs with no formal training, and a web services budget of about $300/mo all-in. We just Googled a LOT and learned many best (and many not-so-good) practices on our own.
I was paid $15-$25/hr at that job, and I was very happy. Before that, I was logging burned trees and building hiking trails, surrounded by mosquitos, rain, and smoke for $6/hr.
Fast forward a few years, and eventually I discovered Next.js while trying to find a better replacement for Drupal (which I will NEVER use again). I taught myself modern Javascript (ES6+) and React and absolutely fell in love with Next, despite (or maybe because of) having grown up with decades of handling state and transactions on the backend. I was 10x more productive in that stack than I had ever been, and Vercel turned what used to take weeks/months of config and debugging into 2-3 clicks and $20/mo. I decided that my next job would be frontend only.
Eventually I got a six-figure job doing only frontend work at a mid-sized corporation, and it was glorious for a while. In contrast to many developers, I LOVED the UI/UX part of the job and would work alongside UX to tweak every modal, color, font, etc. CSS by this point was second nature (but flexbox still is and probably will forever be difficult). It was a blast not having to touch the backend anymore (I never really enjoyed it, it was just the boring shit I had to get running so I can focus on playing with the UI). That job paid a lot more than my first one, but ironically I had way less responsibility. Eventually, though, management changed and added a ton of Agile bullshit and useless bureaucracy and meetings and I quit.
These days, if I needed a light backend, I'd just write it as a route handler in Next.js (https://nextjs.org/docs/app/building-your-application/routin...), a serverless function (on Vercel of Cloudflare), or use some SaaS API/managed DB. At small biz scale, IMO there's no reason to go down to the metal anymore, or really even down to the level of AWS (as opposed to higher-level abstractions over bare clouds). Even for the client, it's much cheaper to pay for those vendor-supported services than extra hours of dev time. For heavier backends, I'd team up with a backend person (like the other person of that 2-person team I started in, who did the opposite and became a backend AWS architect instead, never touching UI) or just not take those jobs.
I don't hate the backend, I just love the frontend, and I'm old & experienced enough now where I get to be somewhat selective (though not in this economy, of course, lol).
-------------
Having done a bit of both sides, I don't think either side is necessarily more or less technically demanding (at least not when you're just building a generic website or dashboard). There's just different skills and challenges, and I don't necessarily mean just "code vs design", but even just code things like scaling + memory safety on the backend, or JS datetime and time zones on the frontend, or making SVG and Canvas work well together over JS/HTML/CSS.
I just love the visual & creative side of things, and don't really care about things like data structures or algorithms (beyond what I need to make sure the code is reasonably performant and readable). I didn't learn how to use binary trees until 20 years into my career, but at the same time, I'm way more fluent in Figma, Photoshop, Illustrator, and GIS (maps) than most devs.
I've also met many other developers, including others who started in the backend and moved to the front, or who started in the front and then decided they love the back instead. It's as much personality as it is skillset, in my experience.
I'm really glad the field was able to diversify & specialize into backend and frontend so that people like me can focus on the pretty shiny parts and leave the hardcore coding to someone else. But of course, as soon as that happened, AI took over everything and now there's no frontend or backend, just AI and breadlines, lol. Alas.