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
Top comments (31)
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?