Hi to all backend developers. As in the title, I would like to ask you what makes frontend so unpleasant to some backend developers? I will appreciate any honest answers no matter how harsh they are.
Hi to all backend developers. As in the title, I would like to ask you what makes frontend so unpleasant to some backend developers? I will appreciate any honest answers no matter how harsh they are.
For further actions, you may consider blocking this person and/or reporting abuse
I love frontend, I am not sure all the complexity born in the past few years has been really necessary for 99% of the websites but I also see counter trends (re-)emerging of people trying to escape it. This applies also to programming in general: most of the content we consume is geared towards building the next tech behemot but 99% of the web projects aren't like that in my opinion.
The positive aspect of the current trend is that there's never been in my memory such an active and massive frontend community and a lot of interesting things are happening :-)
I believe some of the frustration is that, design aside, frontend possibilities have exploded and it requires specialized expertise and domain knowledge, making it more difficult for a pure backend person to evaluate them. In the past you literally only had to worry about picking a library for JavaScript and most of the times it was jQuery. It's not like that anymore :D
"most of the content we consume is geared towards building the next tech behemot but 99% of the web projects aren't like that"
I completely agree, something like 80% of the web is still built on trusty ol' PHP!
Still dislike the language but it's kind of true. It works. It's ugly to me because I have different taste but can't say didn't use it quite a lot
I have worked on both ends and I'm more comfortable in backend. I will list them as below:
1) Asynchronous nature: Non-js backend devs think programs are sequential.
fetch(url) will directly return value. This is a myth which will make a lot of people skeptical.2) CSS: There are great resources which different parts of css. Ex:
learn everything about position in 5 minutes,Learn flexbox in 15 mins. But comprehensive learning of CSS AND/OR styling is very hard and needs people to invest lot of time.These two combined can make a great impact on backend devs learning frontend.
Did you say that non-js backend dev don't understand async or that it's a myth people belive? I'm mean first case is offff so much I can't see it. Asyc has been on back long before js existed. It just wasn't considered as useful as today. Hint Erlang and check it's year of development
I meant to say that people who are used to traditional backend programming languages like java where the frameworks like spring abstract away the parts which make a server take multiple requests, scale etc. So the code almost executes sequentially in a single path/request. When it comes to frontend, there's a promise.then which we need to call to make it sequential.
I do understand that java had these things known as
Futuresall the way, but no. of people who use it might not be that big, at least as per my knowledge. So, for me coming from java background initial parts of my career, that was a major place for confusion. That too when there were so many ways to make an api call like xhr, fetch, axios and es6 was kind of new & the confusion between callbacks and promises made me frontend quite hard to master.Java did lag a bit for async adopting as a language. That's a fair point. However start of Java implemented "Green threads" so read about that one if you already didn't.
However developer lacking the desire to use it is not. RxJava and project Reactor were quite there. Aside from Java which WAS always slow in adopting something (now it's a bit faster but maybe slower to implement), you did have numerous things starting from C# who first implemented async/await keywords (not the idea), as best to my knowelege 2012 official release with 5.0. That's just keyword talk. Scala did a lot also.
So before JavaScript jumped the hype many languages had in fact a whole community asking for async behaviour as pretty as async/await keywords in C# or they started propagating new programming religion about functional and Erlan or it's ruby-ish syntax Elixir and told people OO is bad and horrible and such such. It really depends where you work what kind of image you'll get for this. If you worked with telecoms in Java you would think devs always wanted it. I worked mostly with Java and it's still getting a slow phase there but not because of dev, rather old non easy up-gradable projects. It's not just writting couple of lines it's refactoring the way your libs for connections work and all the things management doesn't like to pay for. It's a bit misleading to think JS had any major impact on adopting it.
Before web there was a lot of UI and... well threads. So idea was there. They knew about async stuff. Just picked wrong tools for certain jobs. Or tools were too much lagging in releasing promised.
Now to push back to topic UI was one of the most influential things to push "async" requirements it just didn't start with the web nor JS. It was poorly implemented but hey we're talking about timeline.
Yeah I do agree. when I started maybe 6 years back or so java was where I started with minimal knowledge of async. Maybe that's the reason I found it hard to start. Thanks for the great info.
Cheers
I think it's mostly the platforms.
Backend work is mostly free for all.
Do you want to use .net? Go for it!
Do you want to use Java? Be my guest!
Frontend and mobile are mostly about "what does your user have?" Which is usually Web, Android, and iOS.
Especially the app stores are pretty ugly to work with.
I am a Full Stack Developer. I think it is most likely CSS and all of its quirks getting pages to work in different web browsers. And trying to figure out why something is broken. These are the type of problems that you do not need to worry about when you are solely working on the backend.
Agreed
I've been working backend and frontend for about 7 years and this is my take.
Put plainly, backend is simpler.
That's not to say backend development is easier, but it's simpler. There's usually just one target platform for any server you'd write, whereas a frontend targets multiple devices, browsers, screen sizes, locales, time zones, etc.
That one target could be a single digital ocean droplet, or aws ec2 instance, or any other number of backend infrastructure setups, but it's still just a single, consistent, runtime for your server.
A lot of the complexity in frontend land is due to the multiple runtime targets. For instance Babel only exists because not all browsers support necessary javascript features for modern development.
I have been a back-end Java dev all my life and have been occasionally been thrown into the front-end side during a release or when "Huston, we have a problem" situation and I end up being a full stack dev for that project unofficially. Here are my 2 cents...
1) It takes me quite some time to understand the project structure depending on the front-end tech stack being used. 95% of the time, I end up questioning why is the structure different from the previous project.
2) Does not matter if you are a front-end dev. Big O matters. I have a hard time turning a blind eye to the monstrous O(n2) functions written when it can be done in O(n log n) or maybe even linearly. I finally end up spending late nights in the office optimizing the code. (This does not mean all front-end devs are like this... just my experience)
3) Every front-end team has their own code styling/formatting techniques. Call me a sucker on this, but I have been using Google Code style and their naming conventions for a long time. It freaks me the f*&k out when I see a variable being declared differently in different projects. I have seen user_name, userName, username and UserName being used. Pick one folks.
4) This is again got to do with me; when trying to help out in the "Houston, we have a problem situation" I have been told I need to be creative and productive at the same time. Excuse me, but last time I checked, you needed help. I may not have the best UI/UX sensibility as the front-end devs, but I am doing the best I can to help you out. A bit of "do it like this" would be more helpful , rather than "you should be more creative and productive".
As a young backend developer i think is difficulty to think what is the best form to show/let user interact with the data(this is my difficulty), but i like and work with the both, backend and frontend.
In backend we know what user want's to see and what he need's to be able see (like permissions, the rules of the server) , in frontend we need to think how the user will see/interact with the data, the pages, the orderof the content, it's a mix and u can't only think in the data itself.
I will come back to see another opinions.
I am currently working with front-end again after some years of working in back-end mostly.
My problem is definitively CSS and how you have a lot of different properties that sound like they should solve the problem but behave in a non-intuitive way.
in the back-end, most things have a very predictable outcome and well-documented ways to solve most problems that emerge.
To me front-end just does not feel like has the same predictability, and it annoys me a lot.
I dislike the stacks. Creating an oversized stack of tech and justify that is needed or it is better. In most cases, it is not. Sometimes, modern js stacks look like they are trying to make js work, just feels forced.
I am not saying that it's always this case or that backend is not affected. I just find it difficult to jump into a file that has 3 levels of tech to render a page, which makes the documentation for each of the levels more difficult to navigate.
Also, the pure frontend dev that knows only how to do things their way. Please, study and learn, and if you don't want to get better, just say it at the start. I am writing the queries for my colleague because he only knows basic typeorm.
I'm a full-stack developer, but three years ago I joined a company that was in sore need of front-end efforts, so I said that I wouldn't mind being responsible for that, too. (The developers were mainly computer scientists who also did not like front-end work.)
Front-end used to get a bad rep for being chaotic, unpredictable and without methodic rigour. Today you can transpile any language you like so that it executes in the browser, or pick from a large number of front-end-native languages, including strongly typed functional ones. The front-end is testable, frameworkey and event-driven. Both Elm and Vue (just to name the ones I've tried) have interactive debuggers built into the browser that let you isolate the app's state space!
So TODAY, what makes front-end unpleasant for me?
The fact that front-end web development has all the conveniences of modern-day software development has the unpleasant effect that I have to actually sit down and learn how to apply those to make the experience pleasant. I don't count that as a drawback because the alternative is worse.
The real drag with modern-day web development is that the web's persistency is not respected. With static HTML pages hosted on university servers in the early days, there was a sense of persistency since it actually required more effort to change things up than to simply append to what you had. How do you hyperlink an infiniscroll?
For me, it's because I suck at it. Might be lack of imagination and creativity but I have less issues with Angular than CSS. However I do prefer non dynamic languages than JS or Python. So TypeScript helped a bit but I still dislike witting useful nice looking UI. So it's more responsivnes and design than "frontend" in my case.
Lots of fingers pointing at CSS, but I don't think that's really the culprit. There are minor difficulties inherent to using CSS infrequently: it's easy to forget the long keywords, which order you go in defining margins or borders (and with two or four elements?), or which flex attributes do what again. But structurally, CSS is all about sets of elements and sets of classes, and principles you pick up working with datasets apply just the same until you get to the really fiddly details, which again are the sorts of things that take regular use to master.
What the frontend does dramatically differently is state. For ~twenty years now, services and APIs have evolved toward the relational database principles of atomicity and isolation. Backend developers live by the rule that the proper place for state across requests is the database; stateful APIs are an absolute nightmare to maintain.
Meanwhile, the frontend is all state all the time. Contemporaneously with the movement toward stateless backends, web frontends started becoming stateful with XMLHttpRequest, and the web's availability and comparative universality helped it overtake the desktop as the target environment of choice. State management on the frontend has only gotten more and more complicated with time and single-page apps. There are dozens of flavors of state management, even more toolchains, transpiling, polyfilling, and finally Electron bringing all that fun full circle to the desktop. It's unfamiliar territory for people who focus most of their attention on the backend, and there's so much of it it's next to impossible to stay current.
This is soooo true. Almost all of the frontend problems I run into are state management. Like "Do I have this data yet? If I don't have the data yet, what should the UI do? When I get the data, what needs to change? What happens if a user types in this field or clicks this button? What changes do I need to make to get the data in the right shape to work with these two different places."
The days of static websites are long gone, which is why people complain about the complexity of JS tooling. Most of that tooling is there to help with asynchronous state management (which is a "hard" problem). I think it's natural that as people expect more interactive websites we'd end up with more state management as a consequence.
Separating in an efficient and clean manner UI Logic from Business Logic.
I'm a quite new dev and the only dev on my team, maybe this isn'ta problem for more senior devs. Anyway, reading has helped, there's a lot of people writting about best practices, I've just scratched the surface yet :D
The question could go both ways, as I've seen front-end devs staying away from backed as well as vice-versa.
For the record, I do front-end as well as in many ways I like it, but it took the last couple of years and some stack shifts to see some ugliness in the front-end.
It all boils down to javascript. Basically, JS (as the language and platform) is bad. It's a damn awful platform.
When a language fails to enable developers to develop safely and provide the moving parts to achieve its goal, it raises alarms. There's a whole world of tooling to make up for what JS lacks. Typescript, wrbpack, gulp, linters, static analyzers for a variety of goals and so on. All fail in some regard, which makes it necessary to go back and create a new one. Starting up a proiect begins with debate on choosing and setting up all the stuff.creating a rest app is cumbersome enough to create an official script for it.... and then still remove unused parts.
Typescript fails at its job and even makes some idiosyncrasies worse. In many respects I find Reason an infinitely better developer experience.
So much cognitive load with the huge amount of idiosyncrasies and gotchas (at least it feeds an ecosystem of JS blogging just to remind people that "this" depends on context, scope changes, automatic type casting and so on).
I do feel that Reason solves most issues and brings some consistency and that's what I use nowadays for front-end but it's still a farcry from using Go or Rust in the backend.
Thank you to everyone that helped me to find the right answer to my question. I wanted to make sure that everything I thought about developing the frontend is right. The whole last year I spent on creating my own project that at first I thought it is dedicated to frontend developers. But it looks like the real users are people who don't enjoy or don't have time for creating front of the apps. So I'm quite happy to show you what I have been working on especially that it looks like I manage to solve all of the common issues with developing frontend.
You can read more here:
dev.to/przemek/backend-developers-...
As a full stack developer, the patience to finish a screen on the frontend is the toughest part in my opinion. Finishing implementing a design can be tedious and require detailed thinking / patience. Whereas on the backend, it's much easier to get things done and move onto the next objective. It's also less subjective, frontend is subject to more opinions on design. While there can be architecture debates on the backend, frontend design can be more of a slough. The payoff to nail a workflow or have a user go through a delightful interface that solves their problems is worth it though.
Backend programmers are paid to provide function. When doing frontend development, you spend most of your time styling components, fixing layout, testing layout, not function, across different browsers/target platforms - manually. That's not programming. If a backend programmer wanted to spend his time dealing with form over function, he'd picked up interior design instead of programming.
Many, if not all, frontend programmers are almost exclusively about form. Take away their CSS and HTML, and give them a powerful abstraction on top of those low level tools, and they'll fall into depression - it's not that they couldn't use it, it's that they panic if there's no possibility to control every last pixel manually. The downside is that most frontend programmers have no clue about ideas such as separation of concerns or testability. Writing reusable, flexible and extensible UI components is a complex and difficult undertaking, requiring a thorough understanding of notions such as MVP, MVVM or MVC, and some extensive knowledge of what was done in the field already - something most web frameworks prove their developers don't have, and which usually makes frontend changes costly, compared to backend changes. This is why frontend code feels dirty, inefficient and wrong for backend developers - they get to spend a lot of time on things they don't feel like it provides much value, and the result doesn't give them any satisfaction.
To give you an example, most web frameworks make it nearly impossible to run unit tests outside a browser (a headless browser still counts as a browser). You effectively need to fire up a HTML + CSS engine, along the JavaScript interpreter, to run tests against code written on top of any web framework. This means frontend tests run thousands of times slower than backend tests. This in itself makes the TDD approach used by many backend programmers impossible in the frontend, with heavy implications on the cost of quality for frontend code. This is something most frontend devs don't even think about. Another example is algorithm complexity analysis. With fast modern machines and devices and extremely optimized frontend engines (for both markup and layout and JavaScript), frontend devs get away rther easily with shitty implementations. Despite the monstrous speed of backend machines, when you need to run thousands of complex computations in parallel, that's not something you can not care about in the backend.
I believe frontend is way less miserable than backend, and I do backend.
centering the divs, when SO is down 😉
css, and html tags, both make no sense.
I don't have common sense when it comes to design, ui, ux, and frontend.
Aligning objects on the screen :|
Lack of communication.