[orange8]

Okay. I'll explain it to you. It basically comes down to a server-client architecture. The server (db, server side code) is the backend, that the user never gets to see. The client (basically the browser - js, html and css) is what the user get's to see, not just through the interface, but by selecting "view source".

So PHP and Rails are back-end languages. You never get to see the code and logic that generated the page because it is "at the back". Golang, which the poster mentioned, is also a back-end language. So if the core of your apps logic is at the back-end (server), what you are practicing is back-end dev. If the core is in the front (e.g. SPAs) then it's front-end dev. Sometimes the complexity can be split 50-50 between the back and front. But if your web-application just uses html, css and a sprinkling of JS, then it is back-end driven. Another category is a website, which does not really have any complexity whether at the back or front.

So to correct your statement, PHP and RoR have never, at any point in time been considered front-end tech. If it is not html, css and js (including complile to js languages like ts), then it is not front-end dev.

[sethammons]

I'm not sure how long you've been in the industry. But you sound like it is less than maybe 10 years. Before react and such, you were considered a frontend developer when you delivered your javascript + html + css from any backend, though typically it would be served by php, RoR, or, more limitedly, by some python. Backend developers didn't touch html or css and couldn't be bothered to to think about js. The balance between full stack, backend, and frontend teetered on if you we're concerned with pixel alignment and UI things vs data storage, manipulation, and retrieval.

Again, back in the day, you wouldn't call yourself a backend dev if you did anything meaningful with html UI. You would still call yourself frontend even though you had to work through templating in a given backend language.

Source: I've been doing this for a couple of decades.

[orange8]

> I'm not sure how long you've been in the industry. But you sound like it is less than maybe 10 years.

Okay. No offence, but so do you.

> Before react and such, you were considered a frontend developer when you delivered your javascript + html + css from any backend, though typically it would be served by php, RoR, or, more limitedly, by some python.

Not really. Back in the day, before the great divide [1], the terms we used were "Web Designer" and "Web Developer". We also had "Flash Developer" but I digress. A web designer was expected to know all the front-end stuff including JS, since the front-end was not that complex. Almost all complexity was at the back-end, and that was the job of a web developer. The term "front-end web developer" simply did not exist in 2003. There was nothing to "develop" in the front end, since all complexity was on the back. Yes, there were some exceptions, but in those days, PHP was king. React is current king, and it's funny how it gets the same hate PHP got back in the day. Some people just like to tear down and burn whatever is at the top. Reacts successor will get the same hate. Thats how you know who the king is.

> Again, back in the day, you wouldn't call yourself a backend dev if you did anything meaningful with html UI. You would still call yourself frontend even though you had to work through templating in a given backend language.

Wrong. Why would someone working on PHP and MySQL call themselves frontend? So who were the backends back then? Strange thing to call yourself "front", when no one called themselves "back", don't your think? Like I said, the terms back then were web developer and web designer.

> Source: I've been doing this for a couple of decades.

Source: So have I.

[1] https://css-tricks.com/the-great-divide/

[illiarian]

> Okay. I'll explain it to you.

> PHP and RoR have never, at any point in time been considered front-end tech.

Okay, let me explain something to you, as a person who has been in this biz for 23 years.

What you're talking about is client-side vs. server-side which doesn't have a 1-to-1 correspondence with frontend vs. backend.

Frontend has always been about something user-facing. Backend has always been about something that is non-user-facing.

Client-side dev has hijacked the term frontend to describe purely client-side development. Even though with the exception of direct DOM manipulation there are very few conceptual differences between generating UI on the client and generating the UI via PHP/RoR.

[orange8]

> Okay, let me explain something to you, as a person who has been in this biz for 23 years.

Since you've brought up your experience, what exactly does "in this biz" mean exactly? What was your job title 20 years ago? 15 years ago? 10 years ago? 5 years ago? Now? If you've really been in the industry that long, you should have noticed that the job titles also evolve. Back when all the complexity was in the server, and JS was just a baby toy language and not the beast its evolved into today, the job titles were very different than they are now.

> What you're talking about id client-side vs. server-side which doesn't have a 1-to-1 correspondence with frontend vs. backend.

Just google "front-end" dev, or even use wikipedia [1]. The client-server architecture even pre-dates the web, but when it comes to web developement, the front end is css, html and js. Nothing more, nothing less. If you do not agree, then go edit that wikipedia page.

> Frontend has always been about something user-facing. Backend has always been about something that is non-user-facing.

What do you mean by "user facing"? Can a user view the source code of a PHP generated page? How is PHP user facing? Can you give me an example of a web tech that is "non-user-facing"?

> Client-side dev has hijacked the term frontend to describe purely client-side development. Even though with the exception of direct DOM manipulation there are very few conceptual differences between generating UI on the client and generating the UI via PHP/RoR.

The term client-side dev is never used in the industry. Never. What we use is front-end developer. Go to any job ad website[2] and look for the term "client side dev", you wont find it. What you will find is "front-end dev". Then look through all the front-end dev job postings, and show me one, even one that lists PHP, RoR or Golang as a job requirement. Here are some front-end roles [3][4]. Notice how none of them mention PHP, Golang or RoR? Then here are some back-end roles [5][6], notice how there is no mention of js, html or css?

Case closed. Have a nice day.

[1] https://en.wikipedia.org/wiki/Front-end_web_development

[2] https://www.ycombinator.com/jobs

[3] https://www.ycombinator.com/companies/golinks/jobs/k3k6PSz-f...

[4] https://www.ycombinator.com/companies/tractian/jobs/P6ri7Wt-...

[5] https://www.ycombinator.com/companies/svix/jobs/7DMKXxB-rust...

[6] https://www.ycombinator.com/companies/safebeat/jobs/2mJ95eL-...

[illiarian]

> What do you mean by "user facing"? Can a user view the source code of a PHP generated page? How is PHP user facing?

It literally produces the website that the user is looking at.

Unlike, say, a microservice that retrieves some data.

> The term client-side dev is never used in the industry. Never.

If you paid attention to what I write you could've seen this: "Client-side dev has hijacked the term frontend to describe purely client-side development. ".

This is what happened, and you are a great example of this.

Two technologies produce user-facing UIs and sites by stringing together data from different services and presenting that to the user.

"OMG PHP runs in the server this is backend unlike this JS code that literally does the same"

[orange8]

> It literally produces the website that the user is looking at.

Your definition is meaningless because EVERYTHING in the pipeline literally produces everything "you are looking at" from the database to the css.

> Unlike, say, a micro-service that retrieves some data.

That data still produces part of "what you are looking at". What a useless phrase. Stick to industry definitions, yours do not make sense. And there is no language called "micro-service". I asked you to name the so called "non-user-facing" part of the web development stack.

> If you paid attention to what I write you could've seen this: "Client-side dev has hijacked the term frontend to describe purely client-side development. ".

So, old man yells at the cloud and uses his own idiosyncratic terms. What matters is not who hijacked what. What matters is that the industry has settled on the term "front-end developer". Complain as much as you want, but realize that train left the station. Go ahead and use your own terms that no one understands because "my 23 years experience", but that's exactly how people fall out of touch. And then when you say thinks like "PHP is front-end dev" people will immediately dismiss your knowledge, so you have to keep reminding them "but look.. my experience!" The term is "front-end dev", deal with it.

> "OMG PHP runs in the server this is backend unlike this JS code that literally does the same"

Old man yells at a language that can be used both in the cloud and browser.

When JS is executed in the server (e.g. Nodejs) is it part of the back-end stack. When it is executed by the browser, it is part of the front-end stack. When it executes on both, it is full-stack. Kapish?

[creamyhorror]

It's simple enough: before the rise of front-end frameworks in the 2010s, web developers were indeed more of a single group ("full stack"). But even before the rise of Angular in 2011/12ish, there was already starting to be a specialisation in front-end vs back-end; some devs, I remember, worked almost wholly on the JS UIs of more front-end-heavy websites (they may have been more of web designers previously). Others concerned themselves more with the backend, databases, services, etc. As frontend technologies grew more complex (and mobile became of primary importance), the division grew.

Before Angular and co., "full stack" encompassed using HTML, CSS, and JS. What it can be fairly said to mean nowadays is debatable, but 10+ years ago, doing Rails with a bit of JS would definitely have counted.

[orange8]

> It's simple enough: before the rise of front-end frameworks in the 2010s, web developers were indeed more of a single group ("full stack").

They did not call themselves "full-stack" though, did they?

[creamyhorror]

The term "full-stack developer" was definitely around before React and Angular.

Sep 2010, a few job ads are looking for "full-stack developers": https://news.ycombinator.com/item?id=1659409

Comment from @peteforde on Dec 2010 https://news.ycombinator.com/item?id=2053957

====

The key skill that you're looking to pick up is actually what professionals think of as "full stack web development". That is, you should aim to understand lots of things:

- MVC web frameworks like Rails and micro-frameworks like Sinatra

- MySQL and non-relational datastores like MongoDB

- web and proxy servers like thin and nginx

- Redis! it's like a Swiss Army knife... but also Memcached

- jQuery and Haml/Sass

- Backbone and websockets

====

Basically, in 2010, if you knew how to work with jQuery, Haml/Sass and maybe Backbone (in addition to backend tech), you could be called "full stack".

And that Sep 2010 Who's Hiring post had many ads looking for front-end (or UI) and back-end engineers, meaning that it was common to be specialised at the time.

Looking back, wow, the experience/knowledge requirements back then were pretty low compared to today...