Ask HN: Which is harder Front end or Back end? | Hacker News Reader

Ask HN: Which is harder Front end or Back end?

13 pointsshire49 comments

This is a two part question, I want to get a friend into Web development should I start him off with the Frontend side(HTML, CSS Javascript) or Backend side(PHP, JAVA, PYTHON) of things?

Which is harder and why? is Web development hard in general?

And which is more fun and joy to work on? if you had to pick one particular side to start off in and build a career out of because is fun which side would you favor?

View on HN

Asking the first question is as silly as asking whether physics or chemistry is harder. It's a vague and loaded question that will be answered through a foggy personal lens of experience.

And asking which is more "fun and joy" is as silly as expecting an insightful answer as to whether football or soccer is more awesome.

My one piece of practical advice: learn JavaScript. With its massively growing presence on the backend, it's on of the few cross-cutting skills you can have in web dev.

Yeah but the more advanced fields of physics like quantum mechanics are way harder than anything in chemistry. It's actually a good analogy though, they are pretty similar in difficulty at the beginner through intermediate levels, but once you get into the advanced stuff they begin to differentiate.

> Yeah but the more advanced fields of physics like quantum mechanics are way harder than anything in chemistry.

That's a very loaded statement. If this were a forum for the physical sciences (as opposed to computer science), that would probably be analogous to saying "Android is easier to develop for than iOS" or "Java is easier than C#" (both of which would easily start flamewars on HackerNews)

Yeah, still... it's true.

A lot of chemistry is quantum mechanics. What is a "less advanced" field of physics anyway?

An example of a less advanced field of Physics than quantum mechanics would be Newtonian mechanics, such as is taught to college freshmen and sophomores. At least it seemed a lot easier to me.

That isn't a field of physics that's a high school textbook.

There are people doing very advanced and difficult things in classical mechanics, even if they aren't the problems or topics that show up in a freshman physics course. There are also trivially easy quantum mechanics courses out there, so even if you are going to rank fields of physics by how "advanced" they are, I don't think going off the order they're taught to undergrads is reasonable.

Great advice. Except for JavaScript on the backend. That's horrible advice. ;)

Please don't write backend in JavaScript. It's an ugly hack language full of pitfalls that we're stuck with for now on web pages; why put it on the backend where uptime and reliability are even more important? You need a slew of extensions to make it predictable and debuggable enough in that situation. I have yet to come across a situation where I really needed to share a library between my web page and server application, but I have in the client and server of a non-web game, so there are probably reasonable scenarios where it's useful, but from what I've heard getting a JS library to the point of portability between both webpages and node/other JS backends is more trouble than it's worth. PHP is even more of an ugly hack language filled with pitfalls. I've had a much better time writing backend in either .NET or python. Python's looseness still made it harder to deal with for complex situations but it's decent. If you like the idea of .NET on the backend but don't want to or can't have mono/.NET there's JSP which also is probably a good idea.

Web apps have been tilting more heavily toward the frontend (using a backend as an API/data layer), and I don't see that slowing down any time soon, so the frontend is the way to go, IMO.

If we're targeting the frontend and assuming OP's friend has limited experience programming, there's a benefit to learning the same (flawed) language in both the back and frontend, instead of learning two languages. Even if that one language is flawed.

I've shared code between Node and the browser using Browserify [0], and it's pretty easy. Page size can take a hit if you use modules that are meant for the backend and have large dependency graphs, but even then it could be worth it.

[0]: http://browserify.org/

True, and also front-end doesn't have to be based on legacy tech (HTML/JS/CSS). In this mobile-first world, native is a good option. Xamarin Forms is worth looking at.

Snarky. Glad you ended your comment with a constructive "learn Javascript".

I'd suggest that /you/ start him off with neither - your best bet is to turn him on to something like teamtreehouse.com's html/css/javascript course if he's already computer literate. Otherwise computer literacy is first priority and linda.com has some pretty good videos.

You should then after the 30 day trial be able to judge his passion by how far he gets. If he doesn't even complete the first chapter, then you would have wasted your time trying to teach him something he has no interest in.

I believe the way to introduce someone to web development is by teaching them something that has a tangible reward - e.g. design a static web page you can host, or have the ability to edit the HTML/CSS in a CMS or e-mail template.

My opinion is that anything is hard if you have no idea what you're doing. The biggest factor I've seen that determines if someone can become a competent programmer is passion.

I work across the whole spectrum from design to backend. During the learning phase both front/backend can be quite fun. Though it becomes less joy full when you are working professionally due to constraints, bugs, deadlines etc.

Anyone can start learning frontend development as you only need a browser and text editor to experiment. There are tons of free tutorials and books available to get going. I also find it helpful to see how other websites are implemented, last night I was going through khanacademy.org using chrome developer tools. However, professionally, I find frontend to be the most frustrating part of web development due to inconsistencies and bugs across browsers.

In my experience backend is the least frustrating part of web development once you know your environment, stay within that environment and follow best practices, most of the time things just work. It only get irritating when you have to integrate with some troublesome remote api which is not under your control.

But, to answer your question, I would say try both, see what he likes and go from there.

This depends on the person entirely because you can challenge yourself and push the boundaries in either one.

If your friend enjoys visual feedback/things then it would follow that they would probably enjoy front-end work better, however if they enjoy problem solving and tend to be more logical in their thought process, the back-end may be a better fit.

Begin with a problem then start with the thing that your users will see and work your way down the stack. New students enjoy the immediate gratification from changing a color, moving things around on the browser, or animating a great looking turtle. I recommending having a problem to work within as it provides constraints and a set of mini goals. "I need to take user input" then becomes "I need to process user input" then becomes "I need to put this user input somewhere" and once your friend visits each part of the stack, he can decide where he wants to spend time.

I didn't answer the "fun" part because it's not so great a leading indicator of career direction. Both sides have significant depth and breadth in terms of technical challenges and skill.

The answer is of course: it depends

"Modern" front end development will often involve build processes - gulp, browserify, whatever - that will introduce a barrier for entry.

Likewise if your friend wants to get into, say, C# development, you'd be much better off with a Visual Studio environment.

That's not to say that either of those are necessary, but I'd suggest that they are the norm for developers in those areas.

Alternatively, work with something like Sinatra and plain old HTML/CSS/JS - your friend could get a sense of one of the simplest methods of creating web applications.

So - it depends. Because there are so many choices, I suggest you find out their interests first. Is it visual? Then maybe they'd prefer frontend. Is it in the overall architecture of an application? Then maybe they'd prefer the backend?

When I started off there was something really gratifying when doing a static web page front end. You get immediately rewarded when throwing in an img tag and setting some basic CSS (if you start from nothing, it's really nice to get visual feedback). But soon after I wanted to get into 'real' coding and got interested in TDD, and finding elegant solutions for problems be it backend or a complicated UI. If you can spark that kind of motivation I'd say your friend is good to go. I'm also working on a program that I'm basing on my experience of teaching myself how to code: http://archi2tech.com/ maybe your friend is interested ;)

I would have them try both and see what they like more. I came from a backend development background and found the most difficult thing about frontend stuff is figuring out what the best tools, frameworks, etc. are to use. As soon as you learn something new and shiny like Angular, Bootstrap, etc. there's a new thing like React and Flux to check out. The build systems for frontend tools are IMHO a pretty big mess, annoying to use, and changing very quickly too.

Regardless of which path you take learning solid algorithm and software engineering skills will help with any development you do, frontend or backend. Consider your friend might not even care about web stuff too, perhaps they'd rather make games or mobile applications.

Which is more fun may depend on the person's skills. For instance, a person with a background in design may prefer front-end. IMO, it's best to start the person off with at least basic understanding of HTML, CSS, JS the reason being that all web sites have a frontend, but not all a backend. Codecademy Web Fundamentals can be good for this. I guess in the end, really depends on what kind of web dev the person wants to do. The person will be motivated to work on what he or she wants to build for pleasure.

It depends on what you want to do and where you want your career to go longer term, but that's specializing. Realistically, you should start him out learning the entire stack and understanding how different pieces fit together to create a complete picture. Perhaps something like Ruby on Rails that includes a more end-to-end approach. Knowing how the pieces fit together early helps you understand what you enjoy doing and makes understanding future co-workers more expedient.

It's really hard to get a friend into Web development. You can encourage, mentor, and guide them but someone has to be genuinely curious and excited about web development.

Each of them requires its own paradigms and conventions. Writing good UI code that works cross-client (especially on mobile) is often a challenge that requires different thinking than backend code. On the other hand, backend requires you to think about databases and scalability, which may not be your bread and butter. I genuinely enjoy each of them for different reasons. I don't think it's tenable to argue that one is objectively harder than the other.

To build anything non-trivial you really need both, but the frontend is generally easier to start out with and get enough visual feedback to motivate you to go deeper and deeper into the stack. The reverse is far more difficult for most people.

As you go deeper and get exposed to more concepts, it's only natural to specialize in either backend or frontend.

It depends.

Both can get difficult and being an expert requires lots of training. However, I believe that frontend is easier and more fun for starters. With little skill you get something on the screen, with more skill you can make some really sweet stuff. If you can hook in some existing API it's easy enough to do a dynamic site.

Why not both at the same time?

1. Think of a small project (one you could do in a weekend)

2. Architect it as a backend API + frontend consumer.

3. Explain the architecture to him at a high level.

4. Teach him Python/Ruby with bottle.py/sinatra, make the API.

5. Teach him HTML/CSS, make the layout.

6. Teach him Javascript, call the API and manipulate the DOM.

I like this approach, but I would reconsider step 6 as soon as possible. Most people move away from directly manipulating the DOM, because it's just not sustainable. Better to set them along the path of having templates that render to the page.

Facebook's React.js [0] could be great for a beginner. Even though it's another library to learn, it's conceptually simple and has a very small surface area. Components (optionally but usually) have a number of properties and (always) a render() method which renders the component to the page. There's more to React than that, but that's enough to get started.

[0]: http://facebook.github.io/react/

Yeah, agreed. I was speaking in the general sense. Definitely better to teach Javascript via a framework (whether it's Angular, React, Polymer, whatever) than manipulating the DOM directly.

Right, gotcha.

I wouldn't throw a framework like Angular, Ember, or Backbone into the mix right away though. They have a lot of moving parts.

The thing I like about React is that it's just a view layer, and can be a very simple one at that. A beginner could start putting things on the screen very quickly, then pick up a framework or larger app architecture later on. Not only is it a way to get started quickly, but the core concepts of a view layer learned through React would be applicable in larger frameworks.

I can't see why there would be a consensus best answer for this. People enjoy different things and are better at different things. If you want to get your friend into web development, I'd advise having him work through one of those complete tutorials where you write a bit both sides of a site, and see what he enjoys more. I know there are different languages for back end but I think any good tutorial should do, as the problems you solve on the backend I think are pretty consistent over the different languages.

Some people really like working front-end and doing all types of things to make a page load quickly in all browsers/look good or whatever, and some people like working on the back end and getting it up to 10kqps ro something.

I like back end but that's just my personal taste. Let your friend be good at what he's good at, I think the job market wanting both skills right now if that's the reason your friend is trying to learn web development.

And don't forget the whole world of non-web programming :)

I see what you're going for with this answer, but given certain constraints, there are definitive answers to this question. I feel like saying "people are good at different things" is the statement we tell children so they aren't discouraged

Front end is harder because success is less objective. I think that backend has for more technically difficult problems, but if you want a straight answer to this question without lots of caveats then front end is harder.

Frontend, with a backend serving as an API/data layer. But focus on the frontend.

That seems to be the way things have gone and are going, and I don't see that changing any time soon.

For a long time, the hardest was front end because you had to remember all the bugs and incompatibilities of various browsers. I think it's getting better.

Front-end development is easier if (a) they are a designer (b) they know a designer. HTML, CSS and JavaScript are easy, but making a design is very hard.

My advice: show her 3 lines oh html that talk to 3 lines of backend. Once she gets it, she'll decide by herself which parts she wants to hack first.

Nothing is hard once you have put your 10000 hours of practice in.

But this is a question about personal preference. Different people have different strengths and weaknesses, different personalities, etc. We cannot answer for your friend. The best approach would be to gain a broad exposure to all layers of the stack, not just "front-end" or "back-end", but also the databases, servers, networking, and all those pieces that comprise the modern Internet. Any one of them might spark an interest and a passion.

I'd say back-end. The front-end of any software no matter how complex it is it will always run on a single device, while a scalable back-end could imply a complex architecture composed of multiple components running across multiple servers, all working together to serve the front-end.

A single device that can be any out of 100's of devices with different browsers, screen sizes, densities and capabilities...

Alternatively, the front end can be run on hundreds of different devices and differing environments, while the back end's environment is completely and utterly locked down.

YMMV

Why not try both and find out which comes across as easier for you.

Frontend, without any doubts. A lot of compatibility and legacy issues, most of tools are in "beta", main language was made to "move a monkey".

Front end is harder, because people that have no knowledge about how things are created can more easily justify their decisions because of the way it looks.

the back end just needs to work as intended. The details can be pretty much any combination of things..as long as it works.

> Front end is harder .... the back end just needs to work as intended. The details can be pretty much any combination of things..as long as it works.

I think I know what you're trying to say - front end work is easier to justify to a client because he/she can easily "see" what you did.

But your statement that front end is "harder" and that the details of backend implementation don't matter are patently false. Let me guess, you're a fronted developer right?

My guess is he is backend developer.

I've done both. Front-end is much harder in my experience.

"don't matter are patently false"

okay. I'm going to go to my boss and ask him if I should use an array or a linked list for this part of my project. He won't care. He does care if it works and if it works well. The actual details don't really matter to him.

However, if I show him an admin interface, he will have all kinds of opinions on where things should go and how they should function.

Developers have much more of a say in the back-end, which makes things easier. Especially when the people making the decisions have almost no experience in the matter.

Maybe at the entry level but what about scaling an application that handles personal info (and credit cards) over multiple servers (just for example)?

What's the most complex backend stuff you can think of? Perhaps Google or Amazon level engineering? There's simply no equivalent of that on the front end.

TL;DR I'm pretty sure the majority of the PhD's at Google are not writing CSS.

There are increasingly more tools for creating the frontend without code - my favorite right now is Webflow. This will continue happening because that's what we had in the past (Smalltalk, VB6, and so on).

Nothing seems to be replacing the need to code backend any time soon.

That's my argument for learning backend: frontend coding is unnecessary and an affectation of the current industry.

Reply on news.ycombinator.com