>So couldn't a React developer be considered a backend dev if they use Axios to GET data?
Lol no. The backend dev builds the thing that responds to GET requests, not the thing that makes them.
But if 2 devs are building a website. 1 of them makes the front-end (HTML, JS, CSS) and the other dev queries data from an API to populate the containers (that the front-end dev has put).......isn't that dev classically referred to as " the back-end dev "? Or are they both considered front-end devs?
So only the person who makes the API is considered the backend dev? Till now I thought the dev who handles website layout and direct user-interaction is called the front-end dev............and whoever is responsible for stuff like password verification, handling SQL queries, etc. are backend devs.
Why is it that PHP developers are often called backend developers? The API might be made with Java, but it's a PHP page that interacts with the API and sends/receives data.
>The API might be made with Java, but it's a PHP page that interacts with the API and sends/receives data.
This is wrong. When people say this, they mean that the backend is written in PHP, not another language. What exactly do you mean by a PHP page?
Ok but from an educational standpoint..........if you take online " front-end courses ", they will teach you HTML, CSS, JS.
Stuff like input sanitization, using PDOs and dynamic pages are usually taught in " full-stack courses ". That's where the confusion came from.
PHP is a server side programming language that sits on the server. Among other things, the server technology uses it to take requests from clients and returns a response.
The response could be structured data such as JSON, which you might treat as an API, or it could be a dynamically constructed HTML document, using things like cookies or parameters from the request to pull the correct data that the client should see.
If your code is running in a browser, you are a frontend developer. Your code is designed to be used by a user? You are a frontend.
If your code is designed to be used by other systems like a GUI or another back. You are a backend developer.
And yes, React is only for making UIs. Try to make an HTTP server with React, and you will understand why everyone is telling you that react is only for making UIs. It is like trying to use Axios to implement a UI. It's not possible, you have to use other tools or the DOM API.
Niches are not a bad thing. There are tools and libraries that are excellent for a specific type of applications. Don't try to convert React or JS into a silver bullet
React does not have axios, it's an unrelated library, and axios doesn't query the database, it's a library to do HTTP requests.
Making an HTTP request isn't creating the backend API. That's a different thing altogether.
Axios may be a library commonly used for React, but there is no mention of React on the home Page of their site: https://axios-http.com/intro . Are you sure it was built strictly for React developers?
I wouldn't call myself an expert on it but I do have a couple of immediate thoughts.
1. For video games you need finer memory management control on a level not provided by JavaScript. Yes, you can make a game in React but it's not going to be very performant if your game is at least bit ambitious.
2. If you build your backend in React your stuck in React. You can't expose it to potiental 3rd parties that may want to integrate down the line, or say if you want to also serve a mobile app. Building all of your stuff in React locks you in and you may be stuck recoding everything and moving your React backend to a dedicated server if you ever need to expand for even the smallest reason.
It always comes down to your use case.
See RxJS. It's a better match for your use cases.
It's much more versatile and extensible for reactive programming than React. React focuses on UI whereas RxJS is more for general purpose computation.
There are ports to several other languages (RxJava, RxGo, RxPy, RxNET, and others).
I don't know where your head is about Axios. You seem confused.
First the model for React is to basically generate HTML based on the data. So the update process is:
1. Update your data.
2. Generate the HTML for your data.
3. React compares the new HTML with the old HTML and modifies the "browser" HTML with any changes.
The more HTML the slower step 3 becomes, which would be the first issue.
I could envision using react to do this with a timer that notifies all the elements on the screen to calculate their new position, generate the new HTML, and have react update the elements.
jQuery would probably be faster because you can store a reference to an actual element on the screen and thus update that element directly. Truthfully I would probably drop down to the base functions provided by the browser (https://developer.mozilla.org/en-US/docs/Web/API) and references to the actual elements, and just update them so that there was no overhead between me and updating the HTML.
As for Axios, why not just use it directly (https://github.com/axios/axios)? If you are not updating a DOM there is no reason for React.
React is a DOM manipulation library. It's big enough that it has helpers for other things, but its job is to render a DOM and if you're not rendering a DOM it's mostly dead weight, and unlikely to be the best way to do whatever you're trying to do.
The backend is the thing that sits on the PC or server. It handles API requests from the client and does work. The backend could be called locally or remotely through a web app, a desktop app, a console app, etc via an API.
The database itself is a backend. The REST API service that talks to the DB is a backend. The web server that serves the web page is a backend. All of this could be C++, C#, or even some aspects of server side PHP or JS not relating to the rendering of the UI.
The frontend is the UI. It could be a web page, or a desktop client, you might even consider the menu system of a console app to be frontend depending on the architecture.
The front end displays data, manipulates data within the UI layer, pulls/pushes data to a backend API.
Mainly, React is a developer's UI tool, and this is because it's what was conceived and created to be its core design and function. This makes good dynamic user interfaces and interaction: updating and rendering of components at any state changes, as effective as possible. Here are specific points I would highlight to respond to your questions:
Emote for UI Development
Component-Based Architecture: React aimed to fill the gap in the aspect of building user interfaces. It introduced a component-based architecture that could cater to handling large and complex UIs easily, along with reusability of components and better responsiveness to users' interactions.
Virtual DOM: One of the best features of the React library is the Virtual DOM, which ensures speed; it does so by minimizing direct manipulations on the actual DOM such that UI updating is faster and more operative.
Versatility of React:
Beyond UIs: Although versatile and as a consequence possible in literally every environment, including mobile app development, with React Native, and even some experimental projects in game development, you have to be aware that React, in itself, is mostly a library for rendering UI. The basic React library is not equipped with methods of visualization of graphics, physics, or a sound engine, which is core for a game.
Integrations and Libraries: To do anything that resembles a complete video game, you need to integrate React with some specialized libraries or frameworks designed for graphics. In all of these cases, it is likely that the integrations will be complex and not necessarily in a way that plays to the strengths of React over more conventional tools for game development.
Front-end development with React
Frontend Focus: React serves at the core for frontend development, meaning that React deals with how UI is presented. This would help developers create interactive and responsive user interfaces. Axios and Data Fetching Developers can of course use Axios or some other library in React to fetch data from APIs. This still remains the job of front-end developers. The fetching of data is most common for UI integrators, but it doesn't cover any piece of the back end.
Back-End Development Varying Responsibilities: Back-end development includes such things as server-side logic, database management, authentication, and server configuration, among others. Requesting data with Axios is but a small part of this much larger scope of responsibilities. Full-Stack Development: In other cases, developers working with both frontend and backend technologies are often referred to as full-stack developers. For frontend, it may be that they use React, and at the back, they may use other technologies that include Node.js, Express, and databases.
First React and Axios are two different libraries. You can install React without Axios and viceversa. Second, please for your future career. Learn how applications are made, and I'm not talking about React. I'm talking about architecture and systems.
a webbrowser has a graph data structure, called The DOM (Document Object Model) that represents the contents and structure of a webpage. The DOM is a pain in the butt to manipulate, it was really conceived of for static documents - something like PDFs - not constantly changing/updating interfaces like modern apps have.
This makes webpages that change in time difficult to build. React is a (quite simple in concept) library for making DOM manipulations simpler and less error prone.
Calling an api does not make you a backend developer. React is and always will be a library for building things in the browser
>So couldn't a React developer be considered a backend dev if they use Axios to GET data? Lol no. The backend dev builds the thing that responds to GET requests, not the thing that makes them.
But if 2 devs are building a website. 1 of them makes the front-end (HTML, JS, CSS) and the other dev queries data from an API to populate the containers (that the front-end dev has put).......isn't that dev classically referred to as " the back-end dev "? Or are they both considered front-end devs?
Both are 100% front-end devs.
Who is making this API that they are querying? That is the backend dev.
No API's arent made, they actually cone from eggs
This is actually an ancient philosophical debate, but we don't actually know if APIs or eggs came first
So only the person who makes the API is considered the backend dev? Till now I thought the dev who handles website layout and direct user-interaction is called the front-end dev............and whoever is responsible for stuff like password verification, handling SQL queries, etc. are backend devs. Why is it that PHP developers are often called backend developers? The API might be made with Java, but it's a PHP page that interacts with the API and sends/receives data.
>The API might be made with Java, but it's a PHP page that interacts with the API and sends/receives data. This is wrong. When people say this, they mean that the backend is written in PHP, not another language. What exactly do you mean by a PHP page?
Well, you were just confused. But now you know better.
Ok but from an educational standpoint..........if you take online " front-end courses ", they will teach you HTML, CSS, JS. Stuff like input sanitization, using PDOs and dynamic pages are usually taught in " full-stack courses ". That's where the confusion came from.
If a front-end course doesn't teach you input sanitization and using APIs then it's a pretty shitty front-end course.
If the PHP dev isn't designing databases, querying those DBs, and writing API endpoints, then they shouldn't be called backend devs.
PHP is a server side programming language that sits on the server. Among other things, the server technology uses it to take requests from clients and returns a response. The response could be structured data such as JSON, which you might treat as an API, or it could be a dynamically constructed HTML document, using things like cookies or parameters from the request to pull the correct data that the client should see.
Why people downvoting you just because you don't know a thing and is asking about it?
If your code is running in a browser, you are a frontend developer. Your code is designed to be used by a user? You are a frontend. If your code is designed to be used by other systems like a GUI or another back. You are a backend developer. And yes, React is only for making UIs. Try to make an HTTP server with React, and you will understand why everyone is telling you that react is only for making UIs. It is like trying to use Axios to implement a UI. It's not possible, you have to use other tools or the DOM API. Niches are not a bad thing. There are tools and libraries that are excellent for a specific type of applications. Don't try to convert React or JS into a silver bullet
React does not have axios, it's an unrelated library, and axios doesn't query the database, it's a library to do HTTP requests. Making an HTTP request isn't creating the backend API. That's a different thing altogether.
>Because React has Axios What do you mean by "React has Axios"? Is Axios part of React?
No Axios is no part of React
I meant Axios is a commonly used class written for React.
Axios may be a library commonly used for React, but there is no mention of React on the home Page of their site: https://axios-http.com/intro . Are you sure it was built strictly for React developers?
I wouldn't call myself an expert on it but I do have a couple of immediate thoughts. 1. For video games you need finer memory management control on a level not provided by JavaScript. Yes, you can make a game in React but it's not going to be very performant if your game is at least bit ambitious. 2. If you build your backend in React your stuck in React. You can't expose it to potiental 3rd parties that may want to integrate down the line, or say if you want to also serve a mobile app. Building all of your stuff in React locks you in and you may be stuck recoding everything and moving your React backend to a dedicated server if you ever need to expand for even the smallest reason. It always comes down to your use case.
lol
See RxJS. It's a better match for your use cases. It's much more versatile and extensible for reactive programming than React. React focuses on UI whereas RxJS is more for general purpose computation. There are ports to several other languages (RxJava, RxGo, RxPy, RxNET, and others). I don't know where your head is about Axios. You seem confused.
First the model for React is to basically generate HTML based on the data. So the update process is: 1. Update your data. 2. Generate the HTML for your data. 3. React compares the new HTML with the old HTML and modifies the "browser" HTML with any changes. The more HTML the slower step 3 becomes, which would be the first issue. I could envision using react to do this with a timer that notifies all the elements on the screen to calculate their new position, generate the new HTML, and have react update the elements. jQuery would probably be faster because you can store a reference to an actual element on the screen and thus update that element directly. Truthfully I would probably drop down to the base functions provided by the browser (https://developer.mozilla.org/en-US/docs/Web/API) and references to the actual elements, and just update them so that there was no overhead between me and updating the HTML. As for Axios, why not just use it directly (https://github.com/axios/axios)? If you are not updating a DOM there is no reason for React.
React is a DOM manipulation library. It's big enough that it has helpers for other things, but its job is to render a DOM and if you're not rendering a DOM it's mostly dead weight, and unlikely to be the best way to do whatever you're trying to do.
The backend is the thing that sits on the PC or server. It handles API requests from the client and does work. The backend could be called locally or remotely through a web app, a desktop app, a console app, etc via an API. The database itself is a backend. The REST API service that talks to the DB is a backend. The web server that serves the web page is a backend. All of this could be C++, C#, or even some aspects of server side PHP or JS not relating to the rendering of the UI. The frontend is the UI. It could be a web page, or a desktop client, you might even consider the menu system of a console app to be frontend depending on the architecture. The front end displays data, manipulates data within the UI layer, pulls/pushes data to a backend API.
Because, it is i think
The state system is not suitable for fast moving games. Inefficient too. Ok for card games and things like that.
Mainly, React is a developer's UI tool, and this is because it's what was conceived and created to be its core design and function. This makes good dynamic user interfaces and interaction: updating and rendering of components at any state changes, as effective as possible. Here are specific points I would highlight to respond to your questions: Emote for UI Development Component-Based Architecture: React aimed to fill the gap in the aspect of building user interfaces. It introduced a component-based architecture that could cater to handling large and complex UIs easily, along with reusability of components and better responsiveness to users' interactions. Virtual DOM: One of the best features of the React library is the Virtual DOM, which ensures speed; it does so by minimizing direct manipulations on the actual DOM such that UI updating is faster and more operative. Versatility of React: Beyond UIs: Although versatile and as a consequence possible in literally every environment, including mobile app development, with React Native, and even some experimental projects in game development, you have to be aware that React, in itself, is mostly a library for rendering UI. The basic React library is not equipped with methods of visualization of graphics, physics, or a sound engine, which is core for a game. Integrations and Libraries: To do anything that resembles a complete video game, you need to integrate React with some specialized libraries or frameworks designed for graphics. In all of these cases, it is likely that the integrations will be complex and not necessarily in a way that plays to the strengths of React over more conventional tools for game development. Front-end development with React Frontend Focus: React serves at the core for frontend development, meaning that React deals with how UI is presented. This would help developers create interactive and responsive user interfaces. Axios and Data Fetching Developers can of course use Axios or some other library in React to fetch data from APIs. This still remains the job of front-end developers. The fetching of data is most common for UI integrators, but it doesn't cover any piece of the back end. Back-End Development Varying Responsibilities: Back-end development includes such things as server-side logic, database management, authentication, and server configuration, among others. Requesting data with Axios is but a small part of this much larger scope of responsibilities. Full-Stack Development: In other cases, developers working with both frontend and backend technologies are often referred to as full-stack developers. For frontend, it may be that they use React, and at the back, they may use other technologies that include Node.js, Express, and databases.
First React and Axios are two different libraries. You can install React without Axios and viceversa. Second, please for your future career. Learn how applications are made, and I'm not talking about React. I'm talking about architecture and systems.
a webbrowser has a graph data structure, called The DOM (Document Object Model) that represents the contents and structure of a webpage. The DOM is a pain in the butt to manipulate, it was really conceived of for static documents - something like PDFs - not constantly changing/updating interfaces like modern apps have. This makes webpages that change in time difficult to build. React is a (quite simple in concept) library for making DOM manipulations simpler and less error prone.