TypeScript is wonderful (if you sell tools or don’t want to RTFM ... )
... which I guess is a fair chunk of the programming community, now that I think about it. But that doesn’t make it right!
I guess the thing that still bothers me about TypeScript is the extra work that I, as a programmer, have to do to to make my IDE work properly:
- I need to include references to those libraries inside my source code (urrggh!).
“Two steps isn't so bad!” I hear you say! Well, then there’s compiling and deployment steps:
- I need an IDE that compiles the code automatically, or a build task to do this (which increases my debug loop).
- I need to separate the source code from the compiled code (WebStorm by default generates your JS code beside the TypeScript file, but you can configure that).
- Then I need to make sure that the generated code runs on browsers that the app must support. And depending on the ES6 features I’ve used, I need to include a shim.
In summary, using TypeScript requires more work than my current development process and increases my debug loop. It reminds me of the step you could perform for Java projects, whereby you tell the IDE where the source code for a JAR file is so that it could help you debug the JAR. It was extra configuration that I feel I shouldn’t need to do.
Summary: As long as TypeScript increases my development effort, I don’t intend to use it. But if that changes, I’ll reconsider.
Note: Kent C. Dodds suggested I check out the webpack videos on Egghead to understand how Webpack makes things easier. I’ll do that soon.
Google Material Design
I have mixed feelings about this.
The Material design components that Google has built look pretty good. They appear to make it easy to get a material-looking application working quickly. The 10-minute demo we saw on day 2 (despite some editing tricks) was quite good.
If I use Google Material Design, won’t my app be just like every other Material Design app? I guess it just feels too prescriptive, like Microsoft’s UI Guidelines were for Windows programs. Now don’t get me wrong — I’m for UI conventions that make it easy for people to use new apps. But as a user, do I want all my apps to look and feel the same (besides some theme colors)?
When you contrast this with what Twitter’s BootStrap framework (which is kind of a component library as well as a CSS framework) offers, I feel that designers have waaaay more freedom to customize the look and feel of their app with BootStrap than with Material Design. And they can do this without affecting usability or breaking common UI conventions.
Prototyping with Angular
This was a pretty cool presentation showing how the UX guys use their own Angular components to quickly change and configure working protoypes of components and applications. I especially liked the demo where they hooked up the Google Voice API to Angular, and could command the component to change its style by saying things like, “Make the header blue,” “Change the background picture to the car image,” and the app changed!
Other noteworthy things
- Ionic would be my starting point for building mobile-centric apps. It has lots of neat features like view-state caching (remembering which page on a tab you are viewing, so you can change tabs and come back to the one you were looking at). Again, reminiscent of Adobe Flex.
- Falcor by Netflix, when it is open sourced, could be better than FireBase? Maybe? It batches service requests to enable views to be served with only the data that they will render/use, rather than the complete object containing all the data-fields/properties.
- Benchpress tool for Protractor looks cool and helpful.
- John Papa’s talk was excellent on the need for code readability, with a glimpse of a new tool that can validate a style guide.
- Protractor plugins for automatically finding accessibility issues looks cool. In fact, I’d like to contribute to Protractor to fix the horrible syntax for getting and setting an input element’s value: get uses inputElem.setText(), set uses inputElem.getAttribute('value').
- Running the $digest() cycle in a Web Worker was interesting, and may be useful in certain edge cases where you need to perform a long-running client-side calculation (like a prime number calculator).
I had the opportunity to attend the Advanced Angular Workshops on the day before the conference. The workshops covered Protractor testing, Advanced Directives, ngAnimate, and angular-formly which is a data-based form rendering component by Kent C. Dodds.
This last workshop especially interested me as it offered a different approach to supporting many of the same use-cases that I considered when building angular-form-lib (please try it out!). The main differences I see between the two libraries (at the moment) are:
- angular-form-lib still uses directive-elements to define the form elements, whereas formly uses model data
- angular-form-lib offers the ability to create form-policies that allow you to define how you want all forms across your site to behave. For example, you can define a policy that says, “When the form is submitted and there is an error, set the focus to the first field with an error,” which is super-useful and accessible.
- angular-form-lib links error-messages (regardless of how they are formatted or displayed) to the form-control, so that when the form control has the focus, screen-readers can read out the error(s) associated with that field.
This article was reprinted with permission from Airpair. Any opinions expressed in this article do not necessarily reflect the views of ProgrammableWeb or its editorial staff. If you have questions regarding the information in the article, please contact the author.