Are PHP devs still full-stack?


#1

Phil Sturgeon posted a tweet the other day that made me think:

Full stack developer? Like fuck. If you ask me to CSS or write another HTML form I'll punch things and cry. Here is your JSON. Good DAY sir.

— Señor Phil ( @philsturgeon ) April 14, 2015

I've built my share of HTML, hacked together some CSS, and written a good bit of JS that still lives in relatively high traffic production apps, but when I think about it, it's always, always a pain. Contrary to the back-end where my code does exactly what I tell it to do, on the front-end side of things there's the ridiculous new-framework-per-day parade in the JavaScript world, along with an uncomfortable disparity between not only different browsers but also different versions of the same browser regarding CSS and JS features and not just how they work, but how they render. What's worse, this can differ per OS.

In fact, it seems like every tutorial or blog post about front end technologies is a "Clever hack to do this" or "X approaches to make Y work in all browsers". The infamous vertical centering still needs workarounds, audio and video consistency isn't even on the horizon and is still only possible with the vastly underrated, under-appreciated and generally misjudged Flash player, and JavaScript, now heralded as the language of all languages, is just starting to get features other languages have had for decades. To me, a context in need of so many hacks and workarounds is inherently broken and needs an intervention beyond one that includes adding a feature or two to a language that's being taken seriously just because it's present everywhere.

I had high hopes for Dart to bring sanity to the web, but now that Google decided it would scrap Dart VM and compile to JS instead, the front end development world seems more adrift than ever and the only reason why those who are comfortable in it don't complain (much) is because they, I believe, grew accustomed to the chaos. You could argue that it's just about getting used to the tools etc, but I think HTML 9 Responsive Boilerstrap is right on the nose about this. Should being able to reproduce some text and shapes in a browser really include this much work, double-checking and frustration?

With that in mind, I don't think I'm comfortable calling myself a full stack developer any more. I can do front end but... I don't really want to.

How about you? Are you a full stack developer?


#2

As you note, there is so much going on in the world of the front end that I don't think it's possible (for a regular, normal human - if such a thing exists) to be able to specialise in both front and back end technologies and do both equally well. As chaotic as the front end world is these days, I do still think it's an exciting time.

There used to be a lot of emphasis on how the stateless nature of HTTP put certain special considerations in your path when developing an online client/server application, but the proliferation of these front end frameworks is changing that.

RoR brought us a paradigm shift (and Cake, CodeIgniter et al) away from web sites with pages to the creation of applications with business logic and presentation layers. The frontend js frameworks are doing it again, in large part thanks to the likes of the DOM, Ajax and web sockets, thereby making it possible to deliver a fully specc'd client application to run in the browser, which in turn lets the back end be the business logic and storage - the server end of the deal.

If this is the case, then there's a future where a PHP developer can become an awesome PHP developer without even needing to know html, css and js. The line stops at providing an api that can consume and emit JSON.

These are all just my impressions on the matter of course, but I think there's a direct parallel in play here.

If "Full Stack" means doing a good job of both front and back ends, then I think there's also a natural ceiling that ends somewhere in the MVC-like framework realm. Beyond that, I think we're looking for specialists in either front- or backend. There's a point where "Jack of all trades, master of none" comes into play simply because of the complexities involved in each domain.

So no, I wouldn't consider myself full stack either. Trying to keep up with the chaotic world that is front end is more than a full time job these days. I can totally relate to Phil Sturgeon's tweet!


#3

We have a dedicated front-end web developer but I still do it all as it is not realistic to stretch a single person across all the tickets and projects we have. Have I wrote JSON API for the front-end developer to consume and handle the complete front-end – yes but it isn't the norm. However, we aren't using any of the shiny new JS frameworks *yet. So in that regards I would still consider myself full stack – server/client and light devops. I also prefer to have a hand in everything because it makes me that much more knowledgable about our ENTIRE ecosystem and not reliant on a single individual to fix problems when they arise. Also being able to prevent problems before they start in every facet of the development process. While everything is getting more complex we also have a lot of new tools at our disposal to make sense of any amount of chaos because at the end of day you either know programming or you don't.


#5

Could not agree more. For 30+ years I coded embedded systems in C and then some C++. That is where the money is. When I retired in 2006 I did some websites for friends and charitable organizations I belonged to. I do most of my backend code in PHP which is like C in so many ways. My PHP code works all the time. I have given up on trying to get front-end code to work on all but the most recent browsers (sans IE). I just put up a warning message that informs potential users that they have an old browser and should not be so lazy and go download a new one.

I can get away with this because 1) I'm retired and 2) I'm doing the work for free. I really pity the poor coder that has to do this crap as a job. It seems that even the simplest most basic tasks are 10 times more difficult than they should be. There is just no good way to do things like grids. The "responsive" website is nearly impossible to get right in the most recent versions of IE, Firefox and Chrome let alone older versions and off brand browsers. Add the cell phones to the mix and it is chaos.

I really miss the "good old days" of the Internet when text was king and everything rendered the way it was supposed to. 90% of the time I go to the Internet it is for information and information means text. I really do not need or want my text adorned with flashy add for girls or medication. I do not need three or four columns. Just black on white text thank you.

Instead of easy to read information I get black backgrounds with blue text or white text on a very light green background. What are these idiots thinking. Todays rage is light gray on white, even SitePoint does this sometimes. Some sites are so bad that I ditch my Chrome and break out lynx, where text is king once again.

It is a sad state of affairs and seems to be only getting worse. I often think we should scrap the whole thing and start clean, I dearly hope we would not do it the same way again.


#6

I'm a front-ender and I feel this way about back-end code. There's just so much chaos to learn with all the frameworks, design patterns, etc.

HTML/CSS gets to the point where you can just go on cruise control. Oh, new framework came out? Features? Compare to other frameworks in your head.

As far as cross-browser issues, it's easy to avoid that. It's one of those situations where if you worked on it full time, you'd have no more issues doing it than you would with random PHP errors slipping into your code smile .

I can't change my car oil by myself but that doesn't mean it's complicated; I'd just need to spend some time learning wink .


#7

As the cliche goes I am totally feeling you on this.


#9

I actually disagree that development has become more difficult. I actually think it has become easier when standard tools are used, over custom, one off solutions. For one there rarely is any documentation with custom solutions. Once the developer(s) leave a company who build a custom solution typically the system becomes a mess, and problems ensue. That is much less likely to happen when using a standardized, open source toolset, especially one highly modularized in nature. Standardized frameworks are nurtured far beyond employment at any single company where as custom solutions built specifically for a client/company die the more and more people leave the company that had a hand in building the custom solution. Stack on top of that using smart debugging tools like xdebug and everything has become more easier to debug than the days of hacking code with print and log statements. I do think the barrier for entry has increased because of spread of all these frameworks but it really isn't much different than working at a medium to large size company. Any company is going to have some type of framework and workflow you will have to learn. Better it be one that can exist far beyond a single position than one that will die once you move on to the next employer which is one reason I'm a huge advocate open source standardization of modular toolsets for specific, high level tasks over reinventing the wheel. I think it is a false impression that things have gotten more complex when really they have been that complex all along if you work at any medium to large size company with a ecosystem of existing web solutions to solve real world business problems.


#10

The frameworks in PHP and in JavaScript make getting started with each hard. It is very difficult picking the right one. And after you have made a choice you better hope that your chosen framework stays popular for a while.

I built my own framework for PHP a decade ago and have upgraded and improved it over time. It does what I need and no more. I find the "all things to all people" frameworks, either PHP or Javascript, to be just too much: too much to learn, too much to use.

I have used jQuery for quite a while and it helps smooth the browser compatibility issues. I have shied away from most other Javascript frameworks for the same reason I don't use frameworks in PHP. It seems like there is a new favorite every other day and I just don't have the time or inclination to chase the latest fad. If I did I would never have time for real work.

CSS is a lot the same. CSS, SASS, LESS and who knows what is next. There are hundreds of CSS libraries with hundreds of CSS classes that I will never use. It seems like bloat to just include these libraries when what you really need is seven or eight functionalities.

I agree that HTML and CSS by themselves are simple technologies but the frameworks and libraries have complicated things significantly.


#11

The grass is always greener on the other side of the fence. wink


#12

I will take frameworks and responsive design problems over those that existed with browser consistency a decade ago any day of the week. At the end the day it is all css, or php or whatever. I think more often than not the people who are complaining about the complexity of these things are those that don't necessarily have a firm grasp on the underlaying technology itself. I mean if you're just starting out with technology then of course all these sub-ecosystem(s) of open source components are going to seem complex. However, to those of us who have been around for a while it really isn't all that much different from years back. The only difference is there is an attempt to further standardize processes and procedures in a way that is reusable for everyone, given any application or scenario. In my experience the archaic approach of building a custom, monolithic framework/ecosystem is far worse a nightmare to maintain than investing time in system/ecosystem that can be used throughout a career. Beginners also need to remember that as someone with nearly a decade of experience my intentions run counter-intuitive to that of their own. I'm always striving to make things optimized, scalable, reusable, maintainable and all around future proof which more often than not DOES lead to using more "complex" code. While readability is concern of mine I'm definitely not programming with a goal of someone who barely knows programming understanding what I'm writing. I'm not a teacher/professor I'm a service provider paid for solve specific problems so I take very little consideration into account in regards to how well someone will understand my code who barely grasps x/y technology. Which consequently does run counter productive to intentions of someone starting off and does tend to look more complex in nature but it all goes back to supporting that basic list of problems given any software problem.


#13

If by full stack you mean "do I do front end to back end coding?" damn right I do. Golly gee whiz, there's this newer (than my first site in '98) awesome way of doing things called HTML5, JavaScript is better and simpler to use than it has ever been, and PHP grows faster, tighter, better... and all of those have expanded the range of doable things immensely.

That said... I'm no longer an up-to-the-latest release PHP guru, or a JavaScript library guru, or even an HTML5 guru. Shoot, I'd be doing great to be a Wordpress, Joomla, or Drupal guru; yet I'd bet when I set to a project I could code my way to the finish line faster than 80% of the code guys out there, because my "full stack talent" is finding the right solutions to the problem and linking them together. [Mostly code stuck behind the corporate firewalls however; for my night job, I'm on the creative side (writer/composer vs. coder), so I haven't given back to the community very much, unfortunately].

I think we need to be grateful for better and better tools, never stop learning from more talented folks than ourselves, and do our best work at whatever layer we're asked.


#15

I am doing it all. I think Clojure and ClojureScript really close the gap between front-end and back-end application development. HTML and CSS are really design issues, structural and presentational, respectively, thus, I don’t really count them as part of full stack.

The main issue my fellow software craftsmen and I see is that hardly any framework, at least in the PHP and Ruby world, invites to good software architecture. Mistakenly, they all fell into the misinterpreted soup of MVC and the likes. JavaScript frameworks have been jumping the same bandwagon, which have shown to lead to incredibly complex code (I am especially looking at you AngularJS with your two-way binding). Facebook’s React is solving a lot of these problems on the front-end, and it’s understandable that the Clojure folks embraced this and made Om, a React wrapper for ClojureScript.


#16

I'm sorry but when I hear a programmer tell me that he/she develops for the web but does not do html/css/js then I just consider them lazy. If you are a web developer then using front end web technologies is simply a part of your job.

Don't want to do front end? Then don't work on the web! Just because you don't particularly like a part of your job does not mean that you can just decide its not your job. I'm sure nurses don't want to clean up a patient who crap himself either but its kinda what they signed up for.

The way some developers talk these days they actually think that they are above front end coding. Seriously!? If you are so far above it then you wouldn't be finding it so difficult would you?

Front end development takes time and research and experience to get good at. It doesn't really have any more variables than any other area of programming. I wouldn't be great at developing device drivers either but if it were my job I'd damn well learn it no matter what the learning curve. For a server only developer to dismiss front end work simply because they struggle with it shows that they have forgotten how they learned to code in the first place.

The fact is front end development takes every bit as much skill and knowledge as server side. And if companies try to separate the job then you will end up having the more experienced programmers on the server and the self-taught newbies or graphic designers who decided they could learn to code on the front end. Even though the two skill sets actually take a real programmer to fully understand.

In my opinion there is no such thing as a full-stack developer. There are only web developers and incomplete web developers.

Those of you who feel they are above JavaScript need to get over yourselves. You are not special. And you are doing yourself a great disservice by continuing your career path with blinkers on.


#17

Where the project also involves a web designer then it is as reasonable to expect the designer to create the front end code in which case the web developer would not need to create that part. The HTML and CSS at least are more likely to be the job of the designer to produce rather than the developer - particularly the CSS as it isn't really the developer's job to implement the designer's design..


#18

I'm confident to call myself a Fullstack Developer. I started with desktop apps over 20 years ago, including 10 years of Delphi. I picked up Rails in 2006 and know that well for the server-side and still use it exclusively. I was never confident with the HTML-plus-jQuery-sprinkles style of front-end, and used Adobe Flex rather than fight with browser quirks. Now I use Ember.js with Bootstrap exclusively for the frontend, and the paradigm is very similar to what I had with Flex and Delphi. I rarely have issues with browsers, and ember enables a very predictable, stable environment for dealing with asynchronous issues.

I hated Javascript at first, and wished it would go away. Now with Ember and its object model, and Intellij running jslint constantly over my code, I've learnt "the good parts" and what to be careful of.

I don't claim to be a designer. Bootstrap is enough for most apps. Otherwise I purchase a theme or work with a real designer. The problems you describe sound more like 5 years ago than now. Life is pretty good with the above, and I have no desire to chase another hot new framework. I'd rather have fun building an exciting new app.


#19

I always focused on front end, going way back to 1998. I'm comfortable doing all the front end things being described as difficult.

I'd tend to agree that front end is WAY more complicated, in general, than backend coding - some of the time. It's easy to assume the backend code is more straight forward when dealing with browsers, javascript UI problems etc.

The reality is that for each handful of simple backend functions that return a little JSON, there is a monster function that has to do POOP TON of querying, sorting, re-querying, resorting, splitting, transforming, calculating and filtering before making that little JSON object.

I do a lot of HTML. I do a lot of CSS. I do a lot of Javascript. I do a lot of PHP. I do a lot of MYSQL. Unfortunately you can't be GREAT at all of them.

I'm a Senior Front End Developer by title but I do just as much PHP as the front end stuff day to day.


#20

Certainly. I agree that a Graphic Designer should be expected to produce the design they have created as html and css templates. In fact that is how I work currently. However in most websites and applications today the front end becomes a lot more complicated than simply interpreting a design and coding it up in HTML/CSS.

Generally I do not expect a graphic designer to do javascript. Especially in application frameworks such as angularjs which I definitely consider beyond the capability and responsibility of a graphic designer. Additionally any JS widgets such as sliders or some particularly complicated navigation is something that a programmer should handle. Especially when such widgets have to be written is such a way as they are reusable and can interact seamlessly with your in-house server code. As such a programmer will need to write the js and the html/css for the widget.

To be able to write this kind of code effectively the programmer needs to be intimately familiar with the DOM and the various front end tech. How can you write good JS which manipulates the DOM if you do not understand the DOM and work with it regularly?

Finally there is a lot of front end markup such as web forms which are inseparable from their server-side code. If I am writing a complicated stepped web form with client side validation then I will look at the design and reproduce it myself as it would just be too complicated for a graphic designer to do effectively.

Graphic designers no matter what their experience are going to need support from programmers who are experts in the front end technologies they use.

I think that this thread is not so much about the graphic designer - programmer relationship. But more about splitting the programmer field into server side programmers and client side programmers.

Whether a company decides to separate responsibilities this way is their business. However I think it is a mistake and any programmer worth their salt should be striving to be proficient end to end in the development process.


#21

What? You call yourself a builder but don't do skyscrapers? A painter but do landscapes and not portraits? A mechanic but don't do jets? A surgeon but only do hearts??? You're all freakin' lazy! That goes for you 'pastry chefs' and 'novelists' too! You know who you are!


#23

I am agree with @swader, I am a PHP developer but in my company we have very small group of web developer. And for front end developing, everyone responsible for their work. Because here too many small companies who does not have separate dedicated front end developer. We need to do this work our own. And as per @swaden, in current era, programmer is able to use all kind of tools, technologies either it is designing or programming. So, as per me there is no any word "Full Stack PHP Developer" exists.


#24

What? You call yourself a builder but don't do skyscrapers? A painter but do landscapes and not portraits? A mechanic but don't do jets? A surgeon but only do hearts??? You're all freakin' lazy! That goes for you 'pastry chefs' and 'novelists' too! You know who you are!

More like a builder who builds roofs without knowing anything about load bearing walls. A painter who only can only paint men not women. A mechanic that only fixes engines but knows nothing of the drive train or gear box. Or a heart surgeon who didn't bother getting his M.D. because he only wanted to work on the heart.

Specializing in something does not necessarily mean a complete separation of knowledge and duties.

The front end is the product of your work on the server side. The server side code outputs what the front end displays. A programmer should understand the product they are delivering. In fact they should have intimate involvement in both processes so that they can properly orchestrate how they interact.