6 ms·

You’re right that none of these alternative ways of writing JSX syntax are better than JSX. But I think you miss why people don’t like JSX in the first place;

You’re right that none of these alternative ways of writing JSX syntax are better than JSX. But I think you miss why people don’t like JSX in the first place; Having to compile your javascript sucks. If your framework requires me to have a build system in place just to write some javascript, I’m either not going to use it or, if forced, I’ll find whatever way I need to to get the code written without having to stand up a giant build system. Naturally, the true solution for people like me is to use Vue or Angular or another library that’s not as intrusive as React. But sometimes we’re forced, so we use that terrible createElement syntax. And come away disliking React even more.

chosenbreed37 8y ago
Having to set up a build system is a bit of a pain. The value I get from being able to break down the UI in components and with the possibility of testing them independently makes it worthwhile for me.
- markmark 8y ago
  I think people might just work on projects smaller than I'm used to. I set up a build on day one of a project and then just it for the next six months or year or whatever, so I really never see it as a pain point. As you say, well worth it for all of the benefits. Although frankly if I was doing lots of small projects I'm sure I'd have one of the many starter projects set up how I like it and it would just be running a script once.
dave7 8y ago
Setting up a build system is not required, React with JSX can be inlined using plain old <script> tags just fine I believe. <head> <script src="https://cdnjs.cloudflare.com/ajax/libs/react/0.14.6/react.js"></script> <script src="https://cdnjs.cloudflare.com/ajax/libs/react/0.14.6/react-dom.js"></script> <script src="https://cdnjs.cloudflare.com/ajax/libs/babel-core/5.8.23/browser.js"></script> </head> <body> <div id="app"></div> <script type="text/babel"> // React with JSX goes here </script> </body> It it is less performant than compiled setup, of course.
- acemarke 8y ago
  The React docs point to a much more recent example of this setup: https://raw.githubusercontent.com/reactjs/reactjs.org/master/static/html/single-file-example.html https://raw.githubusercontent.com/reactjs/reactjs.org/master... And have actual instructions here: https://reactjs.org/docs/add-react-to-a-website.html https://reactjs.org/docs/add-react-to-a-website.html
bacro 8y ago
>Having to compile your javascript sucks. That's why I don't like typescript :) Also because typescript makes things way less understandable than without type annotations
- mixedCase 8y ago
  >makes things way less understandable than without type annotations Strange proposition. No dev I know who has professionally worked with both would claim the same, even the skeptics long term ended up grokking types as a way to make it easier to understand the intent behind a piece of code, even when they prefer JS for writing, never for reading other people's code. How long have you worked with each? What editor tools have you used for TS? I'm really curious about your experience.
  - bacro 8y ago
    I was investigating typescript to use in a react native project and while checking some of the definitions contained in a package in Visual Studio Code (I believe it was react-navigation) the way they were presented was so confusing that I aborted immediately going with typescript. It was a function that returned a function that accepted as a parameter another function and the extra syntax was really taxing to my brain to fully understand what the function was all about. When I removed the extra syntax it was way clearer for me to understand it. Sometimes, pure javascript with a good variable naming is better. Sure, I could use some of static type checking to avoid some bugs but there weren't many bugs that I remember when I was doing the app so I think it didn't impact me too much. Also I am a solo developer in my company, I don't work in a team so it's not a big problem here.
    - com2kid 8y ago
      RN and Typescript is interesting. The getting started, learning curve, and "wtf is happening here" curve is rather high. Especially once you add in Redux and React Navigation. It doesn't help that all of the "getting started with RN and TS!" assume a decent understanding of TS. I eventually got TSX working, but yeah, figuring out what you need to declare to make it all work is not easy. Redux having 5 major ways (or whatever it is) of using it didn't help any. I use the shorthand form of mapDispatchToProps in my connect call, which none of the "TS in Redux" tutorials seem to use. (Why not? It is so much easier and shorter!) I eventually gave up on typing Redux, IMHO the last thing Redux needs is more boilerplate! I rarely have type problems in my Redux code anyway. I probably understand enough to do it now (or maybe not, haven't investigated what typing redux-thunk looks like), but I'm going for "less bugs" not ideological purity in my code. The tl;dr is that you have to declare an interface for your props, an interface for your state, and your props interface has to include a NavigationScreenProp which I honestly declared as navigation: NavigationScreenProp<any>; because I have better things to do in life than spend yet more time trying to figure out how to type something I never actually use. (state is in Redux, so the NavigationScreenProp is of very little use to me) All that said, the one time learning curve was worth it. Typescript definitions can get super complicated though, my 90% use case is preventing typos and allowing for refactoring, so I only type objects I pass around as interfaces and I type functions that have been the source of bugs. Mostly anything that comes from my backend DB I want typed end to end. The majority of my REST endpoints use Typescript to pull from the DB so I just share interfaces across my backend and frontend. It has been worth the hassle just for that.
nicoburns 8y ago
Using Angular or Vue without a module system sounds awful. How do you organise your code? Manual namespacing on the global object? So I'm coming from a perspective where I will definitely be compiling my JavaScript regardless, and adding JSX doesn't make much difference complexity wise (and provides a much nicer syntax).
- Bahamut 8y ago
  Can't speak for Vue, but Angular has its own module system in addition to ES imports, which does give a gain when it comes to testing. There is one benefit to Angular's templates that is pretty nice due to its use of TypeScript - you get intellisense in editors on your templates.
  - TomMarius 8y ago
    JSX is typed, you get all the benefits of intellisense and type safety. It even supports generics.
- bwindels 8y ago
  ES modules with relative URLs have shipped in browsers, and when import maps [1] land, it could become viable to not bundle or transpile for local development and only do so for production builds. 1: https://github.com/WICG/import-maps https://github.com/WICG/import-maps
com2kid 8y ago
I objected to it at first. Then I learned how much nicer Javascript is with Babel. No worrying about browser compatibility, Babel just makes it all work. If I see some stage 3 proposal that I want to use, no problem, drop it in. When I wanted to start moving over to Typescript, one line in Babel and I could start writing .ts files. While learning what in the world was going in with regards to Babel was a bit of a painful start, now that I have it up and running, life is good.

chosenbreed37 8y ago

Having to set up a build system is a bit of a pain. The value I get from being able to break down the UI in components and with the possibility of testing them independently makes it worthwhile for me.

markmark 8y ago
I think people might just work on projects smaller than I'm used to. I set up a build on day one of a project and then just it for the next six months or year or whatever, so I really never see it as a pain point. As you say, well worth it for all of the benefits. Although frankly if I was doing lots of small projects I'm sure I'd have one of the many starter projects set up how I like it and it would just be running a script once.

dave7 8y ago

Setting up a build system is not required, React with JSX can be inlined using plain old <script> tags just fine I believe. <head> <script src="https://cdnjs.cloudflare.com/ajax/libs/react/0.14.6/react.js"></script> <script src="https://cdnjs.cloudflare.com/ajax/libs/react/0.14.6/react-dom.js"></script> <script src="https://cdnjs.cloudflare.com/ajax/libs/babel-core/5.8.23/browser.js"></script> </head> <body> <div id="app"></div> <script type="text/babel"> // React with JSX goes here </script> </body> It it is less performant than compiled setup, of course.

acemarke 8y ago
The React docs point to a much more recent example of this setup: https://raw.githubusercontent.com/reactjs/reactjs.org/master/static/html/single-file-example.html https://raw.githubusercontent.com/reactjs/reactjs.org/master... And have actual instructions here: https://reactjs.org/docs/add-react-to-a-website.html https://reactjs.org/docs/add-react-to-a-website.html

bacro 8y ago

>Having to compile your javascript sucks. That's why I don't like typescript :) Also because typescript makes things way less understandable than without type annotations

mixedCase 8y ago
>makes things way less understandable than without type annotations Strange proposition. No dev I know who has professionally worked with both would claim the same, even the skeptics long term ended up grokking types as a way to make it easier to understand the intent behind a piece of code, even when they prefer JS for writing, never for reading other people's code. How long have you worked with each? What editor tools have you used for TS? I'm really curious about your experience.
- bacro 8y ago
  I was investigating typescript to use in a react native project and while checking some of the definitions contained in a package in Visual Studio Code (I believe it was react-navigation) the way they were presented was so confusing that I aborted immediately going with typescript. It was a function that returned a function that accepted as a parameter another function and the extra syntax was really taxing to my brain to fully understand what the function was all about. When I removed the extra syntax it was way clearer for me to understand it. Sometimes, pure javascript with a good variable naming is better. Sure, I could use some of static type checking to avoid some bugs but there weren't many bugs that I remember when I was doing the app so I think it didn't impact me too much. Also I am a solo developer in my company, I don't work in a team so it's not a big problem here.
  - com2kid 8y ago
    RN and Typescript is interesting. The getting started, learning curve, and "wtf is happening here" curve is rather high. Especially once you add in Redux and React Navigation. It doesn't help that all of the "getting started with RN and TS!" assume a decent understanding of TS. I eventually got TSX working, but yeah, figuring out what you need to declare to make it all work is not easy. Redux having 5 major ways (or whatever it is) of using it didn't help any. I use the shorthand form of mapDispatchToProps in my connect call, which none of the "TS in Redux" tutorials seem to use. (Why not? It is so much easier and shorter!) I eventually gave up on typing Redux, IMHO the last thing Redux needs is more boilerplate! I rarely have type problems in my Redux code anyway. I probably understand enough to do it now (or maybe not, haven't investigated what typing redux-thunk looks like), but I'm going for "less bugs" not ideological purity in my code. The tl;dr is that you have to declare an interface for your props, an interface for your state, and your props interface has to include a NavigationScreenProp which I honestly declared as navigation: NavigationScreenProp<any>; because I have better things to do in life than spend yet more time trying to figure out how to type something I never actually use. (state is in Redux, so the NavigationScreenProp is of very little use to me) All that said, the one time learning curve was worth it. Typescript definitions can get super complicated though, my 90% use case is preventing typos and allowing for refactoring, so I only type objects I pass around as interfaces and I type functions that have been the source of bugs. Mostly anything that comes from my backend DB I want typed end to end. The majority of my REST endpoints use Typescript to pull from the DB so I just share interfaces across my backend and frontend. It has been worth the hassle just for that.

nicoburns 8y ago

Using Angular or Vue without a module system sounds awful. How do you organise your code? Manual namespacing on the global object? So I'm coming from a perspective where I will definitely be compiling my JavaScript regardless, and adding JSX doesn't make much difference complexity wise (and provides a much nicer syntax).

Bahamut 8y ago
Can't speak for Vue, but Angular has its own module system in addition to ES imports, which does give a gain when it comes to testing. There is one benefit to Angular's templates that is pretty nice due to its use of TypeScript - you get intellisense in editors on your templates.
- TomMarius 8y ago
  JSX is typed, you get all the benefits of intellisense and type safety. It even supports generics.
bwindels 8y ago
ES modules with relative URLs have shipped in browsers, and when import maps [1] land, it could become viable to not bundle or transpile for local development and only do so for production builds. 1: https://github.com/WICG/import-maps https://github.com/WICG/import-maps

com2kid 8y ago

I objected to it at first. Then I learned how much nicer Javascript is with Babel. No worrying about browser compatibility, Babel just makes it all work. If I see some stage 3 proposal that I want to use, no problem, drop it in. When I wanted to start moving over to Typescript, one line in Babel and I could start writing .ts files. While learning what in the world was going in with regards to Babel was a bit of a painful start, now that I have it up and running, life is good.