6 ms·
TypeScript and JSX
- Renaud 11y agowow, that, plus the VS2015 support for JSX syntax amount to great tooling. Being able to use JSX in Typescript is a big deal, if only for the compile-time checking you get for free.
- deleted 11y ago[deleted]
- toxicFork 11y agoI may just use it for compile time prop validation! Amazing. I was looking for that feature alone using eslint and so on but couldn't find anything like that. Since the compile speed improvements I'm running out of excuses not to use TypeScript in my projects now.
- arm55 11y agoThis is pretty awesome. React and typescript have independently improved my opinion of javascript - now we get to use them together.
- drinchev 11y agoThat's cool. I'm trying to use it right now. What I don't like so far is : 1. Lack of definition files for some isomorphic flux implementations ( like yahoo/fluxible ) ; 2. Lack of big projects written with TSX to learn from ; 3. No support in WebStorm ( even 11 EAP, dated 09.09.2015 ) for TSX files ; With No. 1. as most annoying I would recommend for anyone trying to do isomorphic NodeJS + TypeScript app to be really patient and to expect writing commits to DefinitelyType repo. Kudos for TypeScript team for implementing TSX it would be great when it's out of beta.
- wereHamster 11y agoNote that you don't need the declaration files. They are entirely optional. You can get started right now and add them gradually as they get written by the community.
- drinchev 11y agoI usually write the declaration files that I need and submit to the repo. It's not that hard :) and your app feels kinda 'complete'. I would take the opportunity to address the DefinitelyType repository issues. Actually if anyone from TypeScript team reads this, they should know people there are struggling with that. There are multiple flaws in gathering so much development code under one roof and a lot of discussion that goes nowhere [1][2][3]. What would be great if there is some sort of "native" support / recommendation of definition files. 1 : https://github.com/borisyankov/DefinitelyTyped/issues/5040 https://github.com/borisyankov/DefinitelyTyped/issues/5040 2 : https://github.com/borisyankov/DefinitelyTyped/issues/2150 https://github.com/borisyankov/DefinitelyTyped/issues/2150 3 : https://github.com/borisyankov/DefinitelyTyped/issues/4513 https://github.com/borisyankov/DefinitelyTyped/issues/4513
- jbrantly 11y agoFWIW, there is better support[1] in 1.6 for definition files for node modules. TypeScript can now read definitions directly out of node_modules. As library authors include those in the package there will be less of a dependency on getting definitions from DefinitelyTyped. This obviously doesn't solve all problems but I think the point is the TS team is aware of some of the issues and is taking steps to address. 1. https://github.com/Microsoft/TypeScript/pull/4352 https://github.com/Microsoft/TypeScript/pull/4352
- drinchev 11y agoThanks for that, I didn't notice this is coming :)
- sparaker 11y agoThis is great news without a doubt, Does anyone know what is the direction Typescript is headed now that ES6 is becoming increasingly supported?
- hokkos 11y agoI would be interested to know about the difference with TypeScript and Flow, which can do the most ES6/7 things, which has the most expressive type system.
- dominotw 11y ago> which has the most expressive type system. Elm?
- danjc 11y agoThis is awesome! TypeScript has been tremendously useful to us and it's great to finally be able to use React properly.
- beefsack 11y agoI'm still yet to be convinced that JSX is a good idea, why break existing tooling and significantly complicate parsers for what appears to only be a minor convenience at the surface level? Mithril manages similar functionality without any modifications to syntax. https://lhorie.github.io/mithril/ https://lhorie.github.io/mithril/
- ivanceras 11y agoI really like the simplicity of mithril with regards to expressing the view. It's less verbose than jsx, and even less verbose than html. You cant think of it as a tree of minimalistic functions organized in a JSON structure. Also, you can use regular javascript control flow in the view, that's awesome.
- andreypopp 11y agoYou can also use regular JS control flow within JSX. That's the point.
- pygy_ 11y ago`m()` actually outputs plain JS objects. m(".hello", 'world') outputs {"tag":"div","attrs":{"className":"hello"},"children":["world"]}
- kennydude 11y agoThe security test on that page isn't correct for Backbone. Underscore's templating (what is used) has two modes, `<%- %>` will output escaped (what should be used in that demo) and `<%= %>` will output raw
- undershirt 11y agoIs the only difference really that Mithril has replaced "React.createComponent" with "m"? The limitations of creating the view in JS seem invisible, yet visceral to us. I think the reason it is jarring is a fundamental expressivity problem of JS not being able to match templating logic of Handlebars like for-loops and conditionals, despite JS having these statement constructs. An elegant templating solution is a result of Lisp's mixing of data and logic, something called Hiccup in the ClojureScript community, which I've written about here [1]. [1]: https://github.com/shaunlebron/jumping-from-html-to-clojurescript https://github.com/shaunlebron/jumping-from-html-to-clojures...
- guscost 11y agoGreat news. I've been avoiding JSX at work in order to get TypeScript support, and it will be a nice option to have in the future. Now we just need to upgrade from VS2012 (that version is still on TypeScript 1.0, so a lot of the DefinitelyTyped definitions don't work out of the box).
- serichsen 11y agoI see two problems with the basic idea of JSX: - Parsing is a mess, it is not even obviously unambiguous. - HTML syntax is horrible, and all templating language attempts building on it are verbose and clumsy. That is the negative argument (“That is crap”), but there is also a positive argument (“Here is a much better alternative”): You can express HTML structure in a concise and relatively readable manner in plain JavaScript, and you do not need a 400 kb interpreter nor a separate compilation step for it! ['div', {'class': 'foo'}, 'some text', ['span', {}, 'yay']] You also can embed "directives" or "components" in a rather obvious and unambiguous way: ['div', {'class': 'container'}, [MyConstructor, {'arg': foo()}]] Implementing a robust interpreter for this is a matter of perhaps 50 to 100 lines of plain JavaScript.
- feedjoelpie 11y agoThe big advantage of JSX to my company is that our design team, which does design in the browser, has a much shorter leap to understanding it than plain JavaScript. These suggestions of "JSX sucks, you can express this in plain JS" always leave people with those skill sets behind. Sure it would be really awesome if the designers were also serious JS programmers, but that's not why we hired them, and with JSX they don't need to be.
- nine_k 11y agoI honestly do not see how much effort would it take to get from <foo bar="baz">Quux</foo> syntax to ["foo", {bar: "baz"}, "Quux"] syntax. I believe someone already working with code (HTML, CSS) should be perfectly capable to learn this transformation in well under 15 minutes.
- vvpan 11y agoIt's a matter of preference. I'd rather shoot myself than write HTML as JS objects like that. I've written countless lines of HTML in my life and don't see any reason to start thinking or writing HTML in the form of JS.