•  

    pokaż komentarz

    Ileż to takich technologii wychodzi co roku i co roku znika ( ͡° ͜ʖ ͡°)

  •  

    pokaż komentarz

    Uff kolejna rewolucja we frontendzie - która to już będzie w tym roku?

  •  

    pokaż komentarz

    "Uwielbiam" takie znaleziska. Z punktu widzenia przeciętnego człowieka tytuł i opis wyglądają mniej więcej tak:

    洛爾卡 – czy sprytne połączenie 去吧 i 頁面描述語言-a 5 może zagrozić 電子?

    去吧, 頁面描述語言 5 i sprytny sposób na oszczędności w wykorzystaniu 網絡瀏覽器'a – poznajcie 洛爾卡.

    pokaż spoiler Więc zakop ( ͡° ͜ʖ ͡°)

  •  

    pokaż komentarz

    Głupota. JS jest znacznie wygodniejszy od Go. Tak, pozawala na więcej błędów, ale jest elastyczniejszy. Wydajność? Ten kto twierdzi że JS jest wolny, mentalnie żyje w latach 90'.

    Te rzekome rozwiązania jakie dają przewagę nad Elektronem, to potencjalne zagrożenia. Poza tym, nadal gdzieś tam musi być V8, więc nic się nie zyskuje.

    Sztuka dla sztuki, albo próba sportowania znośnej platformy GUI dla developerów Go, którzy z niesłusznym obrzydzeniem patrzą na JS.

    (BTW. osobiście piszę w JS, C++, Pythonie i miałem kilka dość pozytywnych podejść z Go)

    •  

      pokaż komentarz

      @Razi91: JS to rak, powinien być zdelegalizowany i zastąpiony TypeScript. Mówię śmiertelnie poważnie. JS jest zbyt płynny, przykładem jest chociażby brak kontekstu w autocmplete w dowolnym IDE. Najlepsze wyjście imho to TypeScript z uporządkowaną strukturą tak aby IDE zapewniało komfort i było świadome co podpowiada. A to że TS i tak zrobi z tego JS już nie ma najmniejszego zanczenia, dopóki jest jako tło.

      No siema Igor.

    •  

      pokaż komentarz

      @Puszy133: a o jsdoc slyszałeś?... Jeśli wszystko masz uporządkowane w js i piszesz kod z głową to dynamiczne typowanie jest Twoim przyjacielem a nie wrogiem

    •  

      pokaż komentarz

      @Puszy133: pełna zgoda, JS jest zbyt ułomny na zadania do jakich jest teraz wykorzystywany. A największą jego wadą jest to że początkujący myślą że znają JS, a nim to co myślisz nie jest tym co myślisz. W backend króluje php który, podobnie jak JS, założenia startowe miał zupełnie inne niż obecne zastosowanie. Cały absurd informatyki polega na tym że po tylu latach standardem nie stał się język dorosły.

    •  

      pokaż komentarz

      Ten kto twierdzi że JS jest wolny, mentalnie żyje w latach 90'

      @Razi91: A co się zmieniło w js od lat 90-tych? Nadal jest interpretowany w przeglądarce a node.js może jest napisany w C ale wykonywany kod nadal jest interpretowany. Skąd te zyski na prędkości od lat 90-tych?

    •  

      pokaż komentarz

      @Koryntiusz nie jest interpretowany, jest JIT tak samo jak w Javie i C#, doucz się trochę, są bardzo fajne materiały o V8 odnośnie optymalizacji.

      @dziki_pl zaadaptował się, po to są narzędzia typu Webpack. I dzisiaj już PHP nie króluje na hacjendzie, chyba że idziesz w ilość, a nie jakość i liczysz wszystkie WordPressy.

    •  

      pokaż komentarz

      @Puszy133: właśnie nie. Dzięki elastyczności JS powstało dużo języków, które z niej korzystają. Gdyby TypeScript był jedynym obsługiwanym w przeglądarce to nie byłoby wielu języków opartych na JS. Co Ci szkodzą konwertery?

    •  

      pokaż komentarz

      @dad1111: development w JS jest nieprzyjemny. Tak jak pisałem, sam JS może sobie istnieć ale w tle. A co do TS to nie chcę zmieniać świata aby przeglądarki natywnie wspierały JS. Prowadźmy development w TS, w przeglądarce finalnie niech hula JS.

    •  

      pokaż komentarz

      @Razi91: trochę więcej niż wordpressy chodzą na php. Wiem że sporo osób idzie z modą na node, ale bez świadomości jego wad.

    •  

      pokaż komentarz

      @Puszy133: Zabawne, że najczęściej krzyczą tak ludzie, którzy nie piszą w JSie.

      Typescript wcale nie jest taki fajny - tak naprawdę dodaje tylko bardzo delikatne zabezpieczenia przed krnąbrnymi programistami, zaciemniając kod, tworzy nowe problemy w miejsce starych i wydłuża czas pisania.

    •  

      pokaż komentarz

      @dziki_pl: To samo mógłbym powiedzieć o PHP, że ludzie się w niego pakują nie znając jego wad: np. brak sensownej asynchroniczności, stosunkowo niska przepustowość, brak samodzielnej instancji... Chyba nikt nie będzie się kłócił ze mną, że JS nie wykorzystuje dzięki asynchroniczności zasobów w sposób bardzo wydajny.

    •  

      pokaż komentarz

      nie jest interpretowany, jest JIT tak samo jak w Javie i C#, doucz się trochę, są bardzo fajne materiały o V8 odnośnie optymalizacji.

      @Razi91: Mój błąd. V8 ma JITa którego porównujesz do Javy i C# ale zacząłeś od porównania do go które w większości przypadków będzie szybsze od Javy a Java w większości przypadków będzie szybsza od node.

      Powiedzenie, że coś jest "wolne" nic nie znaczy bez punktu odniesienia.

    •  

      pokaż komentarz

      @Koryntiusz: nigdzie nie napisałem że będzie szybsze. Napisałem tylko że ma podobne mechanizmy. Jednak w przypadku dużej ilości zadań związanych z IO to jednak Node będzie miał przewagę, bo jest z natury asynchroniczny. Ogarnia znacznie lepiej cięższe zadania, bo jest jednowątkowy (paradoks? Nie do końca) i po prostu dzieli się tam większe zadania na mniejsze i po kolei wykonuje co się da. Nie cierpi na przełączanie kontekstu, bo to nie występuje, żaden task nie jest dzielony, tylko zawsze doprawadzany do końca. Oczywiście powoduje to pewne opóźnienia (góra milisekundy, w webie to pomijalny koszt), ale jednak one nie mają aż takiego znaczenia, gdy taski są wystarczająco małe.

    •  

      pokaż komentarz

      nigdzie nie napisałem że będzie szybsze.

      @Razi91: Ja napisałem, że będzie bo pisanie że coś nie jest wolne bez żadnego odniesienia nic nie mówi. Chyba, że porównujemy czas wykonywania kolejnych wersji języka na innych silnikach.

      Jednak w przypadku dużej ilości zadań związanych z IO to jednak Node będzie miał przewagę, bo jest z natury asynchroniczny.

      @Razi91: Non-blocking IO to jednak trochę inny temat niż asynchroniczność. W JS też możesz pisać synchronicznie a w Javie mieć non-blocking IO. To już kwestia tego jak kto pisze.

      Porównania JS do Javy biorą się stąd że JS wrzucono na backend gdzie IMO jego główna rola jest niezastąpiona - obługa frontu. Nie widzę wielkich zysków używania JS na backendzie oprócz tego, że frontendowcy nie muszą uczyć sie kolejnego języka.

      EDIT: Dziwne wciskanie go we frontend bierze się z tego, że komuś nie chce się uczyć JS'a choć powinien ;)

    •  

      pokaż komentarz

      a o jsdoc slyszałeś?... Jeśli wszystko masz uporządkowane w js i piszesz kod z głową to dynamiczne typowanie jest Twoim przyjacielem a nie wrogiem

      @nbsp: Dynamiczne typowanie nigdy nie było niczyim przyjacielem. To była największa pomyłka w świecie IT i każdy dynamiczny język albo skończył z tworami typu TypeScript albo dodali typowanie w kolejnych wersjach języka jak w Pythonie czy PHP albo musisz używać dziwnych komentarzy i zewnętrznych narzędzi do analizy statycznej.

    •  

      pokaż komentarz

      @Razi91: w php masz oddelegowaną asynchroniczność, którą zapewnia serwer www. W node nie tyle co możesz ale ty ją musisz zapewnić. To co w php załatwia serwer www, czyli chociażby routing w node trzeba robić samemu. Tam gdzie php mnie ograniczał i potrzebowałem działającego w tle procesu wybierałem pythona. Ale rozgraniczam to co zyskuje będąc procesem, od tego co tego nie wymaga i proces będzie wadą.

    •  

      pokaż komentarz

      @dziki_pl: Routing poprzez pliki to antywzorzec. Pythona też używałem (Django), ale odchodzę w stronę Node'a dość ostro. Brakuje mi tylko Djangowego ORMa.

    •  

      pokaż komentarz

      @Razi91: dorzucać sobie JS jeszcze do backendu to jakaś forma masochizmu. Może jeszcze apple script....

    •  

      pokaż komentarz

      @MDobak: zachowujesz się jakby js się skończył, a sie nie skończył i szybko się nie skończy. Dynamiczne typowanie de facto otwiera drogę również na typowanie statyczne. Możesz, ale nie musisz. Chyba lepiej mieć wybór, niż go nie mieć? Ps. Ci co sądzą że js się nie zmienił od lat 90, niech zajrzą na changelog EcmaScriptu.

    •  

      pokaż komentarz

      @nbsp:

      Dynamiczne typowanie de facto otwiera drogę również na typowanie statyczne. Możesz, ale nie musisz. Chyba lepiej mieć wybór, niż go nie mieć?
      Nie, w tym przypadku lepiej nie mieć wyboru bo jedyną drogę jaką Ci to otwiera to drogę na nowe błędy. NIGDY nie powinieneś mieć sytuacji, że jedna zmienna może przyjmować wiele typów danych.

    •  

      pokaż komentarz

      JS jest znacznie wygodniejszy od Go.

      @Razi91: o gurwa co

      callback hell, promise to gówno. Tymczasem w go pracujesz elegancko, na spokojnie, z czytelnym i prostym kodem. A jak potrzebujesz async albo wątków to cyk, goroutine i channels

      chociaż oczywiście jakbym miał wybierać między nodem a php to bym poszedł hodować dzikie świnie, ale jak już to node, bez dwóch zdań ;)

    •  

      pokaż komentarz

      @diogene: Dobrze użyte promises wygląda dobrze i czytelnie, jeśli masz z tym problem, to znaczy że nie umiesz pisać czystego kodu. Poza tym możesz też używać await.

    •  

      pokaż komentarz

      @Razi91: to nadal jest proteza protezy i nijak ma się do wygody i czytelności go

    •  

      pokaż komentarz

      @MDobak: napisałeś NIGDY kapitalikami i rozumiem że dobrnęliśmy do paradygmatu :) Błędy zdarzają się w statycznie i dynamicznie typowanych językach, serio. Jeśli architektura jest poplątana to silne typowanie nic nie pomoże.

      Moglibyśmy toczyć tego flame dalej, ale tak już jest że każdy ma swój ulubiony język programowania. Tak naprawdę o wszystkim decyduje architektura aplikacji. Można poplątać się w morzu interfejsów i typów (które przecież można też rzutować, tyle że ręcznie). Można się poplątać w morzu domyślnie rzutowanych zmiennych w js. Wszystko jedno.

    •  

      pokaż komentarz

      napisałeś NIGDY kapitalikami i rozumiem że dobrnęliśmy do paradygmatu :)

      @nbsp: W programowaniu masz wiele takich paradygmatów które zostały wypracowane latami doświadczeń. Zwykle takie dyskusje najlepiej zakończyć prostym pytaniem: czy masz jakiś sensowy use case w którym ta właściwość języka jest niezastąpiona?

      W ogóle trochę podejrzane jest, że powołujesz się na "dobrą architekturę" gdy dziś jednym z podstawowych elementów dobrej architektury są Value Objecty i typowanie wszystkiego co się da ;)

  •  

    pokaż komentarz

    Siła electrona nie polega głównie na tym, że JS zna prawie każdy, a Go niekoniecznie?

    Sama lorca ma na swoim gh:

    Lorca is an anagram of Carlo, a project with a similar goal for Node.js.

    I jak wejdziemy na projekt Carlo, to działa on właśnie tak samo jak Lorca - tyle, że jest na JS. I ze wsparciem Googla.