18 ms·

No love for react-devtools [0]? I'm amazed it wasn't even an honorable mention, considering he mentioned react and redux (which is probably generally used with

No love for react-devtools [0]? I'm amazed it wasn't even an honorable mention, considering he mentioned react and redux (which is probably generally used with react). I'm also surprised he didn't mention flowtype [1], which is by Facebook and is supported by Babel! If you're writing React, you're probably already using Babel, so using flow is very low friction. Furthermore, if you're interested in runtime assertions, you can use babel-plugin-typecheck [2], which will convert your flowtype annotations into assertions. If we're looking to be pragmatic, IMO, this is the optimal path to take. The library that Elliot is working on looks interesting, but even he recognizes in its page that it's still a work-in-progress. If you're writing a modern JS app and you wanna take advantage of all the ES6 goodies, you'll pick up babel. And if you're using babel, you can get jsx and flowtype for free. It's ridiculous to try and build a JS app without some sort of bundler, whether it's browserify or webpack. And if you're gonna use a bundler, pulling in a transpiler like babel is really easy and it lets you write much saner code. Oh, and if you're already drinking the Facebook kool-aid with react, jsx, and flowtype, you'll wanna give nuclide a shot. As I understand it, it has nice flow support, with stuff like "click-to-define" and inline linting [3]. I'm using flowtype annotations with the babel plugin I mentioned above, but due to my usage of non-standard features, I can't successfully run flow itself over my codebase. I'll also note that my experience with nuclide when I last tried it was underwhelming. [0] https://github.com/facebook/react-devtools/ https://github.com/facebook/react-devtools/ [1] http://flowtype.org/ http://flowtype.org/ [2] https://github.com/codemix/babel-plugin-typecheck https://github.com/codemix/babel-plugin-typecheck [3] http://nuclide.io/docs/flow/ http://nuclide.io/docs/flow/

makepanic 11y ago
The Ember Inspector [0] is another great devtools addon for developing Ember applications. [0] http://guides.emberjs.com/v2.2.0/ember-inspector/installation/ http://guides.emberjs.com/v2.2.0/ember-inspector/installatio...
ericelliott 11y ago
Flow's type inferrence features are great, but I'm not a fan of the inline type annotations, which is one of the major reasons I didn't just use it instead of working on rtype/rfx. I believe that both Flow and TypeScript are competing solutions that are precursors to what may eventually become standard in JavaScript. At that point, all the annotations written for Flow and TypeScript will become obsolete overnight. This is essentially the same thing that happened to AMD, and one of the reasons that I advocated for users to chose Node-style modules and Browserify (and now Webpack) instead of AMD. I consulted on several projects and gave exactly that advice. They didn't listen. Now they're stuck supporting a huge AMD legacy & Bower ecosystem and the authors of Bower are no longer supporting it. That is the future that awaits those who build TypeScript + Flow-annotated applications. Fine if it's just a few modules here and there, but for large enterprise apps, you're building a mountain of technical debt what will eventually need to be paid. Don't get me wrong, I am really excited that Flow and TypeScript are paving the way, and I blatantly stole some good ideas from them for rtype/rfx, but I'm also very wary about leading people down a road that I am pretty confident will dead-end within a few years. Both projects still have great value though. We learned a lot from AMD, and it has influenced the new standards. I am confident that TypeScript and Flow with both influence whatever we get in the JS standard. I know the TypeScript team is already experimenting with additions to the runtime reflection specifications coming in future iterations of ECMAScript.
- WorldMaker 11y ago
  With regards to AMD: SystemJS is a polyfill for the ES2015 module loader designed to remain a set of plugins to said module loader should a browser actually start to implement it. The plugins include the ability for the ES2015 module loader to directly load AMD and CommonJS modules, thus none of the legacy AMD is technically lost and you also don't necessarily need something like Browserify/Webpack in a build process or Node-style modules (CommonJS). JSPM is a package manager for SystemJS and for the most part it can be fairly straightforward to move from Bower to JSPM. With regards to Typescript: I don't think it is a "dead end" and I definitely think you are wrong about the future of it. Typescript has been relatively careful at keeping "an eye to the horizon" and having some idea of the "forward compatibility" of its features. For instance, the module format in Typescript was built before the ES2015 standard finalized, but the final standard was surprisingly close to what Typescript used and nothing necessarily required being rewritten and it was very easy to clean up the old style incrementally if you did feel like being particular about using the final ES2015 syntax. I feel like the same can be said about Typescript's type annotations. They are definitely informed by ES4 ("the lost version", what forked into ActionScript, sort of) and in turn, yes, the Typescript team is certainly influencing the standards to possibly add type annotations to the EcmaScript standards ("this time for real"), or at least a Python 3-like approach where type annotations are safely ignored by browsers when left in the code. At the very least, if ES standardized type annotations are suitably different from Typescript there will presumably be a Typescript transpiled output to it (just as the old Typescript module imports get output correctly when targeting ES2015), and you can even use that output to bootstrap your conversion to the new syntax (thanks to Typescripts attempt to remain a pure superset of ES).
tommyd 11y ago
Just to add my experience here, I evaluated Flow and Typescript recently for a new project and found that while Typescript was more effort to get going with than Flow (things like needing .d.ts files for third party libraries which may not always exist on DefinitelyTyped, setting up the Typescript compiler config, etc.), the advantages of using it made it worthwhile. Documentation and community support online for Flow seems quite light compared to Typescript - I get the sense it is mainly just used inside Facebook at the moment, and it was hard to find help for problems I encountered - and even with Nuclide, the IDE support for flow doesn't touch Typescript's (I guess partially because Typescript has definitions for the 3rd party libraries you use, which is usually quite a big part of JS programming) - the plugins for Sublime and Atom for Typescript are really impressive, as is Visual Studio Code - it's hard to imagine going back! Typescript also seems to offer a more complete "correctness" check of your code, I guess because it is compiling it - I found that Flow didn't pick up on typos in things like imports, which led to runtime errors, whereas Typescript does. I also couldn't get Flow to validate my React prop types - I was probably doing something stupid here, but the lack of docs made it hard to know what. The final straw for me with Flow was that at a certain point in the project, my Atom/Nuclide started using all my CPU with loads of flow-server processes, and again, I couldn't find a solution online, which made it useless to me. Flow's lightweight nature is still appealing and I will keep an eye on it, but at the minute, for a commercial project especially, I think Typescript is a better and more mature bet. Shame it doesn't support non-nullable types though! The main cost of using Typescript is the need to have definitions for third party libraries (although it is possible to create very basic "skeleton" definitions, just listing exported members as being of type "any", which doesn't give you type safety but is a quick way to get it to compile), and also interop with some "cutting edge" features like requiring CSS modules in a React component requires some hacks, but I think the benefit of having the code compile is worth it - I've found most of the time when a runtime error slips through, it's because I've used the "any" type, either in my code or for a library. I plan to write up my experiences at some point, as there's not a huge amount out there about using TS with the latest shiny stuff like CSS modules. Also one other note on Nuclide - I had terrible problems with the version distributed through the Atom package manager - it would completely freeze my Atom and use 100% CPU and the only fix was to delete ~/.atom and start from scratch. Installing it from source fixed this, and even though I am now using Typescript, I am still using most of the Nuclide packages as it adds a few nice features (especially the inline lint/compile errors, not sure which plugin adds these but they appear on mouse over whereas the default Atom ones don't seem to). It does add ~10s to Atom start time, but otherwise doesn't seem to impact performance too much.

makepanic 11y ago

The Ember Inspector [0] is another great devtools addon for developing Ember applications. [0] http://guides.emberjs.com/v2.2.0/ember-inspector/installation/ http://guides.emberjs.com/v2.2.0/ember-inspector/installatio...

ericelliott 11y ago

Flow's type inferrence features are great, but I'm not a fan of the inline type annotations, which is one of the major reasons I didn't just use it instead of working on rtype/rfx. I believe that both Flow and TypeScript are competing solutions that are precursors to what may eventually become standard in JavaScript. At that point, all the annotations written for Flow and TypeScript will become obsolete overnight. This is essentially the same thing that happened to AMD, and one of the reasons that I advocated for users to chose Node-style modules and Browserify (and now Webpack) instead of AMD. I consulted on several projects and gave exactly that advice. They didn't listen. Now they're stuck supporting a huge AMD legacy & Bower ecosystem and the authors of Bower are no longer supporting it. That is the future that awaits those who build TypeScript + Flow-annotated applications. Fine if it's just a few modules here and there, but for large enterprise apps, you're building a mountain of technical debt what will eventually need to be paid. Don't get me wrong, I am really excited that Flow and TypeScript are paving the way, and I blatantly stole some good ideas from them for rtype/rfx, but I'm also very wary about leading people down a road that I am pretty confident will dead-end within a few years. Both projects still have great value though. We learned a lot from AMD, and it has influenced the new standards. I am confident that TypeScript and Flow with both influence whatever we get in the JS standard. I know the TypeScript team is already experimenting with additions to the runtime reflection specifications coming in future iterations of ECMAScript.

WorldMaker 11y ago
With regards to AMD: SystemJS is a polyfill for the ES2015 module loader designed to remain a set of plugins to said module loader should a browser actually start to implement it. The plugins include the ability for the ES2015 module loader to directly load AMD and CommonJS modules, thus none of the legacy AMD is technically lost and you also don't necessarily need something like Browserify/Webpack in a build process or Node-style modules (CommonJS). JSPM is a package manager for SystemJS and for the most part it can be fairly straightforward to move from Bower to JSPM. With regards to Typescript: I don't think it is a "dead end" and I definitely think you are wrong about the future of it. Typescript has been relatively careful at keeping "an eye to the horizon" and having some idea of the "forward compatibility" of its features. For instance, the module format in Typescript was built before the ES2015 standard finalized, but the final standard was surprisingly close to what Typescript used and nothing necessarily required being rewritten and it was very easy to clean up the old style incrementally if you did feel like being particular about using the final ES2015 syntax. I feel like the same can be said about Typescript's type annotations. They are definitely informed by ES4 ("the lost version", what forked into ActionScript, sort of) and in turn, yes, the Typescript team is certainly influencing the standards to possibly add type annotations to the EcmaScript standards ("this time for real"), or at least a Python 3-like approach where type annotations are safely ignored by browsers when left in the code. At the very least, if ES standardized type annotations are suitably different from Typescript there will presumably be a Typescript transpiled output to it (just as the old Typescript module imports get output correctly when targeting ES2015), and you can even use that output to bootstrap your conversion to the new syntax (thanks to Typescripts attempt to remain a pure superset of ES).

tommyd 11y ago

Just to add my experience here, I evaluated Flow and Typescript recently for a new project and found that while Typescript was more effort to get going with than Flow (things like needing .d.ts files for third party libraries which may not always exist on DefinitelyTyped, setting up the Typescript compiler config, etc.), the advantages of using it made it worthwhile. Documentation and community support online for Flow seems quite light compared to Typescript - I get the sense it is mainly just used inside Facebook at the moment, and it was hard to find help for problems I encountered - and even with Nuclide, the IDE support for flow doesn't touch Typescript's (I guess partially because Typescript has definitions for the 3rd party libraries you use, which is usually quite a big part of JS programming) - the plugins for Sublime and Atom for Typescript are really impressive, as is Visual Studio Code - it's hard to imagine going back! Typescript also seems to offer a more complete "correctness" check of your code, I guess because it is compiling it - I found that Flow didn't pick up on typos in things like imports, which led to runtime errors, whereas Typescript does. I also couldn't get Flow to validate my React prop types - I was probably doing something stupid here, but the lack of docs made it hard to know what. The final straw for me with Flow was that at a certain point in the project, my Atom/Nuclide started using all my CPU with loads of flow-server processes, and again, I couldn't find a solution online, which made it useless to me. Flow's lightweight nature is still appealing and I will keep an eye on it, but at the minute, for a commercial project especially, I think Typescript is a better and more mature bet. Shame it doesn't support non-nullable types though! The main cost of using Typescript is the need to have definitions for third party libraries (although it is possible to create very basic "skeleton" definitions, just listing exported members as being of type "any", which doesn't give you type safety but is a quick way to get it to compile), and also interop with some "cutting edge" features like requiring CSS modules in a React component requires some hacks, but I think the benefit of having the code compile is worth it - I've found most of the time when a runtime error slips through, it's because I've used the "any" type, either in my code or for a library. I plan to write up my experiences at some point, as there's not a huge amount out there about using TS with the latest shiny stuff like CSS modules. Also one other note on Nuclide - I had terrible problems with the version distributed through the Atom package manager - it would completely freeze my Atom and use 100% CPU and the only fix was to delete ~/.atom and start from scratch. Installing it from source fixed this, and even though I am now using Typescript, I am still using most of the Nuclide packages as it adds a few nice features (especially the inline lint/compile errors, not sure which plugin adds these but they appear on mouse over whereas the default Atom ones don't seem to). It does add ~10s to Atom start time, but otherwise doesn't seem to impact performance too much.