DEV Community: Preethi Kasireddy

MooTools

Preethi Kasireddy — Thu, 02 Feb 2017 04:47:31 +0000

Introduction

If you were doing web development in 2009, MooTools might very well not need an introduction! MooTools was a well-known JavaScript utility library for building “powerful and flexible code with its elegant, well documented, and coherent APIs”. Its core contributing team was made up of a brilliant set of developers, and we’re lucky today to be speaking with three of them:

Formerly core contributors to MooTools, Sebastian MarkbÃ¥ge, Tom Occhinoand Christoph Pojer are active and vibrant contributors to the Reactcommunity today.

Can you tell us a bit about yourselves and how you each got into programming?

Sebastian: My dad used to code games for the Commodore 64, and I would watch him, and tweak them. I was only ten when I really got into programming. I started programming games and doing small lookup databases through Qbasic for MS-DOS.

Tom: When I first got a computer I was running Windows 3.1, and then Windows 95. I became obsessed with re-skinning windows. I wanted my computer to look different, so I figured out how to resource hack, and change the images. I started with MS Paint and made the buttons different colors. Then, there was this program called WindowBlinds that got me into creating my own skins. Eventually, I discovered HTML. It was so much easier, and better.

Christoph: So, I started programming when I was about 12 trying to learn how to make websites. And then, I think when I was 14 or so, when a friend in middle school was playing a game online and I bet him that I could make it, and make it better. After that, I spent basically every day for four weeks building an online game. It was motivating, building small games that a bunch of people played afterwards.

Interviewer: Interesting! Games seem to be the theme here, especially for people who got into programming early.

Tom: Yeah. You had to edit HTML in a Notepad and make a .html file. There was no syntax highlighting or anything like that. I didn’t know what valid markup was until Netscape came out in the 1990s, like 1997.

Netscape

Â Tom: I think it was probably ’98 for me if I had to guess because I was 13. It seems like it was earlier.Christoph: Exactly! I made websites and someone told me that a website I made didn’t work in Firefox. I didn’t even know what Firefox was. That was 2001.

Sebastian: Yeah, ’93 is when I started. I started withNetscape 2 I think. CSS didn’t exist at all. HTML existed, but JavaScript was not on the scene yet, so you couldn’t actually program much on the client. You had to do everything server-side. Everything was Perl and CGI.

Tom: You’re a dinosaur.

Going back to the origin, do you know why Valerio started MooTools, and how it got started?

MooTools inÂ 2007

Tom: Valerio always gets frustrated when he sees something that can be done better. He was using Prototype, and more specifically, script.aculo.us. There was a common issue where if you created a click event handler to start an animation, and you clicked it twice, it would start the animation overâ€Š–â€Šbasically firing off new animations every time without the ability to choose to either resume, enqueue another, or replace.

It actually wasn’t MooTools that he was creating at first. His whole premise for Moo.fx was just to be able to retain this instance, and be able to do something better than what Script.aculo.uswas doing by default. Prototype was pretty big at the time, so he created prototype.lite.js, which was basically just the class system plus a couple of utilities. Eventually, he built Moo.fx on top of that. It must still exist somewhere today, but that’s how it was born. From Moo.fx, there was a foundation for an alternativeâ€Š–â€ŠPrototype plus Script.aculo.usâ€Š–â€Šwhich became MooTools.

Tom (left) and Valerio (right), the original author of the MooToolsÂ library

How did each of you start contributing to MooTools?

Tom: I was creating a photo album app for a photography studio, and we needed a way to sort the photos. At the time, MySpace had a top eight grid. They implemented it as a one-off, and we wanted to build better support for that.

Script.aculo.us had something similar built in, but I basically expanded MooTools’ drag and drop library, and created Sortable.js. I showed it to Valerio, and he decided it should be in the core of MooTools.

Interviewer: How old were you? Since there was no Github back then, how did you even get to the repo?

Christoph: We used Trac and Subversion.

MooTools Trac

Tom: Gaining access to Trac and Subversion was a big deal. When Valerio asked me to contribute, there were no code reviews. You just checked it in.

Christoph: I had a similar experience as Valerio. I didn’t like Prototype and script.aculo.us. I saw Moo.Fx and then MooTools come out. It was in September of 2006â€Š–â€ŠI was 16 or 17.

Christoph with dread locksÂ ðŸ˜†

I was in my prime teenage years and I was kind of a rebel. I wanted my code to be perfect, and MooTools was just written so perfectly. It was so small but did everything I ever wanted. I was very idealistic.

Tom: Do you remember what your first contributions were? I don’t really remember.

Christoph: I started using it in early 2006 for games. I literally built a German version of Facebook for my friends, even though I didn’t know what Facebook or MySpace were. Then I built some other games with it. I wasn’t contributing much.

I didn’t know English very well, but was trying to learn. I became a core contributor in 2009, almost at the exact time Tom was hired by Facebook. He basically told us to take over after that. That’s when I started contributing to the core, and then we started doing a hack-a-thon in London, where we met up once a year. That was pretty cool.

Sebastian: I came in around the same time as Christoph, but my experience was different. It happened during my second pass into JavaScript. I started with JavaScript in the late ’90s, when it was pretty much useless. Then it had a resurgence around 2005 and I started moving back to the client after having spent five years on the server only. I was looking at all the frameworks, and I needed more help. I wanted to understand more, and MooTools helped me learn how the language worked. It was written in a very clean way, you could study the code base itself, but I was frustrated with some of the details. Unlike these guys, I was actually building pretty complex apps at the time. I was building this complex WYSIWYG editor.

Tom: I was building a CMS. It wasn’t that trivial, come on.

Sebastian: I made a rant on the public mailing list. There were two mailing listsâ€Š–â€Ša private internal list, only for developers, and the public one. On the public list, there was the guy named Aaron Newton, and he was kind of the dad of MooTools. He was the adult because he was actually building startups at the time, and was trying to create a community because he understood the value in that. He spent a lot of time in the public forums helping newcomers, and bringing them into the inner circle. I made these long rants on the public mailing list, and he invited me into the closed circle.

Tom: I think we all started out on the forums. The first step was getting moderator rights on forumsâ€Š–â€Što be able to close topics and answer questions authoritatively. We had little icons next to our names indicating we were moderators. My first contact with Valerio was when he reached out to thank me for helping out with the forums. From that point on, I started contributing to the code.

Christoph: That’s funny because I still have that email. My first interaction with Valerio was not actually about MooTools itself. He had built this bundler or compression thing that I really needed, and there wasn’t really anything else like it. We used to just ship like 30 JavaScript files, and this MooTools website had this bundler where you could concat your files together.

The MooTools builder. So before its time.

Tom: So before its time, man, the MooTools builder. So before its time. You selected the things you wanted, and it created a customized script for you. You would just save the file and put it on your web server. It was amazing.

Sebastian: It was ingenious because there was no common JS.

Tom: There was no nothing. It was all globals.

Sebastian: There was no way to tell from anyone’s code base what modules were required, so you had to check it yourself, but because it was just a website, you could do that easily without trying to get a standard around it.

MooTools has such a distinct and memorable brand around it. What were some of its core values that made it stand out initially, and why do you think people remember it so positively today?

Sebastian: We valued the readability of the code base a lot, because that’s how we learned.

We saw jQuery as the opposite, where everything was inline. There were no reusable abstractions, and they tried to support every use case there was. Ultimately that made the code more difficult to understand and maintain. That’s why we chose not to support as many use cases.

Christoph: It was interesting because we were all very like-minded. We were building something great, but we didn’t do any outreach. We attended maybe 3–5 conferences over the course of seven years. We didn’t really build it for other people. We were trying to build the perfect framework, something that we could use. It might not be the best way to grow an open source project, but we were just our own little community trying to build something perfect.

Sebastian: There was also the chaining. The chaining was very explicit, and everything was designed around readability and grammarâ€Š–â€Šthe chaining should mimic an English sentence.

Tom: We constantly iterated to refine and improve the API. One of the guiding principles was that code built on top of MooTools should be readable, easy to understand and easy to extend. We had a very strict style guide in our heads that we all followed. It was almost academic in a sense.

Christoph: I think academic is a really good description. We were so focused on the API design, rather than building something that people could actually use and adopt.

MooTools team hackingÂ away

What do you think was the most impactful or important thing that you learned while working on MooTools?

Collaboration, like we said, is really important to create a very tight teamâ€Š–â€Šone that shares the same values in terms of how you write code and what you should prioritize. That’s one thing we mastered that allowed us to move forward.

Sebastian: Collaboration, like we said, is really important to create a very tight teamâ€Š–â€Šone that shares the same values in terms of how you write code and what you should prioritize. That’s one thing we mastered that allowed us to move forward.

On the other hand, pragmatism is something we didn’t do well, but we’ve since learned.

Christoph: For me, because it was the first open source project I worked on, I learned a lot about being involved in the community and working on open source. That experience can burn you out. People hate on you for making changes to the API that they don’t understand, or you have to deal with people questioning you all the time. But, getting to know the community, meeting people I worked with everyday, that was one of the best things for me.

Tom: For me, learning JavaScript was huge. There was a ton of experimentation, trying to solve problems in a cross-browser way, and I felt like I almost carried too much weight about cross-browser incompatibilities. I feel like I really learned JavaScript and functional programming concepts in a way that I couldn’t in school.

We got hired because we could solve real business problems using JavaScript. JavaScript was looked down on in the beginning, and had stagnated, and had performance problems, but it let us build something productive.

Sebastian: I think that’s a really underestimated point in the last decade. There was a growing community of kids like us with no prior experience, and we got hired because we could solve real business problems using JavaScript. JavaScript was looked down on in the beginning, and had stagnated, and had performance problems, but it let us build something productive.

Meanwhile, there were a lot of academic projectsâ€Š–â€Šthe common wisdom was that they were going to succeed. That these business tools backed by big enterprises were going to replace JavaScript. But that’s not quite what happened. It goes to show, you have to pay attention to what people are drawn to. They’re drawn to it for a reason.

MooTools was probably one of your first large open source contributions and projects as well. How would you say it impacted your career?

Tom: For me, it was pretty easy, actually. Somebody was organizing a conference in the Netherlands called Fronteers and they used and loved MooTools. So they reached out to Valerio to see if he would speak about MooTools and object-oriented JavaScript. Valerio referred them to me. I was pretty young, in my early 20s, and I had never spoken at a conference. I didn’t really know what I was talking about. I thank my lucky stars everyday that it wasn’t recorded because it was so embarrassing. As a result, though, a recruiter from Facebook contacted me, and said they were trying to do more with JavaScript and asked me to come in for an interview.

Tom at React.jsÂ Conf

Christoph: My story is pretty similar to Tom’s. I also did a public talk. It was really difficult because while I was used to public speaking, I was not used to public speaking in English in a foreign country. I was not as lucky as Tom, my talk is still online. I used to have a really heavy, Austrian, Arnold-Schwarzenegger-like accent.

After the talk, a Facebook recruiter reached out, and I ended up doing an internship at Facebook. Tom was actually my intern manager, so that worked out pretty well. Then, I had to go back to University and finish my degree before I could join Facebook full-time. By the time I came back, there were all these MooTools people like Sebastian working full-time at Facebook.

Sebastian: I was working in Europe. Thomas Aylott was at Cloudera and then worked at Sencha in the Bay Area. He started talking to me about moving out here. At the time, I didn’t wanted to move to California, especially not the Bay Area. But, another MooTools guy referred me to Apple, so I interviewed there. I didn’t really like the attitude of the company. I honestly didn’t think I would move out here at all. Finally, though, Aylott left Sencha and started working for Facebook. After that, he referred me again, so I finally flew out, interviewed, and it had a different vibe. All my MooTools friends were there, so I decided to jump in.

People didn’t understand why I would want to work at Facebook. I had to convince them that we were doing interesting stuff. After a while that was part of what fueled our resurgence into the front-end, open source world. We wanted to share some of the stuff that we were thinking about and working on.

Tom: People didn’t understand why I would want to work at Facebook. I had to convince them that we were doing interesting stuff. After a while that was part of what fueled our resurgence into the front-end, open source world. We wanted to share some of the stuff that we were thinking about and working on. Even after 2011, we were still seen as a PHP company. Hack didn’t come around until 2013.

Christoph: People actually thought we didn’t know JavaScript.

Tom: It’s funny because all of the problems we were solving back then, became the top of our minds two, three years later. Systems like Bootloader and Primer. Primer was the precursor to progressive web apps, and Bootloader was a precursor to bundle splitting. People were solving very different problems than what we were solving at that time.

Can you talk about MooTools 2?

Christoph: Oh, man.

Sebastian: MooTools 2 was a rewrite that was supposed to be even cleaner.

Sebastian: I think the problem it created was that it tried to be so clean that everything had an abstraction associated with it. I think that influenced my JSConf EU talk about avoiding abstraction. Eventually it reaches a point where nobody can understand it.

Tom: In hindsight, it seems so not practical.

Christoph: It’s funny you refer to it as MooTools 2. That was actually something that was never attainable. It was always a hypothetical, aspirational goalâ€Š–â€Šthe actual, perfect, end-state of MooTools. MooTools 2 was basically shipped as 1.2, which broke everything.

Sebastian: That’s how we learned the importance of upgrade paths.

Incidentally, we were just idealists building a framework in a vacuum. We learned a lot from that, and we applied a lot of what we learned to React development.

Tom: That’s actually why React today is so incremental, and why every single release provides steps detailing how you got from the last one to this one. Create React App has instructions for upgrading from a previous version, because we didn’t provide a set back then, and it was a nightmare for everyone that used the framework. Incidentally, we were just idealists building a framework in a vacuum. We learned a lot from that, and we applied a lot of what we learned to React development.

Christoph: That’s maybe the takeaway. MooTools definitely taught us a ton of lessons that now help us with projects like React or whatever else we work on in open source.

Do you think that your learnings from MooTools is one of the reasons why open source has been so successful at Facebook?

Tom: Yeah, I started this project called Project Perception. I wanted to change the perception of Facebook in the front-end community, by talking more openly about what we were doing. James Pearce joined Facebook around that time, and started managing an open source team to work on it. We’ve been collaborating ever since.

Then, Jordan Walke handed us React. It was the solution to our problem. It was a very different way of building web apps.

Open source also helps you be intellectually honest with yourself. If you’re putting ideas out there, people will find flaws, they will have other ideas. You can’t just say there are better solutions internally. You can compare it to other solutions in the ecosystem. It forces you to be honest with yourself, and it helps the company as well.

Sebastian: Open source also helps you be intellectually honest with yourself. If you’re putting ideas out there, people will find flaws, they will have other ideas. You can’t just say there are better solutions internally. You can compare it to other solutions in the ecosystem. It forces you to be honest with yourself, and it helps the company as well.

For some reason like twenty years ago games went one way with immediate mode rendering and functional programming, and apps went the other way with imperative, object oriented programming. Then we were starting to see, like with React, a shift back to the direction of declarative, asynchronous, functional programming

Tom: There was actually a lot of push back against open sourcing React. Many could enumerate the costs, but they didn’t really understand the benefits. Even if we tried to sell recruiting as a benefit, it was always an intangible, immeasurable thing. I don’t think we took into account that we would have the ability to push the entire industry forwardâ€Š–â€Što watch the ideas and concepts from React bleed into other frameworks.

I don’t think React was directly competing with any other JavaScript library at the time. I think it was competing with a traditional way of building user interfaces. For some reason like twenty years ago games went one way with immediate mode rendering and functional programming, and apps went the other way with imperative, object oriented programming. Then we were starting to see, like with React, a shift back to the direction of declarative, asynchronous, functional programming, and now, every framework, every view system on every platform has taken these ideas into account. I think we’ll start to see that more and more, over time.

Christoph: It’s also tied back to MooTools, it was something we learned the hard way. The downfall of MooTools if you want to call it that, was because we didn’t collaborate with many people outside of our team. In jQuery they adopted some of our animation code, and we were actually offended by it. Even though it was open source, we thought we knew how to build the perfect system by ourselves. I think the benefit of open sourcing a project, is that it starts with a level of competition, and eventually leads to collaboration.

Compared to MooTools, or just your experience with open source initially compared to today, what’s changed?

Sebastian: I’ve been on the outskirts of a couple of open source communities, and I think there’s a lot of varied management structures. With React, we foster certain people we can trust to stick around by working closely with them. It’s mainly driven by a core team rather than RFCs for example.

But, it’s a process we’re constantly evaluating, like looking at how Ember does it with RFCs.

Tom: I think we all really like Ember’s RFC process. We talk about it internally all the time, and we’ve applied it to the GraphQL project and a few other projects.

Christoph: Yarn as well.

Tom: Also, for MooTools, funding was handled on our own. With React it’s different because Facebook is relying heavily on React. We have something like 36,000 React components checked into our code base, and we’re supporting dozens of existing app in production. We can’t just make huge, sweeping changes like MooTools 2. We have to think about things incrementally. We have to think about upgrade paths.

You can be somewhat assured that if React continues to work well for us, it will continue to work well for you. We have to upgrade ourselves at the same time as you. If we stop using it, if we stop investing in it, you’re going to know early on, and we’re going to have to have a path forward. It’s a bit of a security blanket.

So I think now, we’re hesitant of being a fork in the ecosystem. We see it over and over in open source, everyone has to work together because otherwise you create a much smaller, bifurcating ecosystem.

Sebastian: With MooTools, a lot of big companies relied on it, but we weren’t working for them. People kept contributing to the older versions because they couldn’t upgradeâ€Š–â€Šthere was no sane upgrade path at the time. So I think now, we’re hesitant of being a fork in the ecosystem. We see it over and over in open source, everyone has to work together because otherwise you create a much smaller, bifurcating ecosystem.

What about from the contributor point of view? Do you feel it’s any easier or more difficult?

There is still, for every project, one person associated with it. The creator. On Twitter, they always refer to that one person. I feel like that’s what burns people out. The only reason these projects are so great is because there’s a whole team of people contributing to it, not just one person.

Christoph: There is still, for every project, one person associated with it. The creator. On Twitter, they always refer to that one person. I feel like that’s what burns people out. The only reason these projects are so great is because there’s a whole team of people contributing to it, not just one person. As the one person though, there are still a lot of people who will attack you, or create issues that are difficult if not impossible to deal with. I feel like that hasn’t changed. I honestly also just wish people were nicer in general. That’s something that is difficult to deal with. Maybe that’s just me putting so much of my heart into this open source project.

…you can’t take the emotion out of open source because open source, and this community, is driven by passion, it is a lot of emotion.

Sebastian: I think Dan Abramov put it best when he said, you can’t take the emotion out of open source because open source, and this community, is driven by passion, it is a lot of emotion. My biggest recommendation to those just starting out in open source is to not be tricked by the founder status. Start out by making yourself replaceable. You’re building an ecosystem, it should be able to function without you, otherwise you’ll burn out. That’s one thing John Resig did really well. He was able to grow jQuery to the point where he wasn’t contributing much.

My biggest recommendation to those just starting out in open source is to not be tricked by the founder status. Start out by making yourself replaceable.

Tom: jQuery, in my opinion, did significantly better than MooTools in this regard, and better than React is currently doing. There were so many core contributors to jQuery that all could have taken it in the right direction for the long haul. That’s why I think it’s still so prevalent. Most websites still have jQuery, and it’s still the go-to for all the cross-browser issues.

As far as the emotional side, you have to be able to separate yourself. Separate yourself from the feedback, and from the community, so you can actually do the work. Dan Abramov does this the best. Any time there is any angst, or anger, or negativity, he just combats it with vicious niceness. He’s just so overwhelmingly nice that he wants to get to the root of why you feel a certain way. He has thicker skin than most, certainly thicker than mine.

Separate yourself from the feedback, and from the community, so you can actually do the work.

Christoph: This has totally turned into a group therapy session. Thank you for that.

For someone who is maybe a year into programming, or two years into programming, and they’re just getting into open source today, what is one piece of advice you’d give to them?

Everyone feels intimidated when they first approach a project. […] All you need to do is ask how you can help, and find the project. […] Just stay humble, and start small.

Tom: Everyone feels intimidated when they first approach a project. They don’t know how they can help, but they want to be involved. All you need to do is ask how you can help, and find the project.

Find something that’s a burden for the maintainers. It can be something simple, like closing out duplicate issues, or responding to questions, or helping to prioritize items. Don’t show up wanting to rewrite everything. Just stay humble, and start small.

Sebastian: Don’t get discouraged.

Tom: Yeah, don’t get discouraged.

Always know that maintainers and core teams see almost everything and will remember you. You’re not invisible, so the more you keep contributing, even if they never respond to your issue, they’ll know who you are.

Sebastian: Because there’s often a lot of context, especially on longer-living projects, and not everything is documented.

There may also be very few maintainers to look at issues or port requests. That’s something we’re actively working on. We have metrics tracking that, and are trying to be better, but there are still issues. Always know that maintainers and core teams see almost everything and will remember you. You’re not invisible, so the more you keep contributing, even if they never respond to your issue, they’ll know who you are. When they do need your help, they’ll know what you’ve contributed on, and what context you have. Don’t get discouraged early on.

Christoph: Yeah, I mean I guess people being intimidated goes back to the hero founder status that some people have or perceive. Often it helps to just meet people at conferences. You’ll realize they’re just real people, they’re not the smartest people in the world. They’re just normal people that happened to work on this project. You can start contributing, and get to that point as well.

All of us are here today because we’re very passionate about the web, so we’re curious to hear what keeps you on your toes and excited to keep contributing to making the web better?

I don’t think you should have to learn 3,000 different technologies in order to build a simple app. The web is how I got into software, and I think it’s ultimately how most people could and should get into software.

Tom: For me, I really want to make it easier to build software. I think it’s just extraordinarily difficult to build software in any capacity. I don’t think you should have to learn 3,000 different technologies in order to build a simple app. The web is how I got into software, and I think it’s ultimately how most people could and should get into software. The best thing about web technology is the very low barrier to entry. That feeling of high productivity and rapid iteration with all software development, whether you’re building an image decoder backend service, or you’re building a simple game or app, or a complex VR game. I think the complexities of a particular platform that you want to build for, should be disclosed over time as you encounter them.

Christoph: Yeah, that’s why we are all here, right?

We all know that with too much fragmentation, you can’t do anything, and eventually you end up joining back in. I hope that we’re able to join back in as quickly as possible. We don’t want to lose track of the next layer because technology is fundamentally about building layers, on top of layers, on top of layers of abstraction. We might be focused on the top layer, but someone’s building the next layer, and they can’t do that if our layer is too fragmented. We have to be able to unify, and collaborate.

Sebastian: I’d add that one of the reasons I’m excited about the web in general, is because there’s a tendency for our community to diverge when we have new ideas, but we have to unify at some point. We all know that with too much fragmentation, you can’t do anything, and eventually you end up joining back in. I hope that we’re able to join back in as quickly as possible. We don’t want to lose track of the next layer because technology is fundamentally about building layers, on top of layers, on top of layers of abstraction. We might be focused on the top layer, but someone’s building the next layer, and they can’t too that if our layer is too fragmented. We have to be able to unify, and collaborate.

Christoph: I guess one great thing is that all of this tooling is also written in JavaScript. So, while it’s great that we’re trying to make it easier to build software, the barrier to entry in general is much lower. Everything is written in JavaScript, so whatever you want to work on, you can go and work on that piece and improve it. The prospect that everything could be written in one language is actually really cool. Your React framework, your user code, your test framework, your JavaScript bundler, your package managerâ€Š–â€Šthey’re all written in the same language. So, if you have a problem with one, it’s pretty easy to solve. That’s what excites me.

This project is made possible with sponsorships from frontendmasters.com, egghead.io and Microsoft Edge.

Our sponsors.

This post was originally published on betweenthewires.org

Why use static types in JavaScript? (Part 4)

Preethi Kasireddy — Fri, 09 Dec 2016 17:51:57 +0000

Should we use static types in JavaScript or not?

The first programming languages I learned were JavaScript and Python, both of which are dynamically-typed languages.

But my foray into static types have added a whole new dimension to how I think about programming. For example, even though I found the Elm compiler errors overwhelming at first, defining types and “pleasing the compiler” became second nature, and actually improved my code thinking. Plus, there's nothing more liberating than an intelligent robot telling me when I'm doing something wrong and how to fix it.

Despite the tradeoffs that come with types like verbosity and the upfront investment to master them, the safety and correctness that types add to our programs make these “disadvantages” less of an issue for me personally.

Dynamic typing feels faster and easier, but it sometimes loses ground once you actually try to make a program run in the wild. At the same time, you can talk to any Java developer who's had to work with more complicated generic type definitions and they'll tell you all about how much they hate types.

Ultimately, there's no silver bullet. My personal approach is to favor using types under these circumstances:

The program is critical to your business
The program is likely to be refactored as your needs evolve
The program is complex and has many moving parts
The program is maintained by a large team of developers who need to be able to grasp and understand the code quickly and accurately

On the flip side, I'd consider opting out of types in these types of situations:

The code is short-lived and non-critical
You're prototyping and trying to move as quickly as possible
The program is small and/or simple
You're the only developer

The beauty of being a JavaScript developer today is that because of tools like Flow and TypeScript, we finally have a choice of whether to use static types or good ol' vanilla JavaScript.

Conclusion

I hope this post helped you get a feel for why types matter, how to use them, and most importantly when to use them.

Being able to toggle between dynamic and static types is a powerful tool for the JavaScript communityâ€Š–â€Šand exciting :)

More questions? As always, ping me in the comments to keep the conversation going.

Why use static types in JavaScript? (Part 3)

Preethi Kasireddy — Fri, 09 Dec 2016 17:26:10 +0000

Disadvantages of using static types

Like anything else in life and programming, static type checking comes with its tradeoffs.

It's important that we understand and acknowledge them so we can make an informed decision of when static types make sense and when they simply aren't worth it.

Here are a few of those considerations:

1. Static types require investment upfront to learn

One reason JavaScript is such a fantastic language for beginners is because it doesn't require the student to learn an entire type system before they can be productive in the language.

When I initially learned Elm (a statically-typed functional language), the types often got in the way. I would constantly run into compiler errors related to my type definitions.

Learning how to use the type system effectively has been half the battle in learning the language itself. As a result, static types made the learning curve for Elm steeper than for JavaScript.

This matters especially for beginners where the cognitive load of learning syntax is at an all time high. Adding types to the mix can overwhelm a beginner.

2. Verbosity can bog you down

Static types often make programs look more verbose and cluttered.

For example, instead of:

async function amountExceedsPurchaseLimit(amount, getPurchaseLimit){
  var limit = await getPurchaseLimit();

  return limit > amount;
}

We'd have to write:

async function amountExceedsPurchaseLimit(
  amount: number,
  getPurchaseLimit: () => Promise<number>
): Promise<boolean> {
  var limit = await getPurchaseLimit();

  return limit > amount;
}

And instead of:

var user = {
  id: 123456,
  name: 'Preethi',
  city: 'San Francisco',
};

We'd have to write:

type User = {
  id: number,
  name: string,
  city: string,
};

var user: User = {
  id: 123456,
  name: 'Preethi',
  city: 'San Francisco',
};

Obviously, this can add extra lines of code. But there are a couple arguments against this being a real downside.

Firstly, as we mentioned earlier, static types help eliminate an entire category of tests. Some developers would consider this a perfectly reasonable tradeoff.

Secondly, as we saw earlier, static types can sometimes eliminate the convoluted error handling and in turn reduce the visual clutter of code significantly.

It's hard to say whether verbosity is a real argument against types, but it's one worth keeping in mind.

3. Types take time to master

It takes time and lots of practice to learn how best to specify types in a program. Moreover, developing a good sense for what is worth tracking statically and what to keep dynamic also requires careful thought, practice, and experience.

For example, one approach we might take is to encode critical business logic with types, while leaving short-lived or unimportant pieces of logic dynamic to avoid needless complexity.

This distinction can be tough to make, especially when developers less experienced with types are making judgment calls on the fly.

4. Static types can hold up rapid development

As I mentioned earlier, types tripped me up a bit when I was learning Elm — particularly when adding code or making changes. Constantly being distracted by compiler errors made it difficult to feel like I was making any progress.

The argument here is that static type checking might cause a programmer to lose focus too often — and as we know, focus is key for writing good programs.

Not only that, but static type checkers aren't always perfect. Sometimes you run into situations where you know what you need to do and the type checking just gets in the way.

I'm sure there are other tradeoffs I'm missing, but these were the big ones for me.

Up next, Part 4 (coming soon)

In the final section, we'll conclude with discussing if and when it makes sense to use static types. Stay tuned!

Why use static types in JavaScript? (Part 2)

Preethi Kasireddy — Fri, 09 Dec 2016 17:11:10 +0000

Advantages of static types

Static types offer us many benefits when writing programs. Let's explore a few of them:

1. Detects bugs and errors early

Static type checking allows us to verify that the invariants we specified are true without actually running the program. And if there's any violation of those invariants, they will be discovered before runtime instead of during it.

A quick example: suppose we have a simple function that takes a radius and calculates the area:

const calculateArea = (radius) => 3.14 * radius * radius;

var area = calculateArea(3);
// 28.26

Now, if we were to pass a radius which is not a number (e.g. ‘im evil')…

var area = calculateArea('im evil');
// NaN

…we'd get back NaN. If some piece of functionality relied on this calculateArea function always returning a number, then this result might lead to a bug or crash. That's not very pleasing, is it?

Had we used static types, we could have specified the exact input(s) and output types for the function:

const calculateArea = (radius: number): number => 3.14 * radius * radius;

Try to pass anything but a number into our calculateArea function now, and Flow will send us a handy-dandy message:

calculateArea('Im evil');
^^^^^^^^^^^^^^^^^^^^^^^^^ function call
calculateArea('Im evil');
              ^^^^^^^^^ string. This type is incompatible with 

const calculateArea = (radius: number): number => 3.14 * radius * radius;
                               ^^^^^^ number

Now we're guaranteed that the function will only ever accept valid numbers as inputs and return a valid number as output.

Because the type checker tells you when there are errors while you're coding, it's a lot more convenient (and a lot less expensive) than finding out about the bug once the code has been shipped to your customers.

2. Living documentation

Types serve as living, breathing documentation for both ourselves and other users of our code.

To see how, let's look at this method that I once found in a large code base that I was working in:

function calculatePayoutDate(quote, amount, paymentMethod) {
  let payoutDate;

  /* business logic */

  return payoutDate;
}

At first glance (and the second and third), I had no idea how to use this function.

Is quote a number? Or a boolean? Is payment method an object? Or maybe it's a string representing the type of payment method? Does the function return the date as a string? Or as a Date object?

No clue.

My solution at the time was to evaluate the business logic and grep through the codebase until I figured it out But that's a lot of work just to understand how a simple function works.

On the other hand, if we had written something like:

function calculatePayoutDate(
  quote: boolean,
  amount: number,
  paymentMethod: string): Date {
  let payoutDate;

  /* business logic */

  return payoutDate;
}

It becomes immediately clear what type of data the function takes as input and what type of data it returns as output. This demonstrates how we can use static types to communicate the intent of the function. We can tell other developers what we expect from them, and can see what they expect from us. Next time someone goes to use this function, there will be no questions asked.

There's an argument to be made that adding code comments or documentation could solve the same problem:

/*
  @function Determines the payout date for a purchase
  @param {boolean} quote - Is this for a price quote?
  @param {boolean} amount - Purchase amount
  @param {string} paymentMethod - Type of payment method used for this purchase
*/
function calculatePayoutDate(quote, amount, paymentMethod) {
  let payoutDate;
  /* .... Business logic .... */

  return payoutDate;
};

This works. But it's way more verbose. Beyond verbosity, code comments like this are difficult to maintain because they're unreliable and lack structure — some developers might write good comments, some might write obscure comments, and some might forget to write them at all.

It's especially easy to forget to update them when you refactor. Type annotations, however, have a defined syntax and structure and can never go out of date — they're encoded into the code.

3. Reduces convoluted error handling

Types help remove convoluted error handling. Let's revisit our calculateArea function to see how.

This time, I'll have it take an array of radii and calculate the area for each radius:

const calculateAreas = (radii) => {
  var areas = [];
  for (let i = 0; i < radii.length; i++) {
    areas[i] = PI * (radii[i] * radii[i]);
  }

  return areas;
};

This function works, but doesn't properly handle invalid input arguments. If we wanted to make sure that we properly handle cases where the input is not a valid array of numbers, we'd end up with a function that looks like:

const calculateAreas = (radii) => {
  // Handle undefined or null input
  if (!radii) {
    throw new Error("Argument is missing");
  }

  // Handle non-array inputs
  if (!Array.isArray(radii)) {
    throw new Error("Argument must be an array");
  }

  var areas = [];

  for (var i = 0; i < radii.length; i++) {
    if (typeof radii[i] !== "number") {
      throw new Error("Array must contain valid numbers only");
    } else {
      areas[i] = 3.14 * (radii[i] * radii[i]);
    }
  }

  return areas;
};

Wow. That's a lot of code for a little bit of functionality.

But with static types, we could simply do:

const calculateAreas = (radii: Array<number>): Array<number> => {
  var areas = [];
  for (var i = 0; i < radii.length; i++) {
    areas[i] = 3.14 * (radii[i] * radii[i]);
  }

  return areas;
};

Now the function actually looks like what it originally looked like without all the visual clutter from error handling.

Easy enough to see the benefit, right? :)

4. Refactor with greater confidence

I'll explain this one through an anecdote: I was working in a very large codebase once and there was a method defined on the User class that we needed to update — specially, we needed to change one of the function parameters from a string to an object.

I made the change, but was having cold feet to commit the change — there were so many invocations of this function sprinkled around the code base that I had no idea if I'd updated all the instances properly. What if I missed some invocation deep in some untested helpers file?

The only way to know was to ship the code and pray that it didn't blow up with errors.

Using static types would have avoided this. It would have given me the assurance and peace of mind that if I updated a function and in turn, updated the type definitions, the type checker would be there for me to catch all the errors I missed. All I'd have to do is go through those type errors and fix them.

5. Separates data from behavior

One less talked-about benefit of static types is that they help separate data from behavior.

Let's revisit our calculateAreas function with static types:

const calculateAreas = (radii: Array<number>): Array<number> => {
  var areas = [];
  for (var i = 0; i < radii.length; i++) {
    areas[i] = 3.14 * (radii[i] * radii[i]);
  }

  return areas;
};

Think about how we'd go about composing this function. Because we're annotating types, we are forced to first think about the type of data we intend to use so that we can appropriately define the input and output types.

Only then do we implement the logic:

This ability to precisely express the data separate from the behavior allows us to be explicit about our assumptions and more accurately convey our intent, which relieves some mental burden and brings some mental clarity to the programmer. Without it, we are left to track this mentally in some fashion.

6. Eliminates an entire category of bugs

One of the most common errors or bugs we encounter as JavaScript developers are type errors at runtime.

For instance, let's say our initial application state is defined as:

var appState = {
  isFetching: false,
  messages: [],
};

And let's assume that we then make an API call to fetch the messages in order to populate our appState. Next, our app has an overly simplified view component that takes in the messages (defined in our state) as a prop and displays the unread count and each message as a list item:

import Message from './Message';

const MyComponent = ({ messages }) => {
  return (
    <div>
      <h1> You have { messages.length } unread messages </h1>
      { messages.map(message => <Message message={ message } /> )}
    </div>
  );
};

If the API call to fetch the messages fails or returns undefined, we'd end up with a type error in production:

TypeError: Cannot read property ‘length' of undefined

… and your program crashes. You lose a customer. Bummer.

Let's see how types can help us. We'll start by adding Flow types to our application state. I'll type alias the AppState and then use that to define the state:

type AppState = {
  isFetching: boolean,
  messages: ?Array<string>
};

var appState: AppState = {
  isFetching: false,
  messages: null,
};

Since our API to fetch messages is known to be unreliable, here we're saying that messages is a maybe type of an array of strings.

Same deal as last time — we fetch our messages from the unreliable API and use it in our view component:

import Message from './Message';

const MyComponent = ({ messages }) => {
  return (
    <div>
      <h1> You have { messages.length } unread messages </h1>
      { messages.map(message => <Message message={ message } /> )}
    </div>
  );
};

Except now, Flow would catch our error and complain:


<h1> You have {messages.length} unread  messages </h1>
                        ^^^^^^ property `length`. Property cannot be accessed on possibly null value                                                                  
<h1> You have {messages.length} unread messages </h1>
               ^^^^^^^^ null

<h1> You have {messages.length} unread  messages </h1>
                        ^^^^^^ property `length`. Property cannot be accessed on possibly undefined value

<h1> You have {messages.length} unread messages </h1>
               ^^^^^^^^ undefined

     { messages.map(message => <Message message={ message } /> )}
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ call of method `map`. Method cannot be called on possibly null value

     { messages.map(message => <Message message={ message } /> )}
       ^^^^^^^^ null

     { messages.map(message => <Message message={ message } /> )}
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ call of method `map`. Method cannot be called on possibly undefined value

     { messages.map(message => <Message message={ message } /> )}
       ^^^^^^^^ undefined

Whoa buddy!

Because we defined messages as a maybe type, we are saying that it is allowed to be null or undefined. But it still does not allow us to perform operations on it (like .length or .map) without doing a null check because if the messages value was in fact null or undefined, we'd end up with a type error if we perform any operation on it.

So let's go back and update our view function to be something like:


const MyComponent = ({ messages, isFetching }: AppState) => {
  if (isFetching) {
    return <div> Loading... </div>
  } else if (messages === null || messages === undefined) {
    return <div> Failed to load messages. Try again. </div>
  } else {
    return (
      <div>
        <h1> You have { messages.length } unread messages </h1>
        { messages.map(message => <Message message={ message } /> )}
      </div>
    );
  }
};

Flow now knows that we've handled the case where messages is null or undefined, and so the code type checks with 0 errors. Long dead runtime type errors :)

7. Reduces # of unit tests

We saw earlier how static types can help eliminate convoluted error handling because they guarantee input and output types. As a result, they also reduce the # of unit tests.

For instance, let's go back to our dynamically-typed calculateAreas function with error handling:

const calculateAreas = (radii) => {
  // Handle undefined or null input
  if (!radii) {
    throw new Error("Argument is missing");
  }

  // Handle non-array inputs
  if (!Array.isArray(radii)) {
    throw new Error("Argument must be an array");
  }

  var areas = [];

  for (var i = 0; i < radii.length; i++) {
    if (typeof radii[i] !== "number") {
      throw new Error("Array must contain valid numbers only");
    } else {
      areas[i] = 3.14 * (radii[i] * radii[i]);
    }
  }

  return areas;
};

If we were diligent programmers, we might have thought to test invalid inputs to make sure they are handled correctly in our program:

it('should not work - case 1', () => {
  expect(() => calculateAreas([null, 1.2])).to.throw(Error);
});

it('should not work - case 2', () => {
  expect(() => calculateAreas(undefined).to.throw(Error);
});

it('should not work - case 2', () => {
  expect(() => calculateAreas('hello')).to.throw(Error);
});

… and so on. Except it's very likely that we forget to test some edge cases — then our customer is the one to discover the problem. :(

Since tests are solely based on the cases we think to test, they are existential and easy to circumvent.

On the other hand, when we're required to define types:

const calculateAreas = (radii: Array<number>): Array<number> => {
  var areas = [];
  for (var i = 0; i < radii.length; i++) {
    areas[i] = 3.14 * (radii[i] * radii[i]);
  }

  return areas;
};

…not only are we guaranteed that our intent matches reality, but they are also simply harder to escape. Unlike empirically-based tests, types are universal and difficult to be wishy-washy around.

The big picture here is: tests are great at testing logic, and types at testing data types. When combined, the sum of the parts is greater than the whole.

8. Domain modeling tool

One of my favorite use cases for types is domain modeling. A domain model is a conceptual model of a domain that includes both the data and behavior on that data. The best way to understand how you can use types to do domain modeling is by looking at an example.

Let's say I have an application where a user has one or more payment methods to make purchases on the platform. There are three types of payment methods they're allowed to have (Paypal, Credit card, Bank Account).

So we'll first type alias these three different payment method types:

type Paypal = { id: number, type: 'Paypal' };
type CreditCard = { id: number, type: 'CreditCard' };
type Bank = { id: number, type: 'Bank' };

Now we can define our PaymentMethod type as a disjoint union with three cases:

type PaymentMethod = Paypal | CreditCard | Bank;

Next, let's model our app state. To keep it simple, let's assume that our app data only consists of the user's payment methods.

type Model = {
  paymentMethods: Array<PaymentMethod>
};

Is this good enough? Well, we know that to get the user's payment methods, we need to make an API request, and depending on where in the fetching process we are, our app will have different states. So there's actually four possible states:

1) We haven't fetched the payment methods

2) We are fetching the payment methods

3) We successfully fetched the payment methods

4) We tried fetching but there was an error fetching the payment methods

But our simple Model type with paymentMethods doesn't cover all these cases. Instead, it assumes that paymentMethods always exists.

Hmmm. Is there a way to model our app state to be one of these four cases, and only these four cases? Let's take a look:

type AppState<E, D>
  = { type: 'NotFetched' }
  | { type: 'Fetching' }
  | { type: 'Failure', error: E }
  | { type: 'Success', paymentMethods: Array<D> };

We used a disjoint union type to define our state as one of the four scenarios described above. Notice how I am using a type property to determine which of the four states our app is in. This type property is actually what makes this a disjoint union. Using this, we can do case analysis to determine when we have the payment methods and when we don't.

You'll also notice that I pass in a generic type E and D into the app state. Type D will represent the user's payment method (PaymentMethod defined above). We haven't defined type E, which will be our error type, so let's do that now:

type HttpError = { id: string, message: string };

Now, we can model our app domain as:

type Model = AppState<HttpError, PaymentMethod>;

In summary, the signature for our app state is now AppState<E, D> — where E is of the shape HttpError and D is PaymentMethod. And AppState has four (and only these four) possible states: NotFetched, Fetching, Failure and Success.

I find this type of domain modeling useful for thinking about and building user interfaces against certain business rules. The business rules tells us that our app can only ever be in one of these states. So this allows us to explicitly represent build our app state and guarantees that it will only ever be in one of the pre-defined states. And when we build off of this model (e.g. to create a view component), it comes blatantly obvious that we need to handle all four possible states.

Moreover, the code become self-documenting — you can look at the union cases and immediately figure out how the app state is structured.

Hi, I'm Preethi Kasireddy

Preethi Kasireddy — Thu, 08 Dec 2016 19:14:45 +0000

Hi, I'm Preethi (Rhymes with leafy).
I'm a software engineer based in San Francisco.

Building useful and beautiful software products is what gets me out of bed in the morning — aside from morning workouts, almond butter and my space heater, of course.

Coding is my life, although some of you know me from my former lives as a partner at Andreessen Horowitz, analyst at Goldman Sachs, and industrial engineering student at USC.

When I'm not immersed in JavaScript, React, Elm or Functional Programming, you can find me giving back to the tech community through writing and teaching.

Nice to meet you!

Why use static types in JavaScript? (Part 1)

Preethi Kasireddy — Thu, 08 Dec 2016 18:36:48 +0000

Intro

As JavaScript developers, we don't encounter static types that often.

Does that mean they aren't important? Nope.

Understanding types isn't just a mind-expansion exercise either. They're bound to improve your JavaScript, if you're willing to spend some time looking at their advantages, disadvantages, and use cases.

Interested? Well, you're in luckâ€Š–â€Šthat's what the rest of this post is about!

First, a definition

The quickest way to understand static types is to contrast them with dynamic types. A language with static types is referred to as a “statically-typed language”. On the other hand, a language with dynamic types is referred to as a “dynamically-typed” language.

The core difference is that statically-typed languages perform type checking at compile time, while dynamically-typed languages perform type checking at runtime.

This leaves one more concept for us to tackle: what does “type-checking” mean?

To explain, let's look at types in Java vs. Javascript.

“Types” refers to the type of data being defined.

For example, in Java, if you define a boolean as:

boolean result = true;

This has a correct type, because the boolean annotation matches the value given to result, as opposed to an integer or anything else.

On the other hand, if you tried to declare:

boolean result = 123;

This has an incorrect type, because it explicitly marks result as a boolean, but then defines it as the integer 123.

However, JavaScript and other dynamically-typed languages have a different approach, allowing the context to establish what type of data is being defined:

var result = true;

Long story short: statically-typed languages require us to declare the data types of our constructs before we use them, while dynamically-typed languages do not. JavaScript implies the data type, while Java states it outright.

So as you can see, types allow us to specify program invariants, or the logical assertions and conditions under which the program will execute.

Type-checking simply verifies and enforces that the type of a construct (constant, boolean, number, variable, array, object) matches the invariant that we've specified. We might, for example, specify that “this function always returns a string.” When the program runs, we assume that it will return a string.

The differences between static type checking and dynamic type checking matter most when a type error occurs. In a statically-typed language, type errors occur during the compilation step, i.e. at compile time. In dynamically-typed languages, the errors occur only once the program is executed, i.e. at runtime.

This means that a program written in a dynamically-typed language (e.g. JavaScript or Python) can compile even if they contain type errors that will prevent the script from running properly. On the other hand, if a program written in a statically-typed language (e.g. Scala or C++) contains type errors, it will fail to compile until the errors have been fixed.

A new era of JavaScript

Because JavaScript is a dynamically-typed language, we can go about declaring variables, functions, objects and anything without declaring the type.

var myString = "my string";

var myNumber = 777;

var myObject = {
  name: "Preethi",
  age: 26,
};

function add(x, y) {
  return x + y;
}

Convenient! But not always ideal, which is why tools like Flow and TypeScript have recently stepped in to give JavaScript developers the option to use static types.

Flow is an open-source static type checking library developed and released by Facebook that allows you to incrementally add types to your JavaScript code.

TypeScript, on the other hand, is a superset that compiles down to JavaScript, although it feels almost like a new statically-typed language in its own right. That said, it looks and feels very similar to JavaScript and isn't hard to pick up.

In either case, when you want to use types, you explicitly tell the tool about which file(s) to type-check. For TypeScript you do this by writing files with the .ts extension instead of .js, whereas for Flow you include a comment on top of the file with @flow

Once you've declared that you want to type-check a file, you get to use their respective syntax for defining types. One distinction to make between the two tools is that Flow is a type “checker” and not a compiler. TypeScript, on the other hand, is a compiler.

I truly believe that tools like Flow and TypeScript present a generational shift and advancement for JavaScript. Personally, I've learned so much by using types in my day-to-day.

…Which is why I hope you'll join me on this short and sweet journey into static types.

The rest of this 4-part post will cover:

I. A quick intro to the Flow syntax and language

II. Advantages of static types (with detailed walk-through examples)

III. Disdvantages of static types (with detailed walk-through examples)

IV. So should we use static types in JavaScript or not?

(Note: I chose Flow over TypeScript in the examples in this post because of my familiarity with it. For your own purposes, please do research and pick the right tool for you. TypeScript is also fantastic.)

Without further ado, let's begin!

Part 1: A quick intro to Flow syntax and language

To understand the advantages and disadvantages of static types, we should first get a basic understanding of the syntax for static types using Flow. If you've never worked in a statically-typed language before, the syntax might take a little while to get used to.

Let's begin by exploring how to add types to JavaScript primitives, as well as constructs like Arrays, Object, Functions, and etc.

boolean

Describes a boolean (i.e. true and false) value in JavaScript.

var isFetching: boolean = false;

Notice that when we want to specify a type, the syntax we use is:

number

Describes an IEEE 754 floating point number. Unlike many other programming languages, JavaScript doesn't define different types of numbers (e.g. integers, short, long, floating-point etc). Instead, numbers are always stored as double precision floating point numbers. Hence, we only need one number type to define any number.

number includes Infinity and NaN.

var luckyNumber: number = 10;

var notSoLuckyNumber: number = NaN;

string

Describes a string.

var myName: string = 'Preethi';

null

Describes the null data type in JavaScript.

var data: null = null;

void

Describes the undefined data type in JavaScript.

var data: void = undefined;

Note that null and undefined are treated differently. If we tried to do:

var data: void = null;

/*------------------------FLOW ERROR------------------------*/
20: var data: void = null                     
                     ^ null. This type is incompatible with
20: var data: void = null
              ^ undefined

Flow would throw an error because the type void is supposed to be of type undefined which is not the same as the type null.

Array

Describes a JavaScript array. We use the syntax Array<T> to describe an array whose elements are of some type T.

var messages: Array<string> = ['hello', 'world', '!'];

Notice how we replaced T with string, which means we are declaring messages as an array of strings.

Object

Describes a JavaScript object. There are a few different ways to add types to objects.

We could add types to describe the shape of an object:

var aboutMe: { name: string, age: number } = {
  name: 'Preethi',
  age: 26,
};

We could define objects as maps where we map a string to some value:

var namesAndCities: { [name: string]: string } = {
  Preethi: 'San Francisco',
  Vivian: 'Palo Alto',
};

We could also simply define an object as an Object type:

var someObject: Object = {};

someObject.name = {};
someObject.name.first = 'Preethi';
someObject.age = 26;

However, this last approach lets us set any key and value on our object without restriction, which doesn't entirely add much value.

any

Can represent any type, quite literally. The any type is effectively unchecked, so we should try to avoid using it unless absolutely necessary (e.g. when you need to opt out of type checking or need an escape hatch).

var iCanBeAnything:any = 'LALA' + 2; // 'LALA2'

One situation you might find any useful for is when using an external library that extends another system's prototypes (e.g. Object.prototype).

For example, if you are using a library that extends Object.prototype with a doSomething property:

Object.prototype.someProperty('something');

You may get an error:

41:   Object.prototype.someProperty('something')
                       ^^^^^^ property `someProperty`. Property not found in
41:   Object.prototype.someProperty('something')
      ^^^^^^^^^^^^ Object

To circumvent this, we can use any:

(Object.prototype: any).someProperty('something'); // No errors!

Functions

The most common way to add types to functions is to add types to it's input arguments and (when relevant) the return value:

var calculateArea = (radius: number): number => {
  return 3.14 * radius * radius
};

We can even add types to async functions (see below) and generators:

async function amountExceedsPurchaseLimit(
  amount: number,
  getPurchaseLimit: () => Promise<number>
): Promise<boolean> {
  var limit = await getPurchaseLimit();

  return limit > amount;
}

Notice how our second parameter getPurchaseLimit is annotated as a function that returns a Promise. And amountExceedsPurchaseLimit is annotated as also returning a Promise.

Type alias

Type aliasing is one of my favorite ways to use static types. They allow us to use existing types (number, string, etc.) to compose new types:

type PaymentMethod = {
  id: number,
  name: string,
  limit: number,
};

Above, we created a new type called PaymentMethod which has properties that are comprised of number and string types.

Now if we want to use the PaymentMethod type, we can do:

var myPaypal: PaymentMethod = {
  id: 123456,
  name: 'Preethi Paypal',
  limit: 10000,
};

We can also create type aliases for any primitive by wrapping the underlying type inside another type. For example, if we want to type alias a Name and EmailAddress:

type Name = string;
type Email = string;

var myName: Name = 'Preethi';
var myEmail: Email = 'iam.preethi.k@gmail.com';

By doing this, we are indicating that Name and Email are distinct things, not just strings. Since a name and email aren't really interchangeable, doing this prevents us from accidentally mixing them up.

Generics

Generics are a way to abstract over the types themselves. What does this mean?

Let's take a look:

type GenericObject<T> = { key: T };

var numberT: GenericObject<number> = { key: 123 };
var stringT: GenericObject<string> = { key: "Preethi" };
var arrayT: GenericObject<Array<number>> = { key: [1, 2, 3] }

We created an abstraction for the type T. Now we can use whatever type we want to represent T. For numberT, T was of type number. Meanwhile, for arrayT, T was of type Array<number>.

Yes, I know. It's dizzying stuff if this is the first time you're looking at types. I promise the “gentle” intro is almost over!

Maybe

Maybe type allows us to type annotate a potentially null or undefined value. They have the type T|void|null for some type T, meaning it is either type T or it is undefined or null. To define a maybe type, we put a question mark in front of the type definition:

var message: ?string = null;

Here we're saying that message is either a string, or it's null or undefined.

We can also use maybe to indicate that an object property will be either of some type T or undefined:

type Person = {
  firstName: string,
  middleInitial?: string,
  lastName: string,
};

By putting the ? next to the property name for middleInitial, we indicate that this field is optional.

Disjoint unions

This is another powerful way to model data. Disjoint unions are useful when we have a program that needs to deal with different kinds of data all at once. In other words, the shape of the data can be different based on the situation.

Extending on the PaymentMethod type from our earlier generics example, let's say that we have an app where users can have one of three types of payment methods. In this case, we can do something like:


type Paypal = { id: number, type: 'Paypal' };
type CreditCard = { id: number, type: 'CreditCard' };
type Bank = { id: number, type: 'Bank' };

Then we can define our PaymentMethod type as a disjoint union with three cases.

type PaymentMethod = Paypal | CreditCard | Bank;

Payment method now can only ever be one of these three shapes. The property type is the property that makes the union type “disjoint”.

We'll see more practical examples of disjoint union types later in part 2.

Alright, almost done. There are a couple other features of Flow worth mentioning before concluding this intro:

1) Type inference: Flow uses type inference where possible. Type inference kicks in when the type checker can automatically deduce the data type of an expression. This helps avoid excessive annotation.

For example, we can write:

/* @flow */

class Rectangle {
  width: number;
  height: number;

  constructor(width, height) {
    this.width = width;
    this.height = height;
  }

  circumference() {
    return (this.width * 2) + (this.height * 2)
  }

  area() {
    return this.width * this.height;
  }
}

Even though this Class doesn't have types, Flow can adequately type check it:

var rectangle = new Rectangle(10, 4);

var area: string = rectangle.area();

// Flow errors
100: var area: string = rectangle.area();
                        ^^^^^^^^^^^^^^^^ number. This type is incompatible with
100: var area: string = rectangle.area();
               ^^^^^^ string

We tried to define area as a string, but in the Rectangle class definition we defined width and height as numbers, so based on the function definition for area, it must be return a number. Even though we didn't explicitly define types for the area function, Flow caught the error.

One thing to note is that the Flow maintainers recommend that if we were exporting this class definition, we'd want to add explicit type definitions to make it easier to find the cause of errors when the class is not used in a local context.

2) Dynamic type tests: What this basically means is that Flow has logic to determine what the the type of a value will be at runtime and so is able to use that knowledge when performing static analysis. They become useful in situations like when Flow throws an error but you need to convince flow that what you're doing is right. I won't go into too much detail because it's more of an advanced feature that I hope to write about separately, but if you want to learn more, it's worth reading through the docs.

We're done with syntax

We covered a lot of ground in one section! I hope this high-level overview has been helpful and manageable. If you're curious to go deeper, I encourage you to dive into the well-written docs and explore.

With syntax out of the way, let's finally get to the fun part: exploring the advantages of using types!

Chris Coyier

Preethi Kasireddy — Thu, 17 Nov 2016 00:31:29 +0000

I am the co-founder of CodePen.io, a well-known collaboration “playground for the front-end, creator of CSS-Tricks, a site dedicated to teaching all things web design and development, and the co-host of Shop Talk Show, a live podcast about front end web design, development, and UX.

Tell us a little bit about yourselfâ€Š–â€Šwhere did you grow up and what was your childhood like?

I’m a pure Midwesternerâ€Š–â€Šas I sit now, I’m in Milwaukee, Wisconsin which isn’t too far from where I grew up in Madison, Wisconsin.

I had a super normal (at least my version of normal_)_ upbringingâ€Š–â€Ša middle class family just living in a small town. I got a computer at a young age, my ideas were encouraged, I had an opportunity to get a good education and took it. I feel like the cards lined up for me in an interesting way. In high school, I took a programming class that excited me, and eventually I went to college for it.

Tell us about your first programming experience.

It took until a high school elective for me to get legitimate programming experience. I had a teacher named Mr. Scott, who was such a positive influence. In his class, the language that I took to the most was called Turbo Pascal. Mr. Scott taught us the basics of course, but he encouraged us to get into real projects right away. I remember the very first significant product that I worked on was just a Pascal version of the Game of Life.

The game ended up being published in a little magazine and I was totally hooked after that.

In your podcast you mention later pursuing a computer science degree in college, but ultimately switching to some kind of art major. Can you tell us about that transition, and how your skills, interests, and career evolved?

Laziness, selfishness, and jealousy made me switch to art, but it actually turned out to be the right choice.

After all the positive experiences I had in high school, when I went to college I knew immediately that I wanted to major in Computer Science. The degree was called Management Computer Systems, which should have been a red flag. Not surprisingly, it turned out to be more about the business-side of programming.

I was learning languages that I wasn’t interested in, and the teachers weren’t especially engaging. It was a bummer. It didn’t slaughter my dream of becoming a programmer, but I was definitely a little disenchanted with the idea. I was still a full-blown computer nerd on the side, though.

In the meantime, I was living with a ceramics major and he had this great community of art students. I’d tag along with him to art parties, and I’d go hang out with him in the studio at the art building. I truly believed that his life in college was way more awesome than mine. He had found a real passion, he had found a better community. Honestly, I was pretty jealous of his college life.

Eventually, I made the decision to switch from computer science to art. I had a feeling that what I studied in college didn’t matter that much, and that life would ultimately work out.

My parents are usually very supportive of me, but when I told them I dropped Computer Science they were mad. They were worried that I was throwing away my college career. But, I just marched right into the administrative office and told them I was switching.

The good news is that I took to it right away. I loved it. It was the best thing I ever did. I graduated with a BA in ceramics from the University of Wisconsin-Whitewater.

Chris graduated with a BA inÂ Ceramics

After majoring in art, what did you do between graduation and starting CodePen? Did you have a bunch of jobs in between or did you have an idea of what you wanted to do?

It turned out to be a hard to just jump in and get hired as a designer. I didn’t have enough confidence.

Kind of. There is a decent span in there.

When I left college, my fears were realized. I had no idea what I was actually going to do. I was motivated to get a job right away, and I applied to a bunch of places, but I didn’t have any experience.

It turned out to be a hard to just jump in and get hired as a designer. I didn’t have enough confidence.

Luckily, my mom was in the printing industry and knew a lot of people around town. So I ended up going into the digital printing press after college. It was pretty technical work, and it was interesting in its own way. I’d take designs and turn them into metal plates to go on the presses. It’s a kind of artâ€Š–â€Šyou can think of it like the CSS of print, where you take a design and turn it into reality. So, there’s actually a connection there, between printing and programming.

But it wasn’t that interestingâ€Š–â€ŠI knew I wasn’t going to make a career out of the printing press, because I wasn’t entirely happy doing it. There isn’t a fun community around it. It was really just a job.

On the side, I was into music. I was playing in a Bluegrass band. One day I decided our band needed a website, and that became an excuse to make a website. That was when I began to realize how cool the web is. I wanted to jump in. Then, just through a stroke of luck, there was an opening at a really small shop for an inexperienced web designer and I snatched it up. That’s how I became a professional web designer overnight.

You were also at a company that was acquired by SurveyMonkey. Was that when you decided to move away from Wisconsin?

Right. That was the part that I skipped over. After working at the agency in Madison I ended up working for a company called Wufoo in Tampa, Florida. I moved down there to work with them, which is probably one of the best decisions I ever made.

It was a great team. I’m still friends with everyone. They were building something great, they thought deeply about what they were doing and how they were working. They were good to the people they worked with and their customers. They were eventually acquired by SurveyMonkey, which turned out to be a positive outcome.

In fact, I met my two co-founders, Alex Vazquez, and Tim Sabat at Wufoo. We worked there together, and then at SurveyMonkey, and now they’re my co-founders at CodePen. We’ve been working together for a long time.

The foundingÂ team

How did you end up discovering the problem that you wanted to solve with CodePen?

Well, it was right at that time actually. I worked as a web developer for the agency for many years. In 2007, I decided to launch CSS-Tricks. I was learning it quickly, and I was really into it, and I just wrote down what I was learning using CSS-Tricks as the medium. It’s still around today. In fact, I published an article on CSS-Tricks this morning.

For most of my work with CSS-Tricks, I would make a demo, put it in a folder, and FTP it up to the CSS-Tricks server. Then, when I wanted to show a demo, I would just link to the folder on my server. It worked fine, but it requires the person reading to view source, or use the dev tools, and dig around and find out what’s going on.

Eventually, tools like JSbin and JSFiddle made it possible to see the demo, look at the code, and change the code while the demo plays and changes. It was genius.

So at a point I thought I could do that too. It was a project that I could wrap my head around. I wanted to make my own version of those apps, and I wanted to host it myself and have control over features. That was the idea and the spark behind CodePen.

A common fear when it comes to starting something, is a fear of being financially unsustainable. We’re curious to hear how you managed to become financially sustainable with CodePen, and how long that took?

Even if what you do fails, you learn a lot […]

CSS-Tricks was making some money, and I had written a book about WordPress that was doing okay. So, it was easier for me to get started. My other two founders, Tim and Alex, also had some savings to lean back on.

To me, tech doesn’t seem particularly risky. Even if what you do fails, you learn a lot, which makes it easier to get snapped up by some other company down the line.

So, we launched CodePen totally bootstrapped. Our only expenses were server costsâ€Š–â€Šso that’s another advantage of tech, your cost are pretty low compared to other businesses.

When you first starting building the product, was the idea of monetization on your mind? If not, at what point did it become important to your strategy?

The whole idea was to make some money at some point. So, our plan was to build it, make it super cool, and then have PRO accounts.

We launched CodePen out of beta in June 2012, starting with a freemium model and then had PRO plans by December of that year. The majority of it right now is still selling PRO plans.

We also do some advertising as well, because of how many views we get. We have a job board tool too. We fully intend to continue to monetize CodePen, but hopefully it’ll remain a cool freemium product that people pay for because it provides value.

How do you decide which features should be free versus PRO? How do you get that balance right?

Monetization is the hardest stuff to think about, period. […] In the end, how do I know for sure that we made the right choice? I don’t.

Monetization is the hardest stuff to think about, period. You get so much conflicting advice too. It’s crazy.

The PRO features we decided to offer are the features that we felt the users needed.

One of our PRO features is collaboration mode. It’s similar to Google Docs where you get multiple cursors with up to six people on higher plans and you can all code simultaneously. People use it for interviewing, for working together, to teach, etc. It took a lot of effort to build and so to us, it seemed like a very obvious thing to charge for.

With some of our PRO features we look around and see what other people are charging for. With something like GitHub they charge you the minute you want something private. They figured out that privacy matters to some people, and probably validated that in some way, so that’s a feature we decided to charge for on CodePen.

About a year ago, we did take money for CodePen. We had talked to some VCs prior to that as well a few years back. One of them was just brimming with advice and told us to forget everything, and make all PRO features free. He told us that what matters most is making CodePen the best at what it doesâ€Š–â€Ša premium service that everybody uses.

It actually seemed smart at the time. We figured he was rightâ€Š–â€Šif we gave away all the PRO features we could gain some serious momentum. We thought that people would use it and think about it differently.

We had a branch ready to make private pens a free product. We were about to release it, but we got cold feet. We felt we were cannibalizing ourselves in a way. We were considering taking away one of the reasons users had to upgrade, one of the only ways we were making money.

So, we sent out a survey to gauge why people upgraded. A lot of people said privacy.

Our cold feet turned into killing that branch completely. If we had done it, we would have removed one of the top reasons people pay us at all.

In the end, how do I know for sure that we made the right choice? I don’t. I’m sure there are choices that would have made us more successful than we are right now. There are probably just as many that could have screwed it all up too. Who knows?

But, the VCs idea was to build it to sell it. But we were excited about building it. None of us had even really considered selling it.

It’s a difficult part of business, especially freemium businesses. Freemium businesses are either a complete hit or a complete miss. It’s all about whether or not you can figure out what customers care about most, and what you should charge for. Very few businesses could strike the right balance between giving too much value to the customer and too little.

Yeah, exactly. In a sense one of the cool parts of CodePen is that it’s a community. There are a million members of CodePen and they talk to each other and meet each other. We even had a couple get engaged through CodePen! We have real life meet-ups all around the world. There are freelance groups that started on CodePen, and have teams that work together, meet, and operate together on CodePen.

It’s a community that gives us value. If somebody makes something really cool and puts it on CodePen, it’s basically free advertising for CodePen. They are proud of their work and they’re sharing it. That’s why our marketing budget is zero because people market for us.

But if there are features that we work really hard on, then it just feels right to charge to for them.

We recently hired four people after we took funding. We’re all working really hard on a new feature that will probably be locked under PRO. There’s just too much work going into it. It requires a lot of ongoing maintenance, more servers, real costs that necessitate charging for it.

Can you walk us through a day in the life of building CodePen?

We’re always working to do right by our existing customers.

Sure. I’m sure both of you know from your own interesting backgrounds that everyday, we have no idea what’s going to happen. The only consistent thing is communication. We live in Slack, there’s always a lot of talking.

We also have to make sure we’re listening to our customers. Listening to them means reporting bugs, fixing bugs, that kind of work.

We have to balance our time between building new things, and maintaining what’s already there. We’re always working to do right by our existing customers.

I do it all. I actively work on the product. The people that we hired probably spend a lot more time in the code base than I do, but I’m in it everyday. We’re too small to have any structure. There aren’t any managers or anything, so everybody is in the code base working, talking, writing emails,writing blog posts and doing support. That’s a day in the life.

What’s one mistake you’ve made in building CodePen that you hope to never make again?

It’s hard to know if the decisions you’ve made are the right decisions. Maybe there was a decision that I made that was entirely wrong, and I don’t even know it yet.

A lot of people struggle with this. I’m struggling with it right now, and we talked about it earlier, but it’s hard to know if the decisions you’ve made are the right decisions. Maybe there was a decision that I made that was entirely wrong, and I don’t even know it yet. You can’t A/B test the past.

That near miss of making all of our PRO features free, that feels like something I’m glad we didn’t do. But it’s hard to say.

We took VC, but maybe we’ll just be a lifestyle business, which seems like the last thing VCs want to hear. No VC one wants to hear that. Lucky for us we took money from the original two founders of Wufoo. They’re friends and we’re trying to do right by them, but they’re not down our throats pushing for epic growth.

When we talked to actual VCs, we could tell they were turned off by our trajectory. We want to grow, but we’re not interested in taking buckets of money, making everything free, and trying to be bought by a company like Adobe.

But is that a mistake? Maybe we should have taken a bunch of VC, maybe we are well poised to do that and I’m screwing everything up by not. I don’t know.

Can you talk about one or two difficult periods that you had to go through in building CodePen and how you overcome those struggles?

You have to build a company that people care about. I think that’s important to the people we hire, work with, and like to work with. They need more than just a punch card and a promise of some options.

The struggle is real. One of our early struggles was deciding to do this at all. Some of us had families, we all had responsibilities. It’s not easy to leave a comfortable job like SurveyMonkey, especially when the company is doing so well, and the stock options are good. You roll in at 10 o’clock, and eat gummy worms all day. Why would you want to leave that?

But, we’re well passed that now.

If I’m being totally honest, we’re going through a hard time right now. We grew to nine people, and that’s been a big change. I’m not a manager, but I’m trying to steer the ship. It requires a very different skill set. It requires understanding our employees, and giving them what they need. Some need a lot more feedback than others, some need to be left alone. I know I’m dropping the ball on some of that stuff.

You have to build a company that people care about. I think that’s important to the people we hire, work with, and like to work with. They need more than just a punch card and a promise of some options. We’re trying to figure out how to give them more purpose.

I’ve alluded to this big feature that’s coming out, but I can’t promise anything, or tell you anything. I don’t like to bum people out if it takes forever or doesn’t go as planned. No good comes from promising things you can’t deliver.

This feature though, is a big one. It’s taken a long time to figure out and there have been blockers right and left. I think, occasionally, some moral issues have come up when we’re not making as much progress as we should. There’ve been a couple of dates that we’ve set and not made that I know have bummed people out.

We’re not failing, people aren’t quitting. But it’s been a tough period. I suspect it’s going to work out, though.

What would you consider a successful outcome for CodePen?

I’m absolutely stoked to keep working here, and honestly I hope we can do it forever. If it’s the last job I ever have, that’s fine by me.

I hope we just get to keep on going. We don’t have the startup dream of shooting for incredible growth and selling. Typically, that doesn’t end well for the people who use the product. We’d rather keep building the product we want to exist, and adding to the community we want to be a part of.

I can imagine still working here a decade from now. I really like it. I think it’s a great idea, and we have a list of exciting ideas for the future. I like the community around CodePen too. I’m absolutely stoked to keep working here, and honestly I hope we can do it forever. If it’s the last job I ever have, that’s fine by me. That’s what I’d consider a success.

But, if we could sky rocket right now I’d be down with that. I wish we were killing it harder than we are, because I’d love to keep hiring. We just don’t have the money for that, though. I’d love to eventually double or triple our team. I want to be a manager. I’ve never had that opportunity, and I would love to have it one day.

Have you ever experienced burnout as a founder?

The community helps me, the people around me help me…I have hobbies, I go on vacation. I have enough of a well-rounded life that I don’t think I’m a high risk for burnout.

Not as extreme as some people have. Burnout is a hot topic these days. True burnout would be to just quit, you just don’t do anything anymore. I’ve never totally burned out.

I think I’m lucky in that way. The community helps me, the people around me help me. I’m lucky that I have multiple projects. I have CodePen but I also work on CSS-Tricks, I have a podcast where I talk to people.

Chris enjoys working on his podcast CodePenÂ Radio

I have hobbies, I go on vacation. I have enough of a well-rounded life that I don’t think I’m a high risk for burnout.

How do you build a culture with remote teams?

Positivity is also really important to CodePen and our team embraces it. […] It feels safe here, comfortable, and that’s how good communities are born.

I probably think about this a little too much. I like to shower people with praise. I like to talk things out as a team and find those small teaching moments. Culture comes from thatâ€Š–â€Šfrom moments where you think about how to approach a situation and why, as a team. I also encourage people to pay attention to industry news, and throw their two cents in. Those are culture-building moments.

The CodePen team hard atÂ work

Positivity is also really important to CodePen and our team embraces it. We never let off a negative vibe, we never discourage each other, especially not publicly. We have an inclusive spirit. That’s just vital to me. It feels safe here, comfortable, and that’s how good communities are born.

Who are your programming heroes?

It’s hard for me to look at random people in the industry and consider them programming heroes. […] My heroes are the the people I work with directly.

When you work directly with someone and experience their genius on a day-to-day basis, they feel like the best programmer in the world, and that’s how I feel all the time.

It’s hard for me to look at random people in the industry and consider them programming heroes. Certainly they’re heroes in some sense. I can look at their accomplishments and be impressed, but it’s not as personal. They don’t feel as real to me as the people I work with everyday.

Tim Holman, who we hired, came to us from Tumblr. He did amazing stuff while he was there, but was kind of CodePen famous before he even started working with us. He’s such a smart guy. He doesn’t care about technology, he just cares that the thing he builds works well. He doesn’t care if we suddenly switch to React, he just cares that what we make is cool.

Rachel Smith, another recent hire, was at an incredible advertising agency. She’s just a genius. She’s like VIP on our team. It’s amazing the productivity and the struggles she can battle through. It’s admirable. She’s just an absolutely incredible programmer and person.

Another fellow we hired named Jake Albaugh, also genius. I wish my brain worked the way his brain works.

I struggle with that actually. Sometimes I feel like the least useful person at CodePen. I still add value in other ways, but I’m not useful in the same sense as they are.

So yeah, my heroes are the the people I work with directly. They’re my heroes.

CodePen team

This project is made possible with sponsorships from frontendmasters.com, egghead.io and Microsoft Edge.

Our sponsors.

This post was originally published on betweenthewires.org

What is Between the Wires

Preethi Kasireddy — Tue, 01 Nov 2016 10:55:39 +0000

Between the Wires is an interview series featuring those who are building developer products. Here we hope to spread ideas, encourage innovation, and offer a behind the scenes glance at the creation of developer products.

Who we are

Vivian Cromwell

For eight years Vivian Cromwell worked on developer products at Google including Chrome, Cloud, and Social, focusing on developer experience and tools. While at Google, she built several teams from the ground up, alongside world-class engineers. She recently left Google to start a mobile commerce startup (getchop.io) where she is learning first hand what it takes to build something from scratch — both the good and the bad. As a passion project, she also works as an adviser for startups in the developer space as a way to pass along what she has learned. Through her various experiences, she has become increasingly interested in understanding how developer products and projects are built. From this interest came Between the Wires, an interview series to share maker stories with like-minded individuals.

Preethi Kasireddy

Preethi Kasireddy is currently a software engineer at Coinbase, though her path to this point has been circuitous. After studying Industrial and Systems engineering in college, Preethi went into investment banking at Goldman Sachs, and later became a venture capitalist at Andreessen Horowitz. While there, she interacted with thousands of developers and founders on an array of products. She was fascinated by what they did, and how they did it. After watching their products change the world, she began to study code so that she too could build something that mattered. What started as a pastime quickly grew into a deep passion for programming. Soon after, she left Andreessen Horowitz to become a full-time coder, and to build the foundation needed to be a maker. Between the Wires is a natural extension of her fascination with makers, and offers a place to collect some of the developer stories she initially found so inspiring.

Why we care

We felt that what the community was missing were the raw details and inside scoop on what it takes to be a maker and build a valuable product from ground-up. We care about questions like:

What motivates makers to build developer products?
What lead them to the path they are on today?
What was their first experience with coding?
What are the various ways to get funding for the projects?
Is it possible to work on open source projects in a financially sustainable way?
Given the rapid pace of innovation in the developer ecosystem, how do they make sure a product stays relevant and useful for years?

Moreover, we also want to focus on some of the harder questions like:

What are some of the toughest challenges that developers face in running their business?
Did they fear they would fail? How do they overcome that?

With these questions in mind, we started a series of interviews with makers. Our goal with these interviews is to share experiences that are often hidden behind a product or Github repo so that everyone, including aspiring makers, can learn from it.

We will be releasing the first set of our project starting with the story of Guillermo Rauch, CEO of zeit.co.

We hope this project inspires developers who want to build something. We hope to offer a transparent look into the various challenges and hardships these makers have faced for the sake of their dream. And we hope that it gives others the courage and motivation to do the same.

We would love to hear your feedback. If you have a suggestion for a maker you’d like to hear from, please fill out this form.

A big thank you to our writer Katie Crowley who helped us polish the articles, and to Marc Hemeon who quickly doodled the logo concept for us.

Stay hungry, stay foolish. Keep on building.

Vivian & Preethi

This project is made possible with sponsorships from frontendmasters.com, egghead.io and Microsoft Edge.

Our sponsors.

This post was originally published on betweenthewires.org