Too many tools and frameworks!

Key Takeaways

hello beautiful people today's video is going to be all talk I am going to talk about the frustration that a lot of people in the JavaScript community and the community in general feels about tools and Frameworks how there are so many of them Gul grun react angular Ember Highland underscore low Dash mouth bacon power a lot of people people are feeling overwhelmed we're going to talk about this frustration and what to do about it and I know that a lot of people here expected another episode in the functional programming with JavaScript series however um gothenberg where I live had an earthquake which happens once in every 100 years here which caused a surge which caused my monitor to fry and it is difficult to make screen costs without a screen so I figured I'd take the opportunity to make this one first I want to talk about this frustration in a bigger sense is the fact that we have so many tools and Frameworks a problem and is this a problem just with JavaScript I think the answer to both of those questions is no this debate has been ranging on and on in the JavaScript Community for a while and a few days ago Adam Morris dug up an interesting quote by a man named Theodore Sten if you don't know who sturgeon is he was a uh science fiction writer and he was one of those authors that we all aspire to be as uh as creators he was extremely productive he authored 200 pieces or something like that and he started writing in 1939 in 1939 science fiction was not a respected form of literature it had this position that comic books held uh a while back it was not widely available in libraries and it was just not considered proper literature in 1958 sturgeon published an article I'm going to read a bit from it now so that I get it right I repeat sturgeon's Revelation which was rung out of me after 20 years of weying Defense of Science Fiction against attacks of people who used the worst examples of the field for ammunition and whose conclusion was that 90% of Science Fiction is crud using the same standards that categorize 90% of Science Fiction as trash crud or crap it can be argued that 90% of film literature consumer goods Etc is crap in other words the claim or fact that 90% of Science Fiction is crap is ultimately uninformative because science fiction conforms to the same trends of quality as all other art forms let me read that last part again because it's really important in other words the claim or fact that 90% of Science Fiction is crap is ultimately uninformative because science fiction conforms to the same trends of quality as all other art forms you have to understand that there is going to be a ton of Frameworks and a ton of tools and 90% of it is going to be cracked and that 90% is going to be a big pile of crap because JavaScript is an insanely popular language this is also strengthened by the fact that JavaScript is in the Forefront of code sharing GitHub is a completely new phenomenon in programming that makes it super super super easy to share code and JavaScript is definitely in the Forefront of using GitHub JavaScript also has extremely good packaging Solutions it's very very easy to use other people's code in your code this was easy before when we just had script tags but now with npm that is a super power so no this is not a JavaScript problem it just looks big bigger in JavaScript because JavaScript is bigger and is much better at sharing code if your language does not have this problem it is either because it's not a very popular language or because it doesn't have as powerful code sharing as JavaScript does and if your language is popular and growing it will get this problem because it will get a good package manager because having a good package manager is just too good a feature to not have yes we have completed the introduction that means it's time for stretching all right so we have a lot of tools and Frameworks being created and 90% of them are not very good but that's not a problem if we can identify which 90% And just use the 10% that are good A lot of people try to solve this by looking for the best right work the best tool and to do that they look at either Authority or popularity or a combination of the two popularity might mean that you look at just the number of stars on GitHub and use the popular one because yeah people seem to use that and it doesn't seem to cause them too much pain so we'll use that that seems good or you can look at the publisher that is what is happening with angular people have been looking at oh Google push this out then it it's probably good because Google knows how to build software so angular is in this position today and if you define the best framework as the one that is blessed by Authority and is also popular then we have it we have angular finding Tools in this way is not new in fact like all things in computer science we've done it since the' 70s it began with the sap which is this God software to build Business Systems another example is SharePoint which is this Big Blob of software that can be used for almost anything that is very heavily used in the Enterprise they are popular and they are blessed by Authority and therefore a lot of people use them and you can find Developers for them and it's just a circle that enforces itself and when you work with these tools um well it's not exactly like they're spraying rainbows right and that is because the concept of best tool is not as simple as that if I ask you which tool is the best the hammer or the screwdriver when answering that you would have to say well I I don't know what we're building so I can't really say I I guess I would probably need both maybe when you don't know what you're going to be doing but you still pick a tool you need a very generic tool you need a leather man and a leather man is is is pretty okay it can you can you can screw screws with it because it has a screwdriver a tiny one but it works and you can use it to hammer in Nails because it it's heavy but when you use it it just doesn't feel just right so when you working with one of these God Leather Man Frameworks is that it constantly feels a bit off it feels like you constantly have to coers the tool into doing what you want you have to fool it a bit hack it a bit the framework has made these assumptions that your app just doesn't fit cleanly into the framework supports both round and square pegs but your pegs are starshaped so what I'm trying to get to here is that if you pick your tool before you know what you are building you are per definition going to have to pick a mediocre tool because the general tool is Never As Good As the tool that is specifically tailored for your use case hence the moral of the story is you need to know what you are building before you pick your tools woo we are 8 minutes and 30 seconds into this video which means I think it's time for a break uh go get a cookie in the kitchen that's what I'm going to do I suggest you do the same there were no [ __ ] cookies in the kitchen so we need to know what we are building in order to pick the right tool but we don't know what we're building how how can we find that out a lot of people try upfront analysis you have a business plan or maybe some kind of spec some designs and stuff and you sit down for a couple of hours or maybe even a couple of days and just think really hard about what's going to happen what kind of databases could be useful for this and how much load will this get and how is the data structured and all that kind of stuff the problem is that you will fail we humans think that we are really good at predicting in the future and we are better at it than squirrels or dogs we have these big brains that are almost exclusively dedicated to planning movement which can be generalized into predicting the future but we are not as good as we think we are flicker uh is a uh photo sharing service that just took the World by storm when it launched uh it's not as big nowadays but it was enormous back in the day and a fun fact about flicker is that it actually started as part of a tool set for a massively multiplayer online game called game never ending and it turned out that flicker was a much more viable product than the uh game that they had built you might have heard about Mt gax uh it was the uh by far the biggest Bitcoin exchange for several years and it just crashed a year ago or so uh and the name MTX when I first heard of it I figured it was Mount Cox like it was probably some you know uh famous mountain or something but no it turns out that MTG stands for Magic the Gathering online exchange so it used to be a a a forum for trading Magic the Gathering cards and they implement Ed a feature for uh buying and trading them with Bitcoin and that feature just took off and they decided that oh this this feature that we accidentally built uh is much more feasible as a business and of course we have bourbon bourbon was the name of the company that built Instagram and bourbon was also the name of their product that they built which was his cool location sharing service and they spent a ton of time building that and then they just realize that hey uh we should build this image sharing thing instead which turned into Instagram so paradoxically you need to build something before you know what you're building and this is why we have prototypes and MVPs and whatever you like to call them something that you build in order to test out your idea and when you build your MVP or prototype the best framework that you can use is the one you know best pick whatever tool that you and your team is comfortable with and run with that because since you cannot be sure of what you're building whatever tool that you pick is going to be badly adapted for what you're doing and if you're going to work with a tool that is badly adapted for what you're building you might as well use one that you are very familiar with so you that you know all the nooks and crannies and that you know how to bend into the shape that you want even though it's not well for that fast forward to the future you now have validated your MVP it's up and running you have a few customers and people seem to like it and it seems to be working fine because you have a lot of customers now you know that okay things are probably not going to change around much around here we're not going to do uh flicker or bourbon or uh Mount GX we now know what we are building now you can look at your product and pick the best technical solution and this is what Twitter did nowadays Twitter has a backend built in Scala with a uh pretty Advanced logging back end uh using Cassandra and a bunch of very specific uh cool systems that they invented and have open sourced but that is not the way they started out they started out with Ruby on Rails in hindsight Ruby on Rails is just a horrible choice for a service such as Twitter which is essentially a messaging solution but one thing that Ruby is good at is being very flexible it can be it's one of those big ass God leather mans that can be used to build almost anything in a sort of okay way and Ruby on Rails was not picked because of some sophisticated technical analysis rails was picked because that's what the developers knew and the developers by the way did Twitter as the side project from their uh their normal business so this was not something that they were working fulltime on it was just something oh this was cool and when you have very little time and the thing that you are building is super speculative and might be thrown away or being changed do something completely different it made a ton of sense to just use something that was Ultra flexible that they also knew very well okay so you do your analysis of your MVP and you now have a really good idea about what problems that the current generic solution has and where you want to take this and what problems you see in the future because you you can interpolate sort of from the problems that you're having now how they can become bigger now is the time to start research you describe what it is you're building to other programmers ask them if they have built an app like this and what they used and what uh what learnings they had from using those tools and what what recommendations they have you Google around trying to find what kind of tooling that you need this is a process that is almost completely impossible if you don't know what your building because you would have no criteria to uh to judge the the quality of the tools that you are picking the only things that you could rely on before was popularity and Authority but now when you know what you're building you know that your application needs nails and not screws you know that you need messaging not storage like Snapchat for instance when you start reading the documentation of a new tool you will be able to very quickly dismiss that tool because because you know what your needs are and this means that you will be able to research tools very very fast you will not have a problem picking your tools because you will know what tool you're looking for and we have reached the end of this Monday's video we have talked about how quantity in tooling and Frameworks is just a fact of life to create masterpieces you just have to create a lot of drafts we've talked about how there is no such thing as the best tool and how you should stop looking for the Godlike Leatherman we've talked about how you should understand what you are building before picking a tool but we also talked about how you can't understand what you are building before you built it so you need to make a MVP or prototype and you should do that in the tool that you and your team knows best once you have something that actually has bunch of customers that won't change around a lot so then it is time to analyze it then you research tools and Frameworks and when you do that at that point it will go much better because you know what you're looking for I would love to hear from you either in a comment down below or uh @ mpj me on Twitter tell me what you thought about this format talking only or just ask me something random or tell me what the next episode should to be about and speaking of which do not miss that episode you must subscribe by clicking the face here and until next Monday stay curious