Path: csiph.com!.POSTED.188.146.8.175.nat.umts.dynamic.t-mobile.pl!not-for-mail From: Cezary Tomczyk Newsgroups: pl.comp.lang.javascript Subject: Re: dlaczego firstChild oraz childNodes[0] mam undefined? Date: Wed, 22 Mar 2017 13:51:39 +0100 Organization: csiph.com Internet News Service Message-ID: References: <5d210841-ac34-4a0b-9981-9fe8d5e61d4c@googlegroups.com> <1qyr04lt73a9k.2i4h5jx0p963$.dlg@40tude.net> <20170316120955.4c2fcf01@pe.regionet.pl> <07b85c99-5512-4bf8-a85b-32e2693318a2@googlegroups.com> <1bw0p3palg9q0$.1iffa42jnbl49.dlg@40tude.net> <1exqgczs770q5.1ncnughms5d0a.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Wed, 22 Mar 2017 12:51:41 +0000 (UTC) Injection-Info: csiph.com; posting-host="188.146.8.175.nat.umts.dynamic.t-mobile.pl:188.146.8.175"; logging-data="8540"; mail-complaints-to="admin@kev009.com" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: <1exqgczs770q5.1ncnughms5d0a.dlg@40tude.net> Xref: csiph.com pl.comp.lang.javascript:3343 On 21/03/2017 22:12, Borys Pogoreło wrote: > Dnia Tue, 21 Mar 2017 08:38:15 +0100, Cezary Tomczyk napisał(a): > >>> Tak, na pewno zajmie to dłużej, niż przekopywanie się przez specyfikacje JS >>> i historie wszelkich niekompatybilności, a później próba zapamiętania tego. >> >> Oj, nie przesadzajmy z tą ogromną niekompatybilnością. Na dzień >> dzisiejszy osoboście rzadko mi się zdarza, że muszę spędzić więcej czasu >> na rozwiązaniu problemu z kompatybilnością. W 99% wszystko działa nieźle. > > Bo twórcy przeglądarek w końcu zaczęli czytać dokumentację, zamiast ją > wymyślać. Jednak to nie znaczy, że problemów nie ma, a zwłaszcza braków w > jakiejś konkretnej przeglądarce (najciekawiej jest, gdy coś nie działa w > Safari mobilnym, a w pełnym tak). Absolutnie podzielam Twoje zdanie. >> Oczywiście, problem pojawia się na pewno, kiedy chce się zastosować coś >> jak CSS grid. ;-) > > Albo choćby flexbox. Dostępny od lat, ale nie dość, że są trzy wersje, to > jeszcze implementacje mają masę błędów. Nie ma lekko :-) Ale dzięki temu mamy też pracę, bo jakby było idealnie, to nie bylibyśmy potrzebni :D >>> https://online.mbank.pl/combres.axd/LibsJs/301586628/ >> >> No ale ilość użytych narzędzi/libów/itp. nie jest wprost proporcjonalna >> do jakości. Ilekroć pytam programistów o to, dlaczego korzystają z >> jQuery czy innego narzędzia, to odpowiedź jest jedna - z >> przyzwyczajenia. No a potem takie aplikacje puchną bez limitu. > > Ja bym odpowiedział, że z wygody. Inny problem to pluginy, które albo są > małe i nie robią tego, co chcesz albo mają setkę opcji i ważą 100KB sztuka. No i musimy z tym żyć. Czasem jednak szlag mnie już trafia i wychodzi na to, że szybciej sam napiszę coś (włączając w to unit testy), niż znajdę coś, co ma działać tak, jak ja chcę (lub określone w specyfikacji) :-) Taki przykład z życia wzięty: do pewnego stopnia korzystałem z Grunt-a i Gulp-a, ale im bardziej miałem niestandardowy build process, tym większa frustracja była z korzystania z Grunt-a/Gulp-a (hackowanie, brak pluginów, brak aktualizacji pluginów, itd. Patrz: http://www.ctomczyk.pl/why-i-switched-to-only-nodejs-npm-and-stopped-using-grunt/767/). No więc napisałem cały build process korzystając nawet z tych samym npm pakietów i wreszcie działa tak, jak trzeba. I nie, nie spędziłem nad tym wiele miesięcy. Ale, to są wyjątki ;-) >> Moim zdaniem, dzisiejsze implementacje ECMAScript są na tyle dobre, że >> mogę spokojnie uznać, że bez wielu ekstra rozwiązań da się napisać dobrą >> aplikację. Sam tak robię. Korpo zasady to już inna bajka. Tam w >> większości przypadków nie mogłem zaobserwować postępu :-( > > Programista jQuery jest tańszy ;) Możliwe. Nie można tego wykluczyć :-) -- Cezary Tomczyk http://www.ctomczyk.pl/