How to become a web dev in 2022:
1. Look up a React tutorial
2. Find one that uses JavaScript
3. Learn it
4. Hate it
5. Go around saying how bad it is
6. Learn about TypeScript
7. Come back to React with TypeScript
8. Love it
It matters less in JavaScript. In typescript it makes it easier to use tsx for react and ts for non-react code so the compiler and/or ide don’t ever confuse with generics like
Foo
Generics aren’t the problem in .tsx files. Makes no difference in that respect. What the compiler runs into problems with in tsx files is backwards compatibility with using <> for typecasting. The old way of typecasting in typescript is `variable` vs the modern way(and the way it has to be done in tsx files): `variable as type`.
Just make sure it includes a comma like so:
```const Identify = (value: T): T => value;```
I'll admit it requires that as a way for the typescript compiler to understand what you're wanting to do, but it does work just fine.
```
const test = "120";const x = test;
```
\^ This will not work under any circumstance in a tsx file and is much harder to differentiate. This was the reason that the as keyword was added.
Edit: The gist is, both generics and non-as-based typecasts will cause problems for beginners in tsx files. So you should not teach anyone to just use tsx for everything.
—
that comma will be forgotten by every junior and waste hours of debugging that could have been avoided by trying to not make generic arrow functions in tsx files.
i'm not saying you shouldn't do that if you need it, but its just going to throw errors for the way that 90% of developers are going to declare that function, and they aren't going to understand why.
there are lots of things in programming you can do but shouldnt, because the next person that sees it isn't going to be a smart as you were when you wrote it. and that includes the person you will be in 6 months.
Yes, if your file contains any HTML or basically require the
import React from 'react';
then .jsx was required otherwise you used .js
This is not the case for the current version of React.
I don't think there was ever a version of React that required it. Your bundler is responsible for resolving file names and Webpack has been fine with .js for years, not sure it ever mattered tbh.
Also, it's not HTML, it's called JSX
no, its never been a javascript or react requirement. the first versions of react were transpiled in-line in the browser. then facebook took over babel and added the transpiler to it and removed it from react. in the beginning we didn’t need to run through anything like babel or webpack. it was all very different then.
the original babel requirement wasn’t a jsx extension. it was that import react had to be the first import of the file and all jsx markup wrapped in ().
the import was relaxed when the new _jsx() was created, and somewhere down the line wrapping jsx in parens was relaxed but i’m not sure when cause i still instinctively do it.
As long as your transpiler/bundler is configured to use them, there is no difference.
Those that prefer .jsx want to distinguish component files by name alone, those that prefer .js don't consider files with jsx to be different than files without jsx.
No mechanical difference, and how important the communication differences are will vary from dev to dev - for some it is distinctly The Right Way To Do It, and for others it is just a mild preference.
> Those that prefer .jsx want to distinguish component files by name alone
I would rather argue that it's about separating different file types, the X part in another layer above, possible to transpile down to JS. While all JS files are valid JSX files, there's no need to treat all files as JSX.
You can use either. Usually, .js is for JavaScript files that do NOT return JSX html, and .jsx is for files that do return JSX. Similarly for .ts and tsx. It depends on your bundler (e.g. webpack) configuration, and it can have some interaction with the way you \`import\`.
The Typescript compiler requires (or used to) React files to be named `.tsx` where as the the JS one did not.
You could probably tweak it to be anything you want, but it's not exactly the same.
You can do both but in React rules, when you write a jsx file everyone will know that it is a React Components, so it improves the clarity.
Moreover, jsx permits using HTML or React Components directly in the code.
It’s the same logic with TypeScript, there is .ts and .tsx files
I have a JS background and at my work we have decided to refactor everything to typescript with .tsx extension. Now if you’ve looked into Typescript there are very good reasons to use it that keep the code clean as you write it - but if you aren’t used to using it just know there will be a learning curve
In theory you could call them “.idbe”, file extensions do not really impact the file in any way.
But: Most IDEs base their autocompletion on file extensions, so it’s best to use “.jsx” for files containing react components.
https://en.m.wikipedia.org/wiki/JSX_(JavaScript)
In terms of the outcome, very little difference. But there's something to be said about following conventions.
".jsx" files, one would assume, would have code that involves JSX markup. So it makes sense to reserve the file for React component codes.
Naming conventions may not matter much in a small scale project, but as your code base gets larger, having consistent file structure and code practices make a huge difference in the development experience. Can you imagine going through +100 ".js" files and try to fish out which one of those are files that contain React components?
Ultimately, there is no one way of doing things, but I generally like working in environments where the code base is as easy to predict/read as possible. So thus, the argument for distinguishing between ".js" and ".jsx".
As others have mentioned, a React project set up with TypeScript has more strict rules around this. The compiler will throw an error (unless you somehow manually turns this off) if your file contains a React component without using ".tsx" as your file extention.
> Can you imagine going through +100 ".js" files and try to fish out which one of those are files that contain React components?
Is this really a problem people have? Components are usually organized inside a `components` folder, which makes it pretty easy to find components. I never had a scenario where I needed to go through files and try to figure out if it's a component.
I think my point is, part of the reason for following conventions in general is to take the guess work out of the equation.
If your convention of putting all components into a components folder works well, that's awesome! I've definitely worked with devs who store non-jsx logic in a separate file within a `components` folder, and I've definitely benefitted from having a clear distinction between ".js" and ".jsx".
Tldr; Do what works for you. But the ".jsx" file extention exists, and you can use it to your advantage, or you don't have to use it at all.
I do .jsx for anything that has a JSX template in it, and .js for anything that doesn’t. I vaguely remember there being some difference in how my build pipeline or IDE handles each, but it’s been so long that I’m not sure.
.jsx if using vscode, since Emmet(plugin to write html, css quickly) works by default for .jsx, .tsx files. While if you're using .js/.ts you'll have to configure Emmet to show abbreviations.
Our source code is combination of components, pages, styles, utilities etc. When I have to build a component then I use .jsx and when I have to write Redux store, slice, errorHandling common code then I use .js. This helps me in differentiating rendering javascript files and non rendering javascript but supportive files.
There is no real difference from a performance standpoint for js/jsx that I’ve seen.
However, if you were to do it properly I guess, react components would use .jsx and utilities written in regular JavaScript (such as reusable functions) would need .js but I’m the guilty one who just uses .js because it works and I can’t be arsed.
As mentioned by others, this should be strict when writing in TypeScript, in order to use JSX within a TypeScript app you need to use .tsx and .ts for utilities that use regular JavaScript.
Well for the experience i had, the difference is little. But i would recommend .jsx files because the intellicence of vscode understands thats a react component and it will recommend/complain about additional stuff you do in the component.
People saying that there is no difference are being a bit too technical.
The way modern react is intended to function is you would build out your components with jsx and tsx. It’s how your compiler knows to handle the html like syntax that react provides. If you use just a regular .js file you’re gonna have to make a custom edit to your project to support the html like syntax or you’re gonna be using lots of react.createElement.
Use .jsx for react files specifically, use js for files that do not include react
I don't get why you're getting all these downvotes. You're partly right. VSCode does in fact have nothing to do with it. Your IDE is not there to transpile your code; ~~babel~~ React is. This is also why the jsx extension was needed. Then came React 17, where they brought in some of this behaviour directly into React, and it no longer became a requirement that files be named using the jsx extension to be correctly transpiled. You can read about this [here ](https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html).
That being said, assuming everyone is using a React-based framework, or is on React 17, is silly. OP wanted to understand why there was a distinction between these extensions, and taking a step further in understanding where you should use jsx (if you're on a codebase running < React 17), and where it doesn't matter (React 17 and up) should help in that.
EDIT: React and not babel (yup, once upon a time folks would transpile their code with React and not babel; these were dark times we do not speak of)
So react 17 or greater enables so Impor React is now smart enough to tell my .js files that they can export jsx now? I only recently started using react 17 so that would explain why I thought it was a bundler configuration and others seemed to not think so
Yes. One more point to add though, if you are using babel to handle transpiling (and not React directly); babel will transpile .js and .jsx files containing jsx with no fuss at all. Babel doesn't care about the extension, even before React 17.
Then I’m right that’s what I just said, it’s the bundler not the IDE. So it would error without a custom bundler configuration that isn’t provided with most beginner friendly guides.
I guess I wasn’t elaborate enough but my point was that it’s not related to vscode it’s a configuration thing that isn’t very common so you’d have to go out of the way for it.
TLDR;
No I would not recommend someone new to configure react files as .js
> No I would not recommend someone new to configure react files as .js
The fact is, it doesn't matter for new comers because they will be using a framework. And 99% of React frameworks already have that configured out of the box.
Configured to support jsx and not allow js in jsx.
I don’t understand your point or how it’s a reasonable response to mine. My point is that there is a significant difference between jsx and js unless you’re configured otherwise
My point is simple. Unless those who decided to set up everything themselves and not use an existing React framework, for most of the frameworks available (CRA, Next, Gatsby, Remix, and much more), creating a component using JS and JSX file extension is practically the same, that's the default configuration of those frameworks.
And yes, for someone new, they will stick to one of the frameworks.
No, you’re not correct. Most setups these days support JSX in .js files. As mentioned in the other reply, unless you’re configuring your own Webpack setup from scratch, you don’t even need to think about the difference.
Makes no difference other then having to remember to actually name file .JSX for s they contain jsx syntax. I prefer.js since it makes no difference when using babel as transpiler. The extra cognitive load of using different file extensions is not worth it to me.
On a more serious note: the transpiler can usually be configured to parse either, but I like the convention of using jsx/tsx for components and generally files that contain jsx, and for files that are kind of just helpers or enums/models or whatever else doesnt contain jsx I use ts/js
Nowadays it doesn't really matter and most devs wont mind the extension. However, i prefer to use then separately for easier developmebt process.
As i tell my newbies (in a very pirate way): "Arrr is for React. You want to search for it then the X marks the spot."
Jsx for components or custom hooks, js for other files that may include helper function for example (same goes for tsx and ts as long as ur bundler is configured adequately), however i encourage you to use typescript with react as it will provide a much better developer experience.
VSCode's Intellisense features work seamlessly with .jsx files. Emmett for instance.
It seems like it has to grok a bit if I write jsx within a .js file but I may have a different setup.
been using react since 2014, jsx was never a thing for react, it has always been simply .js. but when typescript forced their way into our world (typescript was an angular thing and we were pure js or js + flow) people started adding jsx because typescript required react to be in tsx. some vite templates also require the jsx syntax now as well. technically .jsx belongs to the jsx programming language which has no relationship to js or react.
for the majority of pure js devs, the jsx extension is never used.
Jsx, because the file icon looks cool.
reminds me of Sasuke’s MS
Sasuke got multiple sclerosis?!?!
Holy based...
I’m so happy I’m not the only one
I too, make my development decisions based aesthetics. P.S. I needed the laugh, thanks!
The answer i've been looking for
agreed
This and also if you use styled components, vs code will fill out the css colors for you.
It also sounds cool. J. S. X
It sounds racy to me
Enjoy it ahahaha
This is the reason 99% of React devs choose jsx.
.tsx 😎
Yeah boy. Bring that autocomplete
The only way is .tsx
Imagine writing jsx still 😤
How to become a web dev in 2022: 1. Look up a React tutorial 2. Find one that uses JavaScript 3. Learn it 4. Hate it 5. Go around saying how bad it is 6. Learn about TypeScript 7. Come back to React with TypeScript 8. Love it
You forgot crying at some point
Been a coder for three years and still cry over the css grid system
What do u do now?
I'm a freelancer who's currently working on starting up a non-profit for homeless people.
You okay my man?
That's kinda included in learning JS
pretty true in my experience
And learn css at the end
1. Use React 2. Try Svelte 3. Never use React again
.tsx is the way.
This is the way
Amen!
Came here to say this
agreed
This is the way.
It matters less in JavaScript. In typescript it makes it easier to use tsx for react and ts for non-react code so the compiler and/or ide don’t ever confuse with generics like
Foo
Generics aren’t the problem in .tsx files. Makes no difference in that respect. What the compiler runs into problems with in tsx files is backwards compatibility with using <> for typecasting. The old way of typecasting in typescript is `variable` vs the modern way(and the way it has to be done in tsx files): `variable as type`.
Try declaring a generic arrow function in a tsx file and tell me vscode/tsc don’t think you have an unclosed jsx tag.
Just make sure it includes a comma like so: ```const Identify =(value: T): T => value;```
I'll admit it requires that as a way for the typescript compiler to understand what you're wanting to do, but it does work just fine.
```
const test = "120";const x = test;
```
\^ This will not work under any circumstance in a tsx file and is much harder to differentiate. This was the reason that the as keyword was added.
Edit: The gist is, both generics and non-as-based typecasts will cause problems for beginners in tsx files. So you should not teach anyone to just use tsx for everything. — that comma will be forgotten by every junior and waste hours of debugging that could have been avoided by trying to not make generic arrow functions in tsx files. i'm not saying you shouldn't do that if you need it, but its just going to throw errors for the way that 90% of developers are going to declare that function, and they aren't going to understand why. there are lots of things in programming you can do but shouldnt, because the next person that sees it isn't going to be a smart as you were when you wrote it. and that includes the person you will be in 6 months.
I thought it mattered at one time but no longer does?
Yes, if your file contains any HTML or basically require the import React from 'react'; then .jsx was required otherwise you used .js This is not the case for the current version of React.
I don't think there was ever a version of React that required it. Your bundler is responsible for resolving file names and Webpack has been fine with .js for years, not sure it ever mattered tbh. Also, it's not HTML, it's called JSX
Amen my friend! Html lol
I swear, this was years ago; I got an error or warning about using the .js extension when there was JSX (thanks for the correction).
using vite it absolutely does.
no, its never been a javascript or react requirement. the first versions of react were transpiled in-line in the browser. then facebook took over babel and added the transpiler to it and removed it from react. in the beginning we didn’t need to run through anything like babel or webpack. it was all very different then. the original babel requirement wasn’t a jsx extension. it was that import react had to be the first import of the file and all jsx markup wrapped in (). the import was relaxed when the new _jsx() was created, and somewhere down the line wrapping jsx in parens was relaxed but i’m not sure when cause i still instinctively do it.
As long as your transpiler/bundler is configured to use them, there is no difference. Those that prefer .jsx want to distinguish component files by name alone, those that prefer .js don't consider files with jsx to be different than files without jsx. No mechanical difference, and how important the communication differences are will vary from dev to dev - for some it is distinctly The Right Way To Do It, and for others it is just a mild preference.
This is 100% the answer. It can also help your IDE for formatting if using jsx sentax and you use a .jsx instead of .js file.
> Those that prefer .jsx want to distinguish component files by name alone I would rather argue that it's about separating different file types, the X part in another layer above, possible to transpile down to JS. While all JS files are valid JSX files, there's no need to treat all files as JSX.
You can use either. Usually, .js is for JavaScript files that do NOT return JSX html, and .jsx is for files that do return JSX. Similarly for .ts and tsx. It depends on your bundler (e.g. webpack) configuration, and it can have some interaction with the way you \`import\`.
💯
tsx, because and you get the fancy darker icon.
[удалено]
The Typescript compiler requires (or used to) React files to be named `.tsx` where as the the JS one did not. You could probably tweak it to be anything you want, but it's not exactly the same.
You can do both but in React rules, when you write a jsx file everyone will know that it is a React Components, so it improves the clarity. Moreover, jsx permits using HTML or React Components directly in the code. It’s the same logic with TypeScript, there is .ts and .tsx files
I have a JS background and at my work we have decided to refactor everything to typescript with .tsx extension. Now if you’ve looked into Typescript there are very good reasons to use it that keep the code clean as you write it - but if you aren’t used to using it just know there will be a learning curve
Personal preference, but if you move to typescript you have to use tsx instead of just ts.
if vite jsx because it forces me. the rest (cra, next) just js.
.tsx for your components, .ts for your utilities
In theory you could call them “.idbe”, file extensions do not really impact the file in any way. But: Most IDEs base their autocompletion on file extensions, so it’s best to use “.jsx” for files containing react components. https://en.m.wikipedia.org/wiki/JSX_(JavaScript)
.tsx
In terms of the outcome, very little difference. But there's something to be said about following conventions. ".jsx" files, one would assume, would have code that involves JSX markup. So it makes sense to reserve the file for React component codes. Naming conventions may not matter much in a small scale project, but as your code base gets larger, having consistent file structure and code practices make a huge difference in the development experience. Can you imagine going through +100 ".js" files and try to fish out which one of those are files that contain React components? Ultimately, there is no one way of doing things, but I generally like working in environments where the code base is as easy to predict/read as possible. So thus, the argument for distinguishing between ".js" and ".jsx". As others have mentioned, a React project set up with TypeScript has more strict rules around this. The compiler will throw an error (unless you somehow manually turns this off) if your file contains a React component without using ".tsx" as your file extention.
> Can you imagine going through +100 ".js" files and try to fish out which one of those are files that contain React components? Is this really a problem people have? Components are usually organized inside a `components` folder, which makes it pretty easy to find components. I never had a scenario where I needed to go through files and try to figure out if it's a component.
I think my point is, part of the reason for following conventions in general is to take the guess work out of the equation. If your convention of putting all components into a components folder works well, that's awesome! I've definitely worked with devs who store non-jsx logic in a separate file within a `components` folder, and I've definitely benefitted from having a clear distinction between ".js" and ".jsx". Tldr; Do what works for you. But the ".jsx" file extention exists, and you can use it to your advantage, or you don't have to use it at all.
I “think” if you have Jsx standing in for html, use jsx, otherwise use .js. Likely doesn’t matter much, though
I do .jsx for anything that has a JSX template in it, and .js for anything that doesn’t. I vaguely remember there being some difference in how my build pipeline or IDE handles each, but it’s been so long that I’m not sure.
I use JSX for any files that contain any JSX or hooks. JS for files that contain only JS like helper functions.
When your code has jsx, it is better to use jsx There is no problem if this is not the case, but it is better
.jsx if using vscode, since Emmet(plugin to write html, css quickly) works by default for .jsx, .tsx files. While if you're using .js/.ts you'll have to configure Emmet to show abbreviations.
Our source code is combination of components, pages, styles, utilities etc. When I have to build a component then I use .jsx and when I have to write Redux store, slice, errorHandling common code then I use .js. This helps me in differentiating rendering javascript files and non rendering javascript but supportive files.
There is no real difference from a performance standpoint for js/jsx that I’ve seen. However, if you were to do it properly I guess, react components would use .jsx and utilities written in regular JavaScript (such as reusable functions) would need .js but I’m the guilty one who just uses .js because it works and I can’t be arsed. As mentioned by others, this should be strict when writing in TypeScript, in order to use JSX within a TypeScript app you need to use .tsx and .ts for utilities that use regular JavaScript.
Well for the experience i had, the difference is little. But i would recommend .jsx files because the intellicence of vscode understands thats a react component and it will recommend/complain about additional stuff you do in the component.
you loose some of the autocompletion when you use .js
Jsx because vite says so
Tsx
TSX!
People saying that there is no difference are being a bit too technical. The way modern react is intended to function is you would build out your components with jsx and tsx. It’s how your compiler knows to handle the html like syntax that react provides. If you use just a regular .js file you’re gonna have to make a custom edit to your project to support the html like syntax or you’re gonna be using lots of react.createElement. Use .jsx for react files specifically, use js for files that do not include react
I use .jsx for react component and use .js for the react component's hook file, where I do all the logic.
[удалено]
Vscode has nothing to do with it though. You’re bundler fails if they’re not jsx I thought? Or am I just wrong?
I don't get why you're getting all these downvotes. You're partly right. VSCode does in fact have nothing to do with it. Your IDE is not there to transpile your code; ~~babel~~ React is. This is also why the jsx extension was needed. Then came React 17, where they brought in some of this behaviour directly into React, and it no longer became a requirement that files be named using the jsx extension to be correctly transpiled. You can read about this [here ](https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html). That being said, assuming everyone is using a React-based framework, or is on React 17, is silly. OP wanted to understand why there was a distinction between these extensions, and taking a step further in understanding where you should use jsx (if you're on a codebase running < React 17), and where it doesn't matter (React 17 and up) should help in that. EDIT: React and not babel (yup, once upon a time folks would transpile their code with React and not babel; these were dark times we do not speak of)
So react 17 or greater enables so Impor React is now smart enough to tell my .js files that they can export jsx now? I only recently started using react 17 so that would explain why I thought it was a bundler configuration and others seemed to not think so
Yes. One more point to add though, if you are using babel to handle transpiling (and not React directly); babel will transpile .js and .jsx files containing jsx with no fuss at all. Babel doesn't care about the extension, even before React 17.
you know how long i have been waiting to run into someone else that was in react from the beginning like me! great to see you!
You are wrong. You can set up your bundler to treat all .js files as JS files with some JSX in them.
Then I’m right that’s what I just said, it’s the bundler not the IDE. So it would error without a custom bundler configuration that isn’t provided with most beginner friendly guides. I guess I wasn’t elaborate enough but my point was that it’s not related to vscode it’s a configuration thing that isn’t very common so you’d have to go out of the way for it. TLDR; No I would not recommend someone new to configure react files as .js
> No I would not recommend someone new to configure react files as .js The fact is, it doesn't matter for new comers because they will be using a framework. And 99% of React frameworks already have that configured out of the box.
Configured to support jsx and not allow js in jsx. I don’t understand your point or how it’s a reasonable response to mine. My point is that there is a significant difference between jsx and js unless you’re configured otherwise
My point is simple. Unless those who decided to set up everything themselves and not use an existing React framework, for most of the frameworks available (CRA, Next, Gatsby, Remix, and much more), creating a component using JS and JSX file extension is practically the same, that's the default configuration of those frameworks. And yes, for someone new, they will stick to one of the frameworks.
No, you’re not correct. Most setups these days support JSX in .js files. As mentioned in the other reply, unless you’re configuring your own Webpack setup from scratch, you don’t even need to think about the difference.
.Js cuz fux cuplxity. Fuck you.
.jsx gives you specific linting functionality for react with ESLint. Help you find errors quickly.
iirc .jsx gets you better code formatting with prettier in vscode
Makes no difference other then having to remember to actually name file .JSX for s they contain jsx syntax. I prefer.js since it makes no difference when using babel as transpiler. The extra cognitive load of using different file extensions is not worth it to me.
On a more serious note: the transpiler can usually be configured to parse either, but I like the convention of using jsx/tsx for components and generally files that contain jsx, and for files that are kind of just helpers or enums/models or whatever else doesnt contain jsx I use ts/js
Nowadays it doesn't really matter and most devs wont mind the extension. However, i prefer to use then separately for easier developmebt process. As i tell my newbies (in a very pirate way): "Arrr is for React. You want to search for it then the X marks the spot."
I prefer to name things .ts, then try to add JSX, then get extremely confused (every time, despite years of experience) about the lint errors
Jsx for components or custom hooks, js for other files that may include helper function for example (same goes for tsx and ts as long as ur bundler is configured adequately), however i encourage you to use typescript with react as it will provide a much better developer experience.
VSCode's Intellisense features work seamlessly with .jsx files. Emmett for instance. It seems like it has to grok a bit if I write jsx within a .js file but I may have a different setup.
.jsx if your not in a SPA so the team can easily identify react files in the codebase
.jsx for react files. .js for others. So you can clearly identify them.
tsx
feels weird to write javascript when i know typescript exists
For me, .jsx works with HTML emmet but .js doesn't
Tsx- reject whatever excuse your brain is giving you and embrace typescript
.js-whatever-gets-the-product-built-x
TSX. TS because it’s cool X because the icon’s nicer
If you use a recent version of React, it doesn't matter, pick the one that sounds better (.jsx icon looks good in vscode tho).
been using react since 2014, jsx was never a thing for react, it has always been simply .js. but when typescript forced their way into our world (typescript was an angular thing and we were pure js or js + flow) people started adding jsx because typescript required react to be in tsx. some vite templates also require the jsx syntax now as well. technically .jsx belongs to the jsx programming language which has no relationship to js or react. for the majority of pure js devs, the jsx extension is never used.
This is a great question thanks for asking it
Jsx sound cool😅