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 gulp grunt react angular
ember Python underscore low – mouth
bacon power a lot of people are feeling
overwhelmed we’re going to talk about
this frustration and what to do about
and I know that a lot of people here
expected another episode in the
functional programming with JavaScript
series however umm-hmm Gothenburg 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
screencasts without a script 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 raging 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 sturgeon if you don’t know
who’s sturgeon is he was a science
fiction writer and he was one of those
authors that we all aspire to be as 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
formal bit richer it had this position
that comic books held 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 sturgeons
revelation which was wrung out of me
after 20 years of worrying 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 crack 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
superpower so no this is
not JavaScript problem it just looks
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 yes too good a
feature do 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
framework the best tool and to do that
they look at either authority or
popularity for a combination of the two
popularity might mean that you look at
just a number of stars and 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 SA P 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 any
thing 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 guess I would
probably need both maybe when you don’t
know what you’re gonna be doing but you
still pick a tool you need a very
generic tool you need a leather man and
a leather man is it’s pretty you okay it
can you can you can screw screws with it
because it has a screw driver a tiny one
but it works and you can use it to
hammering nails because it’s heavy but
when you use it it just doesn’t feel
just right so when you’re working with
one of these god leather man frameworks
is that it constantly feels a bit off it
feels like you constantly have to coerce
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 for star
shape 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 two 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
whoo aah we are eight minutes and 30
seconds into this video which means I
think it’s time for a break aah go get a
cookie in the kitchen that’s what I’m
gonna 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 can
we find that out a lot of people try up
from analysis you have a business plan
or maybe some kind of specs and designs
and stuff and you sit down for a couple
of hours or maybe even a club days and
just think really hard about what’s
gonna 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 the tech stuff the
problem is that you will fit we humans
think that we are really good at
predicting 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 Flickr is a
photo sharing service that just took the
world by storm when it launched it’s not
as big nowadays but it was enormous back
in the day and a fun fact about Flickr
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 Flickr was a much
more viable product than the day that
they had built you might have heard
about mt.gox
it was the by far the biggest Bitcoin
exchange for several years and it just
crushed a year ago or so and the name
auntie Hawks when I first heard of it I
figured it was
mount it was probably some you
know a famous mountain or something but
no it turns out that MT GOx stands for
Magic the Gathering online exchange so
it used to be a forum for Trading Magic
the Gathering cards and they implemented
a feature for buying and trading them
with Bitcoin and that feature just took
off and they decided that oh this this
feature that we accidentally built is
much more feasible as a business and of
course we have urban urban was a name of
the company that built Instagram and
bourbon was also the name of their
product that they built which was is
cool location sharing service and they
spent a ton of time building that and
then they just realized that hey 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 gonna 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 built
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 aren’t probably not gonna change
your own much around here right we’re
not gonna do a flicker or bourbon or
mount rocks 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 back-end built in
Scala with a pretty advanced logging
back-end using Cassandra and unship very
specific 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 you it’s one of those
big-ass god leather bands that can be
used to build almost anything in it sort
of a gateway and movie on Rails word
snob pick 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 site project from their
their normal business so this was not
something that they were working
full-time 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
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 it’s a time 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 what learnings I
had it 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 you’re
building because you would have no
criteria to to judge 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 or a new tool you will be
able to very quickly dismiss that tool
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 taking 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 god-like leather man
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
once you have something that actually
has a 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 at MP Jamie 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 be about and
speaking of which do not miss that
episode you must subscribe by clicking
the face here and until next Monday stake your mieze