8 ms·

Speaking as the person who implemented JSX support for TypeScript, I question the premise! JSX support (and implementation of React semantics for typechecking t

Speaking as the person who implemented JSX support for TypeScript, I question the premise! JSX support (and implementation of React semantics for typechecking that JSX) was a very popular feature request. I can tell you just from how quickly people notice when something JSX-related changes in the nightly build that there are a lot of people using TypeScript with React. Also, since this seem to be a popular misconception, JSX support in TypeScript is not wedded to React. The default JSX target is React, but you can set JSX to "preserve" and get very vanilla semantics as well as keeping the JSX in the emitted code so you can pipe it through a custom transformer. The question also points out that the reader is looking at lots of tutorials -- it should be unsurprising that these don't use TypeScript as it's an optional thing that would only increase the concept count in an educational setting where you want to only show the thing you're trying to explain. If you need a notable React + TypeScript project, see the Delve team's write-up of their use of TypeScript - https://medium.com/@delveeng/why-we-love-typescript-bec2df88d6c2#.uvwtenu64 https://medium.com/@delveeng/why-we-love-typescript-bec2df88...

scrollaway 10y ago
I'd like to offtopicly chime in and thank you :) Javascript is a language and an ecosystem I really disliked until React and TypeScript came around and changed everything. We're making extensive use of JSX in our React app (https://github.com/hearthsim/joust https://github.com/hearthsim/joust / https://hsreplay.net/replay/ZXKe5VoqTzknRJNcPdTnYa https://hsreplay.net/replay/ZXKe5VoqTzknRJNcPdTnYa) and it's really wonderful to both read and write.
afarrell 10y ago
> It would only increase the concept count in an educational setting where you want to only show the thing you're trying to explain. As someone who has written a long tutorial, this makes total sense. When I was first looking at the react ecosystem, it was very frustrating because of the high cost of picking pieces to work together. I really liked http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial.html http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial... because it showed how to use mocha in the context of we webpack and react and redux. It would be nice to see more tutorials for curated toolchains, but they take a lot of work.
- emodendroket 10y ago
  This is basically my frustration with the whole trend toward smaller pieces over big monoliths. I don't need a best-in-class every tiny little thing; I just want reasonable tools I can expect to work together well.
  - wmil 10y ago
    Indeed. This is actually the point of DHH's much maligned "Rails is Omakase" article.
    - taeric 10y ago
      Why was that article maligned? Seemed pretty solid to me.
  - drostie 10y ago
    The other nice thing is that bigger monoliths often (not always) make opinionated decisions. This is usually a good thing. In my work I deal with a legacy system with an ExtJS GUI. The two ways that ExtJS fails to be opinionated are perpetual pain points for me and my team! One is: every component has a million optional configurations, not to mention all of the events you can listen on. For the most part this is great, but there was never any systematic separation for "here are the absolutely-required things, there are the things which are optional but must be configured together, and over yonder are the things which are totally optional." Then you could require that the required-configs were, say, statically known when you were deriving a concrete class from an abstract one. Instead ExtJS wanted to accept doing all of this stuff at runtime, so because it failed to take a strong stand on its required configs, when you inevitably forget to configure some of them, you get an error puked out from somewhere very deep in the framework, where the call-stack and error messages show nothing related to your class at all, just "TypeError: SomethingYouNeverCaredAbout is null." It would have all been saved if `Ext.define` looked for some "abstractProperties" array, and made sure that every new `Ext.define` either set abstract properties or propagated them, finally checking that whichever ones are still present in the `Ext.create` call are filled in. Simple descriptive error messages are then available when you forget a required config. The other way ExtJS violates the principle is... God help you if you ever have to figure out how the underlying form submits and grid reloads actually work. You'd think with something so critical, it would be clear... it's not. "My grid refreshes automatically when the underlying store loads. Great! The underlying store can be loaded or reloaded with the .load() method, which accepts a callback. Wonderful!" It starts off very promising. But then you dig deeper and find that the .load() method packages the params and the callback into some object and then calls some .read() method which doesn't exist on the class you're looking at (inheritance! go up to the superclass!). Once you've traced that down the actual .read() bounces to some .doAction() which repackages these into some `Operation{type: 'readAction'}` or whatever... and then this gets handed up to some Proxy object which then stores it in some meaningless array, because of course these things get batched together... if you're not sick yet you find out that the Proxy needs to push the stuff to some Reader and Writer, just in case you wanted to communicate with the server via XML instead of JSON, or wanted to store the resulting array under a key not named 'results'. But you don't want to do any of this because the query finally gets XMLHttpRequested somehow (God knows how) to some `router.php` which we stole from IBM[1] a long time ago, which finally took a stand, "I will accept these two inputs, send them to the backend this way, and emit one of two corresponding outputs." (Except for that then you open that and it contains code for some sort of `doAroundCalls` because apparently the original author[2] decided to vacillate on what they'd accept, trying to also allow you to bookend one RPC service with two other RPC services, which never happens because Ext.JS never does it!) It gets a little more complicated because there is one rather significant bug which nobody has ever fixed in IBM's router.php, which is that formHandler services get the $_POST params (an associative array) as their first argument whereas XMLHttpRequests get the `json_decode($HTTP_RAW_POST_DATA)` (a StdClass object) as their first argument, so there's no interoperability on the frontend or the backend. Happy debugging, you. It's all one big mess. You begin to wish ExtJS had done what they eventually ended up doing[3], and just told people, "here is how you're going to do this thing. We have a Java router, a PHP router, here is how you set up your backend on these platforms..." That would have been very bold since ExtJS was originally just a set of helper classes to help automate GUI stuff with YUI, so I understand that the history made them feel a bit shaky about doing that, but... I really don't value that there's 10 layers of abstraction just in case I want to transmit the same stuff over-the-wire in XML rather than JSON. If any developers of toolkits are reading this: please, please consider very firm protocols: "here is what you're going to send me, and here's what I'm going to respond with." Because, half of programming anyways is translating outputs to inputs; we all know how to write the adapters which connect the two. Please make your life really simple by not supporting a million different ways to do the thing. I promise, you're also making my life simple because even though I will grumble about spending a half-day writing that adapter, I will then save untold dozens of half-days because the overall architecture is modularized, "oh there's a bug in the adapter, my bad, but it's only a 5 minute fix." My communication with you must pass through a gateway; please limit me to only a very small choice of inputs which you are going to tolerate, and break very loudly at the gateway when I forget some of those. It's far better than having a nigh-undebuggable error somewhere in the middle of your framework code that I never want to read. [1] http://www.ibm.com/developerworks/library/wa-aj-streamline/ http://www.ibm.com/developerworks/library/wa-aj-streamline/ [2] This could be Dan Dallala of Microsoft? His Gist appears to be an older version of the file and is one of the top results when googling strings out of the source file... [3] It's not complete as to how the backend should be set up, but at least there is now a documented interface for this Ext.Direct communication. https://docs.sencha.com/extjs/6.0.1/guides/backend_connectors/direct/specification.html https://docs.sencha.com/extjs/6.0.1/guides/backend_connector...
tomduncalf 10y ago
I mentioned it in my comment below, but as it is relevant, I am going to plug my Typescript 1.9 + React project set up guide here: http://blog.tomduncalf.com/posts/setting-up-typescript-and-react/ http://blog.tomduncalf.com/posts/setting-up-typescript-and-r...
gulbanana 10y ago
i'm one of the people whose team has benefited greatly from your work on .tsx, thanks for the great tool! i suspect a great many typescript users are not open source.
- nojvek 10y ago
  tsx refactoring and type checking is mind blowingly awesome. This feature alone makes me choose tsx over angular templates. angular templates are very loose and no property way of type checking it. I've seen some terrible mistakes in angular templates when refactoring.
k__ 10y ago
> TypeScript is not wedded to React Practially not, but it's a bit of a hassle. either you leave the JSX be and parse it with Babel or you need some wrappers for you VDOM lib, because tsc assumes a namespace, while most not-React-vdom libs just deliver a function out of the box.
- bradleyayers 10y ago
  I'm fixing that in https://github.com/Microsoft/TypeScript/pull/11267 https://github.com/Microsoft/TypeScript/pull/11267
petilon 10y ago
> JSX support in TypeScript is not wedded to React. Agreed. Here's an example of JSX in TypeScript that has nothing to do with React. UI Builder is a templating library, just like Mustache, but much better because you get full intellisense and compile-time checking for the template: https://github.com/wisercoder/uibuilder https://github.com/wisercoder/uibuilder
styfle 10y ago
Thanks for implementing this! I was a bit standoffish at first but after several attempts to implement my own typed-templates[1], I found JSX to be very nice to work with because type safety in templates is hard to come by. If anyone is interested, I have a working boiler plate with React Server rendering using TypeScript[2]. [1]: https://github.com/styfle/typed-tmpl https://github.com/styfle/typed-tmpl [2]: https://github.com/styfle/react-server-example-tsx https://github.com/styfle/react-server-example-tsx
smrtinsert 10y ago
After I saw tsx, I wondered why anyone uses anything else. My goal for my next project is to use typescript and tsx or work somewhere that does! :)

scrollaway 10y ago

I'd like to offtopicly chime in and thank you :) Javascript is a language and an ecosystem I really disliked until React and TypeScript came around and changed everything. We're making extensive use of JSX in our React app (https://github.com/hearthsim/joust https://github.com/hearthsim/joust / https://hsreplay.net/replay/ZXKe5VoqTzknRJNcPdTnYa https://hsreplay.net/replay/ZXKe5VoqTzknRJNcPdTnYa) and it's really wonderful to both read and write.

afarrell 10y ago

> It would only increase the concept count in an educational setting where you want to only show the thing you're trying to explain. As someone who has written a long tutorial, this makes total sense. When I was first looking at the react ecosystem, it was very frustrating because of the high cost of picking pieces to work together. I really liked http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial.html http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial... because it showed how to use mocha in the context of we webpack and react and redux. It would be nice to see more tutorials for curated toolchains, but they take a lot of work.

emodendroket 10y ago
This is basically my frustration with the whole trend toward smaller pieces over big monoliths. I don't need a best-in-class every tiny little thing; I just want reasonable tools I can expect to work together well.
- wmil 10y ago
  Indeed. This is actually the point of DHH's much maligned "Rails is Omakase" article.
  - taeric 10y ago
    Why was that article maligned? Seemed pretty solid to me.
- drostie 10y ago
  The other nice thing is that bigger monoliths often (not always) make opinionated decisions. This is usually a good thing. In my work I deal with a legacy system with an ExtJS GUI. The two ways that ExtJS fails to be opinionated are perpetual pain points for me and my team! One is: every component has a million optional configurations, not to mention all of the events you can listen on. For the most part this is great, but there was never any systematic separation for "here are the absolutely-required things, there are the things which are optional but must be configured together, and over yonder are the things which are totally optional." Then you could require that the required-configs were, say, statically known when you were deriving a concrete class from an abstract one. Instead ExtJS wanted to accept doing all of this stuff at runtime, so because it failed to take a strong stand on its required configs, when you inevitably forget to configure some of them, you get an error puked out from somewhere very deep in the framework, where the call-stack and error messages show nothing related to your class at all, just "TypeError: SomethingYouNeverCaredAbout is null." It would have all been saved if `Ext.define` looked for some "abstractProperties" array, and made sure that every new `Ext.define` either set abstract properties or propagated them, finally checking that whichever ones are still present in the `Ext.create` call are filled in. Simple descriptive error messages are then available when you forget a required config. The other way ExtJS violates the principle is... God help you if you ever have to figure out how the underlying form submits and grid reloads actually work. You'd think with something so critical, it would be clear... it's not. "My grid refreshes automatically when the underlying store loads. Great! The underlying store can be loaded or reloaded with the .load() method, which accepts a callback. Wonderful!" It starts off very promising. But then you dig deeper and find that the .load() method packages the params and the callback into some object and then calls some .read() method which doesn't exist on the class you're looking at (inheritance! go up to the superclass!). Once you've traced that down the actual .read() bounces to some .doAction() which repackages these into some `Operation{type: 'readAction'}` or whatever... and then this gets handed up to some Proxy object which then stores it in some meaningless array, because of course these things get batched together... if you're not sick yet you find out that the Proxy needs to push the stuff to some Reader and Writer, just in case you wanted to communicate with the server via XML instead of JSON, or wanted to store the resulting array under a key not named 'results'. But you don't want to do any of this because the query finally gets XMLHttpRequested somehow (God knows how) to some `router.php` which we stole from IBM[1] a long time ago, which finally took a stand, "I will accept these two inputs, send them to the backend this way, and emit one of two corresponding outputs." (Except for that then you open that and it contains code for some sort of `doAroundCalls` because apparently the original author[2] decided to vacillate on what they'd accept, trying to also allow you to bookend one RPC service with two other RPC services, which never happens because Ext.JS never does it!) It gets a little more complicated because there is one rather significant bug which nobody has ever fixed in IBM's router.php, which is that formHandler services get the $_POST params (an associative array) as their first argument whereas XMLHttpRequests get the `json_decode($HTTP_RAW_POST_DATA)` (a StdClass object) as their first argument, so there's no interoperability on the frontend or the backend. Happy debugging, you. It's all one big mess. You begin to wish ExtJS had done what they eventually ended up doing[3], and just told people, "here is how you're going to do this thing. We have a Java router, a PHP router, here is how you set up your backend on these platforms..." That would have been very bold since ExtJS was originally just a set of helper classes to help automate GUI stuff with YUI, so I understand that the history made them feel a bit shaky about doing that, but... I really don't value that there's 10 layers of abstraction just in case I want to transmit the same stuff over-the-wire in XML rather than JSON. If any developers of toolkits are reading this: please, please consider very firm protocols: "here is what you're going to send me, and here's what I'm going to respond with." Because, half of programming anyways is translating outputs to inputs; we all know how to write the adapters which connect the two. Please make your life really simple by not supporting a million different ways to do the thing. I promise, you're also making my life simple because even though I will grumble about spending a half-day writing that adapter, I will then save untold dozens of half-days because the overall architecture is modularized, "oh there's a bug in the adapter, my bad, but it's only a 5 minute fix." My communication with you must pass through a gateway; please limit me to only a very small choice of inputs which you are going to tolerate, and break very loudly at the gateway when I forget some of those. It's far better than having a nigh-undebuggable error somewhere in the middle of your framework code that I never want to read. [1] http://www.ibm.com/developerworks/library/wa-aj-streamline/ http://www.ibm.com/developerworks/library/wa-aj-streamline/ [2] This could be Dan Dallala of Microsoft? His Gist appears to be an older version of the file and is one of the top results when googling strings out of the source file... [3] It's not complete as to how the backend should be set up, but at least there is now a documented interface for this Ext.Direct communication. https://docs.sencha.com/extjs/6.0.1/guides/backend_connectors/direct/specification.html https://docs.sencha.com/extjs/6.0.1/guides/backend_connector...

tomduncalf 10y ago

I mentioned it in my comment below, but as it is relevant, I am going to plug my Typescript 1.9 + React project set up guide here: http://blog.tomduncalf.com/posts/setting-up-typescript-and-react/ http://blog.tomduncalf.com/posts/setting-up-typescript-and-r...

gulbanana 10y ago

i'm one of the people whose team has benefited greatly from your work on .tsx, thanks for the great tool! i suspect a great many typescript users are not open source.

nojvek 10y ago
tsx refactoring and type checking is mind blowingly awesome. This feature alone makes me choose tsx over angular templates. angular templates are very loose and no property way of type checking it. I've seen some terrible mistakes in angular templates when refactoring.

k__ 10y ago

> TypeScript is not wedded to React Practially not, but it's a bit of a hassle. either you leave the JSX be and parse it with Babel or you need some wrappers for you VDOM lib, because tsc assumes a namespace, while most not-React-vdom libs just deliver a function out of the box.

bradleyayers 10y ago
I'm fixing that in https://github.com/Microsoft/TypeScript/pull/11267 https://github.com/Microsoft/TypeScript/pull/11267

petilon 10y ago

> JSX support in TypeScript is not wedded to React. Agreed. Here's an example of JSX in TypeScript that has nothing to do with React. UI Builder is a templating library, just like Mustache, but much better because you get full intellisense and compile-time checking for the template: https://github.com/wisercoder/uibuilder https://github.com/wisercoder/uibuilder

styfle 10y ago

Thanks for implementing this! I was a bit standoffish at first but after several attempts to implement my own typed-templates[1], I found JSX to be very nice to work with because type safety in templates is hard to come by. If anyone is interested, I have a working boiler plate with React Server rendering using TypeScript[2]. [1]: https://github.com/styfle/typed-tmpl https://github.com/styfle/typed-tmpl [2]: https://github.com/styfle/react-server-example-tsx https://github.com/styfle/react-server-example-tsx

smrtinsert 10y ago

After I saw tsx, I wondered why anyone uses anything else. My goal for my next project is to use typescript and tsx or work somewhere that does! :)