An diesem lauen Sommerabend telefonieren sich Anselm, Hans und Peter zusammen, um letzte wichtige Fragen vor dem Urlaub zu klären. Als da wären…
Schaunotizen
- [00:00:13] Ask me Anything
- Reddit und Sindre Sorhus zum Vorbild, hat Anselm auf GitHub eine sogenannte „Ask me Anything“-Sektion (AMA) aufgemacht, auf der jedermann ihn zu allem befragen kann. Ob er jedem immer antwortet und was das Ganze für einen Sinn haben könnte, das wollen Hans und Peter in einem persönlichen AMA gerne herausfinden. Fest steht: Hans sieht für sich da nicht viel Sinn drin und Peter antwortet bei sich im Blog eigentlich nur auf Fachfragen.
- [00:14:57] You Might Not Need Underscore
- Peter und Hans unterhalten sich eine gute Dreiviertelstunde über die Nützlichkeit von Underscore bzw. seinem Zwilling lodash, und ob die Bibliotehken dank neuerer ECMAScript Features nicht vielleicht sogar gänzlich überflüssig geworden sind. Wir stellen fest: Beide haben ihre ganz eigenen Perspektiven auf die Dinge.
[00:58:18] Keine Schaunotizen
- Introducing Material Design Lite
- Google stellt die UI-Bibliothek Material Design Lite vor, die es erlaubt, den Material Design Look & Feel mit jedem beliebigen MVC-Framework zu verheiraten.
- Web Platform Incubator Community Group (WICG)
- Ihr habt eine Idee für einen neuen nützlichen Webstandard? Ihr habt Lust, Eure Idee bis zu einer Spezifikation voranzutreiben? Diese Community Group soll Euch dabei helfen, Eure Idee zu validieren und sie gedanklich wie auch inhaltlich „zur Marktreife“ zu bringen, auf dass sie am Ende tatsächlich in eine gut durchdachte und dokumentierte Spezifikation münden kann.
Kommentare
Michael Kühnel #
Geschrieben am 31.07.2015 um 10:01
Nachtrag zu cherrypicking von lodash Methoden.
Wenn man nicht die ganze Lib haben will kann neben der Einbindung der »per Method builds« (https://www.npmjs.com/browse/keyword/lodash-modularized) auch in wenigen Sekunden eigene Custom Builds erstellen:
$ npm i -g lodash-cli
$ lodash include=debounce,throttle
Siehe https://lodash.com/custom-builds
Grüße ans Workingdraft Team ?
Irgendeiner #
Geschrieben am 31.07.2015 um 10:06
Hans Argumentation (zu Underscore) ist genau der Punkt den ich in Revision 216 anbringen wollte, aber scheinbar nicht fähig war das entsprechend zu formulieren. Ich kann deine (Hans) Argumente nur zu gut nachvollziehen und sehe das Problem in der Praxis auch immer wieder, daher einfach noch mal meine Zustimmung und mein Dank für diese ausführliche Diskussion.
Eine Anmerkung noch:
Jemand der Javascript beherrscht muss definitiv nicht lernen was der Sprache fehlt, der muss immer noch lernen was ihm die verschiedenen Bibliotheken bieten. Es gibt einfach zu viele um alle zu kennen und in die API-Doku wird man erst schauen, wenn man sein Problem nicht ohne weiteres mit nativen Javascript-Methoden gelöst bekommt. Im Zweifelsfall hat man also eine schicke Bibliothek drin und die Funktionen werden schlicht nicht genutzt. Das sehe ich oft auch schon bei einer einzigen Bibliothek, die bietet Funktion X und der Entwickler schreibt es trotzdem selbst, weil es nur ein paar Zeilen sind die er aus dem Kopf runter schreibt.
Ich kann mich nur an ganz wenige Projekte erinnern wo wirklich keine Bibliothek genutzt wurde, von daher denke ich der Punkt, dass man eine braucht kommt früher oder später in der Regel. Leider kann ich mich allerdings an sehr viele Projekte erinnern wo mehr Bibliotheken als nötig eingebunden wurden. Da sitzt man schon mal vor dem Monitor und fragt sich warum das jetzt notwendig sein soll und ob man sich jetzt mit Bibliothek X auseinandersetzen sollte oder nicht. Das ist meiner Meinung nach nicht hilfreich, vor allem da in der Doku – sofern vorhanden – meist kein Wort über den Einsatzzweck der Libs verloren wird.
Alex #
Geschrieben am 31.07.2015 um 22:35
Ihre Podcast ist endlos hilfreich für die IT-Leute, die Deutsch lernen! Danke :-)
Martin #
Geschrieben am 19.08.2015 um 02:53
Hallo workingdraft team,
Ich bin auch eher für natives js, aber nicht in echt großen projekten (also entwicklungszeit +1/2 jahr mit mehr als 5 entwicklern).
Da ist ein einheitliches utility framework (zb lodash) viel zeit ersparnis und somit geld. Und wenn man sich für so ein utility framework entscheidet, finde ich, so sollte man dieses auch überall wo es (sinnvoll) möglich ist auch verwenden! Und nicht nochmals reimplementieren!
Für kleinere (private) projekte und für den lern-faktor, finde ich die sammlungen unter http://microjs.com/# echt gut!!
Da nehme ich auch gerne mal mehrere und baue aus denen ein projekt spezifisches framework zusammen.
Mein einziges kriterium hierbei: der erste seiten aufruf kommt in einem rutsch (<13kb), der rest wird (wenn möglich) nachgeladen.
Ich bin da eher ein fan von progressive enhancment.
Vielen dank, für den hinweis mir dem debounce!
Grüße,
Martin
Nico #
Geschrieben am 31.08.2015 um 13:13
Ich handhabe das Thema mit Libraries meist relativ pragmatisch: Wenn ich an eine Stelle komme, an der ich eine Funktion benötige, von der ich weiß (durch Vorwissen oder durch Google), dass sie von einer Library schon gelöst wurde, dann wird erstmal geprüft, ob ich – wie Anselm es vorschlägt – auch selbst implementieren könnte. Dabei muss es mich ja nicht stören, dass ich manche Grenzfälle nicht abdecke, denn ich sollte im Idealfall ja wissen, wozu ich sie benötige (das sollte man dann allerdings gründlich dokumentieren). Das mache ich aber auch dann nur, wenn es entweder trivial ist oder es bereits eine Lösung gibt, die ich mir einfach kopieren kann. Ist das der Fall, dann wähle ich Anselms Weg und mache es selbst.
Aber spätestens, wenn ich die Funktion ein zweites oder drittes Mal verwende und Aufwand betreiben müsste die Funktion global bereitzustellen, meinen Code nochmals umzubauen, etc., dann wechsle ich zu Peters Weg und suche mir den schlanksten Weg die Funktion einzubauen (z.B. einen Custom Lo-Dash-Build oder eine MicroJS-Lib). Ab diesem Punkt stimme ich Peter nämlich zu, habe ich keine Lust mehr, meine Implementation eines bereits gelösten Problems langwierig auf allen Zielgeräten zu testen, eventuell an mehreren Stellen, Bugs zu fixen, Sonderlösungen zu bauen.
RSS-Feed zu diesem Beitrag
Kommentare sind für diesen Beitrag geschlossen.