Questions Answered - Learning React, Node vs PHP, should you share code?
You got questions? We've got answers. We gather up the latest questions we've answered from across the tech side of the web. With each answer we hope to contribute back to the community and expand the availability of information.
NodeJS vs PHP: Which is an easy option for building backend?
PHP will be the easiest platform to execute on a wide varieties of platforms, since most web servers (even the cheapest ones) come with it installed. No need for a VPS or SSH access - just upload and go (usually - unless you're using packages like composer or frameworks like Laravel or Symfony).
NodeJS on the other hand requires special hosting packages (like Heroku) or access to SSH. You won't be able to upload your files to most servers and expect things to work -- it'll require you to install dependencies onto the hosting server.
If I had to start my own website with little to no money, or if I planned on working with cheap clients, I'd use PHP.
If I wanted to (eventually) work for an enterprise-level operation that can pay for a bunch of cloud based microservices -- I'd go with NodeJS. You'll learn the most, as most of it's workflows (NPM, transpiling, etc) will translate to frameworks like React. It also forces you to go into the "backend" more than PHP ever will. Both will do server side rendering, but only NodeJS can create a virtual server (using Express).
Hope that cleared a little up. I struggled finding a clear answer between these technologies as everyone's opinions outweighed practical reasoning. Ideally NodeJS is better, but there's a reason PHP is so popular -- it's easier to implement.
Should a team share all it's code?
Man, if this was happening in my office, people would get laid off immediately. Real talk. I'd rather pay for a new employee picking up my stack than keep paying an asshat.
No one has the right to withhold information that doesn't even belong to them (unless the contract says they own the code?). If we're working on the same app and same dataset, we'd better be on the same page with our data structure. It's not a matter of ego - or my work vs your work -- we're all working on the same project for the same goal.
If you're on the team, but you're more interested in your individual stats than actually winning the game -- you're off the team.
Obviously I'm speaking from a managerial/authoratative perspective where I run my ship very differently than most. If you're dealing with this from a colleague, I'd approach the project manager/HR and express your concerns. Ideally, they should be able to speak with the team and set them straight.
Which is the best way to keep on learning React once you are not a beginner?
scotch.io has some more advanced tutorials.
egghead.io Namely, they have a course from the creator of Redux on how to use it.
There are a couple of people on YouTube who do React tutorials and get into more advanced topics like Free Code Camp, or you can glean vague information from developer seminars from AirBNB, Netflix, etc.
You can search for React articles on publications like Medium or Full Stack React. The official React blog is great for keeping up on updates.
A lot of React is all about ECMAScript, so I'd find a few resources to refine your grasp of that.
And as Mikey Lee mentioned, I'd highly recommend searching for React projects on Github and backwards engineering functionality you're interested in. HNPWA is a great site with YCombinator Hacker News clones done in various languages - they have a few React stacks built with GraphQL/Apollo and whatnot. And React.rocks doesn't update much, but they have a few interesting app examples.
Finding case studies from sites that switch over to React is an excellent option as well. Modern Tribe has a decent breakdown of their production of a React/Redux Wordpress theme built on the WP API.
Are most developers living in a cocoon?
"Most meet-ups these days are very specific, they are about a specific framework and fanboys/fangirls going all crazy over it and describing that framework as the best thing ever.
There's more to engineering than say React or Angular. People I've worked with over the years (and that's the only basis I can use to comment on) are so accustomed to a framework and that's the only thing they talk about. They often do not step out of their comfort zone and are happy with whatever framework they know." - Siddarthan Sarumathi Pandian
You gotta pick one at the end of the day.
I'm not building a hybrid React / Angular / Ember / JQuery app, that's not efficient. And picking one is difficult, because they each have their strengths - as well as nuances.
That's where the debates and line drawing begins.
Coders are like artists, we pick our tools and fields and gain experience in them. You may ask me to design you a package, and I can ask: "Do you want me to use a brush with oil paint? Or a digital stylus and illustration software? Or a photograph from my digital SLR?" We all get to the same end point with different methodology to achieve unique results.
And we all have limited time. I only have so much life in me to learn every language. So I'm probably going to pick a top 3, or 5, and focus on those. And then I've got to figure out how the languages meld with my team.
I'll also probably have strong opinions about my choices, because I don't make decisions lightly. And that's O.K. too, because that passion will translate into a deeper understanding of the ecosystem. It helps justify decisions when someone understands why they make them. "I don't like React for this type of function because Angular handles this better and here's an article from Evernote with data proving it." It's a healthy debate, rather than "X is better than Y period".
Part of the KISS is the initial debate of what the simplest route would be, rather than being forced to refactor opinionated code later ("Why are you using Angular for this one form when the rest of the site is Mustache? I thought we agreed on this...").
It's like you said, you just pick the best tool for the job, but not every artist is trained in every tool. I won't force a team to go Node if they've never touched it and prefer PHP.
If you'd like to ask us questions, feel free to hit us up on Twitter, invite me on Hashnode, or use the contact form.
Stay regular,
Oscar
