Dowiedziałem się, że oficjalnie wyszła wersja 1.0 i tak mnie natchnęło, żeby zasięgnąć opini tutaj. Jak myślicie, czy wygryzie Node’a i jeśli tak, to w jakim tempie? Z takich fajnych funkcji:
zintegrowany TypeScript
importy z dowolnego miejsca (np. prosto z repo na githubie)
trzymanie wszystkich zależności w pliku deps.ts, który ma strukturę:
export { assert } from "https://deno.land/std@v0.39.0/testing/asserts.ts";
export { green, bold } from "https://deno.land/std@v0.39.0/fmt/colors.ts";
Osobiście jestem bardzo ciekaw i będę śledził jak się to wszystko rozwinie.
Moim zdaniem deno jest projektem lepszym od node’a, ale obawiam się, że nie zdobędzie popularności. Node jest już znany i lubiany, ale zobaczymy, mam nadzieję, że się mylę.
Ja się jaram! To, że deno nie był stabilny był właściwie głównym stopperem dla mnie. Słyszałem o tym projekcie z 2 lata temu i cieszę się, że nie zapadł w niepamięć <3
Po gwiazdkach GH wnioskuję, że społeczność devowa ma wsparcie dla tego projektu:
To chyba zależy od tego, czy te paczki korzystają z node’owego API, czy nie. Trochę jak to jest z paczkami React-owymi Dotychczas nie postrzegałem node-a jako API, tylko jako czysty runtime. Teraz dotarło do mnie, że to jest także właśnie zestaw bibliotek
Im większa adopcja TSa (a ta raczej wciąż rośnie) tym większa szansa dla tego projektu, o którym zresztą długo było cicho.
Jestem fanem twórcy Deno, bardzo podobał mi się talk, w którym przyznał co zostało skopane przy pracy nad nodem i tam zresztą też pierwszy raz (?) opowiedział o Deno:
Myślę, że Deno potrzebuje teraz jakichś success stories i zainteresowania JSowych influencerów, tak jak to miało miejsce chociażby w przypadku GraphQL.
Jeśli jednak spojrzeć na kontekst powstania Deno → z tego co pamiętam Ryan odszedł od prac nad Nodem stwierdzając, że nie ma sensu go używać skoro jest Golang:
to stanie się jasne skąd wzięły się importy, o których piszesz
Myślę, że głównym selling point Deno ma być to, że można szybciej zacząć faktyczne “kodzenie” bez zabawy w konfiguracje, która w dzisiejszym
nowoczesnym projekcie TS/JSowym wygląda tak (jeśli robimy ją od zera, samemu):
Konfiguracja TypeScripta (statyczne typy)
Konfiguracja formattera (prettier)
Konfiguracja bundlera (webpack, rollup)
Konfiguracja głównego loadera bundlera (babel)
Konfiguracja lintera skryptów (ESlint)
Konfiguracja lintera styli (Stylelint) - dla FE
Wyeliminowanie konfliktów pomiędzy konfiguracjami i testy na popularnych edytorach z ich rozszerzeniami
Koszmar, ale samo Deno to nie jest cure-all.
A dla porównania tak to wygląda w Golangu:
Typy wbudowane, nie trzeba zewn. narzędzia
Formatter wbudowany, nie trzeba zewn. narzędzia
Wbudowany kompilator, bardzo szybkie kompilacje
Nie dotyczy
W VS Code zainstalowałem jedno rozszerzenie - Go. Linter, language server i reszta toolingu zostały zainstalowane i skonfigurowane automatycznie
gdy po raz pierwszy odpaliłem w nim plik z rozszerzeniem .go.
Nie dotyczy
Nie dotyczy
Porównałem Deno do Golanga, bo główne benefity widzę jednak na BE.
