[d.....o]

#programowanie powiedzcie mi co/kiedy poszło nie tak ze stronami www? Tematu nie zgłębiałem zbytnio od ok. 10 lat, gdy pisało się kawałek JS + html + css. Największym problemem była niekompatybilność JS na IE, Firefox i Netscapie

Teraz piszemy w TypeScript, korzystając z frameworków pisanych w JavaScript i kompilowanych styli CSS do CSS, które używają swojego frameworka CSS, który też się kompiluje/minimalizuje, aby całość skompilować do interpretowanego Javascript, który jest kompilowany do zminimalizowanego JS, który generuje DOM, który jest wyświetlany przez przeglądarkę, która jest binarką.

Strony ładują się może szybko, ale zjadają 100%cpu i wygenerowanie się ich trwa czasem wieki... Aplikacje backendowe budują się 2-3 razy szybciej niż frontend. Serio?

[pesymistyk]

@didijo: a po co optymalizować i marnować czas, end-user kupi nowy lepszy sprzęt i gitara

[ItsyBitsyPajonk]

@didijo: powiem ci z perspektywy osoby, która siedzi w marketingu od lat. Nikt normalny nie zaproponuje klientowi z sektora MŚP witryny opartej o framework JS, bo koszty obsługi tego są nieporównywalnie większe. Google nie lubi JSa, specjaliści marketingu nie lubią JSa, klienci nie lubią JSa, tylko #!$%@? programiści się srają jakie to jest fajne.
Nope. #!$%@? nie jest.

[z--x]

@didijo: Powoli mam wrażenie świat FE się budzi i zauważa, że mamy #!$%@?. Ja na przykład jak mam opcję wyboru to w ogóle staram się robić wszystko dependency-free od zawsze, ale też nie chce mi się tracić nerwów jak ktoś wie lepiej i narzuca jakiś toolset.

[Moroder]

@didijo: brak umiejętności web-developerów, tzn. brak programistów w branży web-dev

[Virti]

@didijo: bo jak się rusza i animuje to jest bardziej engaging ( ͡° ͜ʖ ͡°)

[Krolik]

@didijo: Po pierwse jak się to umiejętnie zrobi, to frontend rendering bije szybkością reakcji jakikolwiek server-side rendering. Zamiast wysyłać do klienta całą sformatowaną stronę wygenerowaną dynamicznie, co zajmuje dużo zasobów serwera, można wysłać tylko komunikat z danymi a całą generację zrobić na kliencie i użytkownik widzi zmiany znacznie szybciej, bez niepotrzebnego przeładowywania wszystkiego. Po drugie w ten sposób lepiej się skaluje, bo dostajesz trochę mocy obliczeniowej od każdego klienta.

[mleczko-kokosowe]

@didijo:

Teraz piszemy w TypeScript

Ponieważ programiści wolą pisać w typowanym kodzie i oszczędzają potem czas na szukaniu błędów.

korzystając z frameworków pisanych w JavaScript

Jak to mówią, jeśli nie używasz frameworka to skończysz projekt budując własny (nie dotyczy reacta, tam i tak trzeba wszystko samemu "zgrać"). Poza tym czysty js ma niewygodne api do obsługi dom i eventów (brak możliwości pisania deklaratywnego kodu).

kompilowanych styli CSS do CSS, które używają

[d.....o]

@mleczko-kokosowe: właśnie o tym piszę - "js ma niewygodne api", "czystym CSS brakuje wielu przydatnych rzeczy", "programiści wolą pisać w typowanym kodzie" itd... gdzieś ktoś zapomniał że to wszystko to nie jest CPU, który architekturą sięga wstecz lat 70-80, tylko przeglądarka, która aktualizuje się co kilka tygodni praktycznie z automatu. Mimo tego, że nikt nie chce korzystać bezpośrednio z tych technologii, one dalej są i mają się dobrze

Tak trochę ratowanie