An explanation how to calm down when arguing about JavaScript

1. JavaScript is a buffet, not the enemy
Chris Heilmann @codepo8, ScriptConf, January 2017

2. JavaScript is a buffet,
not a main course…“ – Chris Heilmann

3. JavaScript has grown from a
language and one part of the
web stack into a development
environment in its own right.

4. We want to and we do
everything with JavaScript!

5. This causes a lot of confusion…

6. And I’m worried about
the state of the web
and our community.

7. We work in the
open, and with
very flexible
technologies…

8. …but I see more
drama and dogma
than flexibility and
understanding.

9. Worst of all, I see a
lot of arrogance
and intimidation.

10. That’s why today I
want us to stop and
think about how we
use JavaScript and
share our excitement.

11. I’m not forbidding anyone to
do whatever they want to…

12. But I want to see us becoming
more diverse and interesting!

13. Going back to the buffet
metaphor…

14. Buffets are
great…
✅ They feed a lot of people in a short
time
✅ They allow people to make their
own decisions
✅ They create less waste - people
only take what they need
✅ They are async - you can cook
whilst people eat

15. Buffets have
issues…
🙄 They have lesser quality food
🙄 They might contain things that
make people sick
🙄 You hope that everything is fresh
and gets renewed when not used
🙄 Everybody has their hands in them
and you hope they use the right
tools to take their part

16. And this is pretty much where
we are with JavaScript…

17. Buffet and JavaScript etiquette…

18. Don’t cherry-pick and leave
nothing for others…

19. Your environment is very much
you - and probably nobody else.

20. This is great, own that and
customise to your needs.

21. Share what makes you happy
and makes you more effective.

22. Help improve the tools you use
and you love.

23. Don’t pick the things you like and
demand people to accommodate
to your needs.

24. Make sure you explain in detail
what you rely on and why.

25. You’re creating a service; the
more you think about others, the
more success you will have.

26. Be ready to be flexible.

27. Don’t try to re-use dirty plates…

28. Some things should not be used
on the web any longer…

29. It is not OK to block these things
out, but it is a waste of time to
support them 100%.

30. We can’t move forward carrying
the weight of failed APIs and
broken implementations…

31. This includes polyfills that aren’t
included on demand

32. The web needs to be evergreen

33. Don’t put meat in the veggie
section…

34. There are environments that have
no or very restricted JavaScript.

35. Yes, JavaScript is used to spy on
users and but that doesn’t mean
we need to demonise it - we need
to do better.

36. Different use cases of JavaScript
have different needs.

37. Each of those have best practices
and sensible approaches.

38. They don’t need to mix, they
might even be antithetical.

39. And that’s OK - we can evolve
JavaScript on different tracks.

40. Don’t pile up your plate…

41. It can be daunting to look at the
JavaScript world.

42. Don’t try to be everything, find
something you are excited about
and do that at first.

43. Don’t use every cool new thing
because it is cool and new.

44. Get to know the basics and go
from there

45. If you publish something, think
about collaborating.

46. Documentation, tests and demos
written by others allow you to
question your biases and means
less work for you

47. Find a stack that allows you to
deliver your work and don’t rely
on things you don’t know yet.

48. Don’t touch things you don’t
like and you don’t want…

49. It is OK not to understand
something or not like it.

50. It is not OK to discard it and call
people using it unprofessional.

51. JavaScript can be a great helper
tool, it doesn’t need to replace
everything.

52. It is also not helpful trying to
forcefully convert them.

53. Use the cutlery provided…

54. Flexibility and control comes at a
price.

55. The more functionality you make
dependent on scripting, the
more responsibility you have.

56. If you can use the web platform
to solve an issue - use it.

57. You are likely to have much
more support for environments
you haven’t even thought of.

58. You allow browser creators to
optimise for you.

59. The fewer code you ship to the
end user, the better.

60. Consider making several trips…

61. We have an unfortunate drive to
deliver all the functionality on
first interaction in our products.

62. This isn’t sensible in terms of
data size and code that needs to
get parsed and executed in an
unknown environment.

63. It also doesn’t allow us to deliver
the right solution to the current
environment.

64. Consider not using the one-size-
fits-all solution that makes you
more effective.

65. Instead, deliver a progressively
improving solution.

66. All the code that didn’t get
loaded and executed is a benefit
in a flaky connection world.

67. Don’t be afraid to taste…

68. We live in great times where you
can learn most of what you need
in our market online and for
free.

69. Go and play. Try something new.
Kick the tyres of products people
sell you as amazing.

70. Don’t sit on your laurels, there is
so much to explore out there.

71. Be sure to use this opportunity,
watch videos, take courses, take
part in open source projects.

72. Make sure to explain this to your
companies and demand time to
keep learning.

73. If you need help with this, let’s
talk :)

74. What’s for pudding?

75. The JavaScript world and
community is us.

76. It is not one browser or engine or
environment. Monoculture is stagnation.
Let’s not stagnate but improve.

77. There are many ways you can
help this community - not all are
hard-core coding.

78. We need to break the toxic
demand of more code in less
time.

79. Quick, cheap and fast makes us sick

80. We need to deliver things that
are digestible, with good
ingredients and non-fattening.

81. And that needs time and effort.
Demand that you get it.

82. CHRIS HEILMANN
@CODEPO8
CHRISTIANHEILMANN.COM
THANKS!