Types For Frontend Developers
It's hard to bring up static types in JavaScript without starting a debate. The benefits of using static types are real, and so are the tradeoffs. As with so many things in software, the key to figuring out if the benefits outweigh the costs for you and your team. At Reflexion Health, we recently looked at introducing static types; I'd like to share some of the lessons we learned, and shed some light on how static types can help your team.
Frontend Tools (maybe Future JS?)
Tools
How do you know what a function does, what are valid inputs, what values will it return? How do you make sure that a function that's supposed to work on string doesn't get called with an object and take down your app at runtime? How do you communicate to the other developers on your team all of the assumptions in your code; all of the stuff you've got in your head about how that function you just wrote is supposed to work?
This is where types shine.
Introducing types can help you clearly communicate your intentions to other developers on your team. But this can go much further that simply enforces that a function takes a string, for example. Modern type systems allow you to be much more expressive that was capable in the past.
At the same time, there are tradeoffs that come when you introduce types to your code. Types are meant to constrain; that's the point. But the constraints that help you write more expressive code can hinder your team if you don't consider them upfront. How do you handle and ad-hoc task or prototyping new ideas if you've got all this extra stuff to type? You're compiling your code now, so you know about errors earlier, but compiling isn't that quick and the error messages can be cryptic. Lastly, JavaScript has a rich ecosystem of libraries & tools that were not writing with static types; how do you take advantage everything that already exists?
My team recently went through all of this and we've learned a lot. We're seeing a lot benefit, but it's not all rainbows and kittens. I'll share with you why we feel it's worth it.
- Why our team decided to investigate static typing
- What options we considered, and why we chose what we did
- How we handle interop with existing libraries & tools
- Some examples of where having types can pay off
Developers, intermediate
Intermediate
Attendees will learn how static types can help write more expressive & correct software and how to address tradeoffs when considering statically typed languages. With any luck, we'll also dispell some misconceptions about static types.
Attendees should have a good understanding of JavaScript, and some opinion on static types.
Conceptual
Great proposal! Definitely would like to see this submitted for Fluent: http://conferences.oreilly.com/fluent/fl-ca/public/cfp/522
Some feedback:
The short "Description" could be more catchy. I liked how the beginning of your Abstract talks about not wanting to start a debate, but just share your team's experience... but that detail would need to be, in some form, in the description, to hook me as an attendee if I were reading through a bunch. Your short "Description" is your marketing pitch for getting people interested. The Abstract expands to provide details once they're already interested, so make sure you kinda grab someone's attention.
Example:
Obviously, don't just copy that verbatim, but that gives you an idea of the kinds of things you want to do to grab attention. :)
Absolutely do not make your short "Description" just your first paragraph of your Abstract. I hate that, it's so unoriginal. You didn't, just cautioning not to do so. Be creative and say the same things in multiple ways as appropriate.
Case Studies are useful, and every good conf needs them.
That said, they attract a particular kind of audience. They tend to attract managers or those who are already searching around to fix or change something. You won't as likely attract some of the people who you want to get this message to -- those who already have strong opinions the other direction or don't realize types could solve their issues -- framed purely as a case study.
I think you can tell the same kinds of stories, but frame them slightly differently, and attract a wider audience. This abstract reads as like a fifth grader is writing a book report about a book.. it's very formulaic and straightforward. What if instead, you kind of gave a quick glimpse into a narrative, like telling the beginning of a story, something like:
"I was building this function X to do something, but I couldn't figure out how to make the intent of it clear, and so it kept getting refactored, which wasted dev time. It occurred to me that I could encode that information in the form of types, so I started exploring that more, and it turned out that it made this big difference across our whole code base."
Then you go on to briefly talk about how in this talk, you're going to shed light on how types can help the audience members tackle similar problems and the benefits it will have on team communication, efficiency, etc.
Same talk, same message, different packaging. I think you might consider tweaking this proposal in that respect. I think it will up the attractiveness quite a bit. A reviewer won't need to look for the potential, nor will an attendee. It will be clear and obvious. People will want to come to this talk.
I always tell people: OK talks are about the topic (like this one sounds right now). Good talks are about the speaker's showmanship and the presentation. Great talks are about the audience. Ask yourself how you can describe (and shape) this talk to be more about them, from the lens of what your team did. Everyone will identify more deeply with it in that way.
There's a few typos/grammar nits to be made in the Abstract. Make sure you carefully proof-read before submission. Every little bit of polish can help.