This post is an excerpt from my 2019 Sunrise Journal (built with Hugo, Imgix, Flickr, and yes, jQuery), which I thought would be interesting to share with the dev community.
I've been a professional web developer for over a decade. But lately there's been a recurring question in my head, "If I don't use React, am I still a developer?"
In one regard, I've never been more confident in my abilities. I can be handed a design and make a functioning site with many of the best practices, tie in API services, and create some advanced functionality.
It all began with my first website in 1996, learning HTML and CSS on Geocities when I just was just 13 years old. Eventually I learned to make dynamic websites, mastered Wordpress, learned MySQL, managed several WHM servers, fell in love with regular expressions and did so while working for on some incredible projects through a couple agencies and have used my knowledge to launch some fun projects.
In another regard, I feel like a complete hack. I've been a casual dev.to reader for a couple years. Now when I read the content, I feel everything is entirely over my head. Being in the remote Upper Peninsula of Michigan, it's difficult to find developers to learn with. I don't relate to a thing I read about the culture of Silicon Valley or the startup scene. Being entirely self-taught I feel basic concepts of programming or development are beyond me. React, ES6, AWS management, node.js, Vue, and package managers are completely beyond me. And worst of all, I still build using jQuery and PHP (it's ok, you can laugh).
This is a field I love, but I feel like an old guy (PHP) in a young guy's game (React).
This leaves me with many questions.
- Just how in the world does one keep up with it all?
- If I don't keep up, will I still be taken seriously as a developer?
- Is there a place in the dev community for those who are marketers first, and developers second?
- Is becoming full stack out of the question?
- And alas, if I don't use React, am I still a developer?
Top comments (88)
I think what really makes or breaks a person as a developer is the ability to move data around.
It doesn't matter what language or framework you use, once you know how you want your data to flow through your application you can implement it however you like. Knowing how to handle data structures, how to communicate through the application, that is what makes you a developer, knowledge of the language is important but once you can handle data flow, then you can pick up a language/framework and get productive. but that is just my opinion of course.
I love this first sentence. So much of it really begins with data. Sourcing data, organizing data, sending data, and I'm a data junk at the root of all of it.
My idea of heaven is just an open source database of every data endpoint one can dream of.
That heaven you described sounds a lot like GraphQL and Prisma. Check out Prisma some time for sure. :)
Btw, I know it’s tough to keep up. But I bet you know more than you think. And most good employers care about raw skills instead of buzzwords. Stay positive, my friend! Also, killer profile photo! :)
Try to check out Postgraphile some time. I think it's even better than Prisma (runs on node.js)
Also maybe a great way to get into some new things, if you just check out their examples and play with it.
to answer your question: I don't think you stop being a developer (ask the cobold guys) if you stop expanding your toolset, but you for sure get less and less relevant in a area that's always pushing forward...
"...My idea of heaven is just an open source database of every data endpoint one can dream of..."
That is great, I use that phrase?
Absolutely. Just quote me if possible 😉
WIll do Bugsy, ty.
I'm with you on the React stuff. I work mainly back-end but sit next to React developers, and looking at what they do is... annoyingly daunting. I think it's because a lot of modern javascript is as terse as possible, and I think that's driven by a culture of wanting to be seen as clever, and that it's a Bad Thing for Everybody.
I mean, I know terse, I used to be a Perl programmer for crying out loud, but as I get older I find myself wanting everything to be clearer and closer to human-speak. It's like when people say they've made something as a "one-liner" which is really a bunch of semicolon-separated ternaries with variable names like
aandb. Very clever, have a biscuit, don't bring that stuff anywhere near my codebase.Going back to the title... well, React isn't ubiquitous. It's, am I an artist if I don't use acrylics?, not am I a painter if I don't paint?
I find myself saying I'm going to learn something in my spare time and then spending that time watching TV instead. I don't feel bad about it. I keep up with the things that interest me, and that might be a new framework or language and it might be the characters in Game of Thrones. I only have so many bytes of brain left, and I have to prioritise.
"... I think that's driven by a culture of wanting to be seen as clever, and that it's a Bad Thing for Everybody..."
100%
Lot's of things I agree here, especially the "one-liner" and using your spare time to just unload.
One thing I'm really curious about, though, is this:
"I mean, I know terse, I used to be a Perl programmer for crying out loud, but as I get older I find myself wanting everything to be clearer and closer to human-speak."
What "human-speak" language(s) do you use? :-) Or which one(s) do you consider "human-speak"?
Probably Python (which I used to use ages ago and picked up again recently for Advent Of Code).
The zen of Python defines a lot of that as things like "Explicit is better than implicit, simple is better than complex." and its whitespace requirements force people to write short, clear code.
I usually find myself asking the opposite when I am hiring new developers: if this person only knows React - are they even a developer??
Unlike Angular and Vue, React reinforces bad design patterns since the view and logic of a component are rarely separated, and this makes it difficult and messy to do team development.
For example, I recently hired a "React only" dev who seemed hungry enough to learn other things. Unfortunately, they quit after a week without contributing any reasonable commits. The final straw seemed to be a lack of willingness to understand proper MVC.
This was obviously an extreme case, but I've experienced similar things before among young devs of our current generation. Unfortunately, the same things that make React easy to learn mean many new developers won't bother learning the reasons behind the decisions that power React or how to use web components without React.
In our current epoch, it's important to learn how web components work, but the framework you use to achieve this shouldn't matter, and there should be some emphasis on learning how web components work at their most basic and without any framework (W3C spec).
Anyhow, enjoyed your post and was "old dev" enough to understand the feeling :)
“Unlike Angular and Vue, React reinforces bad design patterns since the view and logic of a component are rarely separated, and this makes it difficult and messy to do team development.”
Spot on!! Not to mention how the react community is...not the most welcoming and accepting of other approaches.
Don't mistake logic with business logic
I’d argue that full stack is a bad term and no one really is. Full stack is really stack agnostic. Dangerous in multiple areas with strong underpinnings to quickly pick up whatever you need to. All the while being aware of the fact that someone who is a specialist might be more efficient at implementing whatever thing.
That being said, learn what you want to learn. Grow your skills in what interests you. Sure, it may not be the technology on every job posting, but tech is going change again and continuing to stretch your learning muscles is what truly matters.
I'd argue that there are genuine full stack developers.
Not all companies have the budget or "perceivable" need for teams of people.
I know an e-commerce company turning over £3 million a year with a single developer who handles the design mock-ups, frontend, backend, database, backups, you name it. I'd say that qualifies as full stack.
The trouble comes when you expect a Jack of all trades to be a master in a specific field.
And I think that’s why the term doesn’t fit in my mind. There is that expectation. But you’re correct that there are absolutely people working all across the stack and doing great work. But I’d still call them stack agnostic :)
Gosh, this is basically how I feel. I don't have nearly as much experience, but I am extremely confident in the skills I do have. My passion is HTML and CSS/SCSS and accessibility, ultimately leading to UX. My JS is mediocre at best... But I can write some decent PHP. For years I questioned if I could even be considered a developer.
The Great Divide by CSS Tricks made me feel a ton better as it showed me that there are many others like me. In fact, we're no uncommon. However, I'm looking to get away from my current job and I haven't found a single post that doesn't mention JavaScript and it's frameworks as being important.
It's a trapping feeling.
This resonates with me so much.
I honestly feel like none of my other skills matter at all any more; The only skill that seems to matter is knowing React.
I've been trying to improve my JavaScript skills... I'm pretty comfortable with DOM manipulation, but I don't know ES6 well, nor have I ever worked with APIs or done anything with Node.
I am trying to improve but so many days it feels like I can never move fast enough to keep up, and I worry that my type of Front End Developer is going to disappear.
As José Muñoz said above: "It doesn't matter what language or framework you use, once you know how you want your data to flow through your application you can implement it however you like."
Given their name, developers should be able to develop. But developing is only dependent on knowing a way to develop, not necessarily developing using a specific framework like React, or even a specific language like JavaScript. Not unless you want to be a JavaScript and React developer.
If you feel like you want to improve as a developer, then work on improving yourself as a developer.
If you feel like there is a trend towards using React, instead of experiencing it as a trapping feeling, go with the flow and at least try to understand what all the fuss is about. You do not have to learn anything you do not want to. Development is in and of itself method agnostic. Do it how you want.
3.b) Ah yes, those are great terms to keep in mind.
5.b) Coincidentally, I met John Carmack once while having a tour of Armadillo Aerospace in Texas back in 2007.
I don't think using a framework makes you less of a developer, if you ONLY know how to work within a framework then that's a problem, but doing lower level stuff doesn't mean you're good or anything, I've seen very bad implementations of assembly, and attempts of programming languages
You have years of development experience. My opinion is, It doesn't matter what tools you use, what matters is a working final product which is maintainable and scalable.
"I fear not the man who has practiced 10,000 kicks once, but I fear the man who has practiced one kick 10,000 times." -Bruce Lee
I feel that this is old article is also related: blog.codinghorror.com/the-magpie-d...
However over the course of my professional carreer (almost 14 years now) I do feel that the industry is sort of... settling. Slowly. Oh, it's still pretty much in turmoil and new ideas and frameworks still appear on a regular basis, but at the same time... some concepts, principles and ideas seem to have coalesced. They've been mulled around, variations have been tried, best practices have been found and are now accepted as the Right Way by almost everyone. And they've stopped changing. There's an implementation or five in most popular languages that vary mainly by method names and no others are being created, because there's just no point.
In backed this would be, for example, the areas of ORMs and Loggers. Take a bunch of active libraries and compare them. The differences are mainly in small details and naming, but the core concepts and patterns are the same. There's no big innovation left there because we've already reached a state where they're good enough for all practical purposes. In a similar way, GIT has won the source-control wars.
And I wonder if the same is happening in the front-end world? That's not an area I'm deeply familiar with, but from the sidelines it also seems like there is a sort of settling. We have React and Vue which are based on the same ideas and everyone seems to be happy with them. There hasn't been a major paradigm upheaval for years now.
Nobody can predict the future, of course, but I think that if you wish to go along the front-end route, then picking up React/Vue would probably be a good investment of time, likely serving you for years to come - if not the rest of your life.
In other words - even if you have fallen a bit behind the times, I think that catching up is easier than it seems. :)
If you can produce quality and keep up with new best practices (not necessarily trends), then yeah. One of the reasons for hate of new tech is inability to learn. People still hate JS because their knowledge is stuck on old ES5 or the recent years fast pace changes, even though things got really settled for a while. Same for PHP hating (they're hating legacy stuff, while not aware of v7 changes). Same goes for trend followers who immediately look at others with disdain if their knowledge of news is old a few weeks...
Oh good. I get to be the first to mention Elm. Recommend you skip all this JS framework stuff and go straight to the gold. I do use jQuery and JS for an existing client and have used Angular and React in the past. However to me Elm just makes so much more sense as the future of front end.
I couldn't agree more.
I have recently written about developers jumping on the React bandwagon without having a sold grasp of the basics. Don't start with React
I believe there is nothing wrong with choosing to stay away from React and its peers. Not every website need to be a Single Page Application. There are valid uses cases for 'older' stacks.
Great article Maroun. This totally needed to be addressed. Thank you!
Thank you Tanner!
Nope, I just think you are still a developer regardless of the tools or programming language your as long as your solving problems using code.
Using pure PHP without web frameworks is something you definitely can wear it as a badge of honour.
There is actually a place for someone which is called "Developer Relationships", "Developer Evangelist" or something around that line that focus on marketing first and developers second. You can take a look at this below.
7 Tips for Breaking Into DevRel
Nader Dabit ・ Mar 6 ・ 8 min read
What developer advocates do
Lynne Tye ・ Feb 20 ・ 9 min read
Yes
Now go learn React!
Not to be a "real developer" but because it's easy especially with vids and tutorials... Who said you have to know everything? No one
Forget about Redux, it's dying anyway and replaced with Context API or GraphQL or others... Just learn plain React
Good luck
Sorry, but I have to answer.
Reduxis about state evolution in time, whilecontext APIis about drilling props down, whileGraphQLis just about querying data from your backend. That are 3 different ideas, absolutely orthogonal to each other.This is all accurate, but the differences matter not to a beginner -- and in practice, few use the major benefits of Redux (rewind, fast-forward, state hydration) while they do use it to pass props. Meanwhile memoization sounds great, until you realize you fetch the data only once, or only once in a long while.
So you can say the philosophical drive and even the main advantage of each is totally different, but in many projects (including large ones) these are subservient to the actual business requirements. If this were not true, there would not be unlimited number of Medium articles or people proclaiming so. Simply put it matters not what the libraries were designed for, only what they are used for. You may say that Context API shouldn't be used for complex state operations and you would be right, but neither should Redux be used for complex state operations. That belongs in the memoization layer, for example reselect. Or perhaps even encapsulated in the component itself.
But none of that matters. The main point is, you do not need Redux to do React. Redux is not React, and the documentation of Redux even includes a section for when not to use Redux. Redux is a major stumbling point for many people entering the React ecosystem, but it can be completely avoided until such time the problems it is designed to solve are actually encountered.
In short, no need for Redux to start, and perhaps no need ever.
I could definitely agree - redux is overused and usually not needed. You have to have some complex situations or conditions, which could be easily resolved in “redux way”, not the “component way”, and you may be lucky not to face such situations ever.
But it worth to understand, as long redux and react are based on the same immutable data structures ideology, and they helps to understand each other.
Oh gosh so much of what you wrote up there I resonate with. Geocities and Tripod were GOOD TIMES. Dicking around with code before that I was a kludger and never really truly understood how it worked, and maybe even resisted that.
I started pursuing dev professionally in 2016, and like you, React came and went and then stayed. I learned Angular and Vue and also feel I have missed the boat. But it's never too late.
It doesn't seem I can get a job in Toronto for the next 2 years without knowing React, but I'd hang in there. Some people just want a swiss army knife expert in JS, Rails and Python.
I could always fall back on email development or maybe Wordpress if I can't find a proper gig. But I don't feel I have pulled my weight yet.
and yes you are a developer. I am a developer, albeit a shitty one.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.