Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

On Selecting JavaScript Frameworks (Women Who Code 10/15)

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Wird geladen in …3
×

Hier ansehen

1 von 53 Anzeige

On Selecting JavaScript Frameworks (Women Who Code 10/15)

Herunterladen, um offline zu lesen

For front-end developers, there's a never-ending stream of new things to learn. New frameworks, with new philosophies, seem to be released on a daily basis. How, then, do you pick which one to use? The answer, as it happens, has nothing to do at all with JavaScript.

For front-end developers, there's a never-ending stream of new things to learn. New frameworks, with new philosophies, seem to be released on a daily basis. How, then, do you pick which one to use? The answer, as it happens, has nothing to do at all with JavaScript.

Anzeige
Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (20)

Anzeige

Ähnlich wie On Selecting JavaScript Frameworks (Women Who Code 10/15) (20)

Anzeige

On Selecting JavaScript Frameworks (Women Who Code 10/15)

  1. 1. ON SELECTING JAVASCRIPT FRAMEWORKS
  2. 2. I'm Zoe Landon. (aka @hupfen)
  3. 3. I'VE DONE THIS A BIT BEFORE. ◇ I'm a web developer with a fair bit of front-end experience. ◇ My last two jobs both involved some degree of picking a JavaScript framework. ◇ In fact, I've only had one job where it didn't come up. ◇ Not to mention personal projects. ◇ It's getting kinda old, honestly.
  4. 4. So, if we're going to pick a JavaScript framework, we should look at our options, right?
  5. 5. THERE'S A FEW.
  6. 6. BY THE WAY... These were all active within the last two weeks, when I made this presentation (Oct. 7). Some are hobbyists, some are big companies, but all are active projects. You could maybe double this with "slow" projects (updates in the last 6 months).
  7. 7. LET'S CLEAN THIS UP A BIT.
  8. 8. BETTER.
  9. 9. EXCEPT... Those lines are blurry. An MVC framework can use components to drive its structure. A component-driven architecture may or may not be modular. There's overlap. It's not clear-cut.
  10. 10. So, how do you pick the right JavaScript framework out of all that ambiguity?
  11. 11. ANSWER:
  12. 12. Choosing a framework shouldn't be the first thing you do on a project, but the last. Before writing code, of course.
  13. 13. LET'S TALK ABOUT CODE SCHOOLS.
  14. 14. CODE SCHOOLS ◇ Code schools, and many college CS programs, advertise that they'll teach you how to code. ◇ Broader PR language talks about how everyone should learn to code. ◇ That's all true. And that's all useful. ◇ But coding is not making software.
  15. 15. Learning to write code, but not learning to make software, causes problems.
  16. 16. CS VERSUS SE Software is more than the code you write. It's all of the context that goes into it. Writing code is a vital step in implementing software, but so is the process of finding that context. Too often, that process is skipped over by programmers who just want to code.
  17. 17. CODING IS NOT SOFTWARE ENGINEERING
  18. 18. Selecting a JavaScript framework is a software engineering challenge, not a coding challenge.
  19. 19. THE PROCESS Sorry, but this is a software engineering talk in disguise. But if you ask the right questions, you'll end up understanding the project and its context so well that picking a framework takes hardly any effort. So let's ask those questions.
  20. 20. SOFTWARE QUESTIONS
  21. 21. WHY?
  22. 22. WHY? Why does the problem you're trying to solve exist? Was performance never considered? Is the code poorly built? Are you just goofing around and learning? There's no wrong answer, besides having no answer.
  23. 23. WHY? Sometimes, you'll get requirements that propose a solution to what they describe. Asking "why?" offers a gut-check, to make sure that solution really is the best one. Also consider why a framework you're evaluating exists. What problems are its authors trying to solve? Do they know?
  24. 24. The context of the problem matters more than the problem itself.
  25. 25. WHAT?
  26. 26. WHAT? Working out why the problem exists helps to define what the problem really is. That helps define the features and capabilities that are going to be necessary. Those become your priority.
  27. 27. WHAT? Some tools and frameworks do certain features really well, and really easily. But other features may take some work. Don't discard a framework just because it doesn't have exactly what you want. You can build it. Or it may have something different that achieves the goal instead.
  28. 28. Any feature is possible, but with the wrong tools some will be difficult.
  29. 29. WHO?
  30. 30. WHO? You go to war with the army you have. You, your customer, your users, your teammates, your company… Everyone brings perspectives. Expectations. Skills. Experiences. Ideas. Politics.
  31. 31. WHO? If your boss says "we're using this framework", and it's not the best one, you either have to fight or concede. If your team already knows a framework that's not empirically the best, but is still kinda close, that may be your wisest pick. Merit rarely wins. Account for this.
  32. 32. The people on a project ultimately determine what's practical.
  33. 33. HOW?
  34. 34. HOW? Every framework has a philosophy behind it. Based on the context you've gathered, you'll have a philosophy on how the project should be done. Now you're just looking for a match. You'll make better code that way.
  35. 35. HOW? Beyond a certain level of competence- based best practices, it's not worth worrying about how pundits write their code. If you don't like a popular approach, don't use it. If you do like it, use it. You're the one writing the code, after all.
  36. 36. Pick the tools that encourage the kind of code you can enjoy.
  37. 37. REPEAT
  38. 38. REPEAT You'll hopefully only choose a framework once, but you should be asking those questions routinely. Every quarter, or at the beginning of every sprint, whatever pace helps keep you confident you're on the right track and making the right software.
  39. 39. REPEAT But now, the hard work is done! All you have to do is implement the ideas you decided on. But since you did all that work, the programming will be easier. You've made the software, you just need to write the code that powers it.
  40. 40. LAST THOUGHTS
  41. 41. LAST THOUGHTS I always like to end on some little summarizing thoughts. Some oblique strategies for software engineering, if you will. And I will.
  42. 42. Immediately why, Eventually how
  43. 43. When faced with a problem, ask why the problem exists before jumping to solve it.
  44. 44. Pick the boring option
  45. 45. Practicality is a valid argument. When working with many others, a less interesting option may be the best.
  46. 46. Software is human
  47. 47. Software has a personality. It's more than just code, it's all the decisions and context that went into it. Understand those, understand software.
  48. 48. Also: Software has a life. It will grow up. It will grow old. You can give it the best chance of success, but ultimately, it's out of your hands. Accept this. Embrace this.
  49. 49. TWEET AT ME: @HUPFEN YELL AT ME: ZOE@HUPFEN.COM Presentation template by SlidesCarnival Photographs by Death to the Stock Photo

×