Pytanie do osob które miały styczność z frontendem w webowych systemach ERP. Zastanawiam się jakie wybrać podejście odnośnie wyboru biblioteki css i zarządzania oknami. Przejrzałem kilka dostepnych rozwiązań Comarchu (np. https://www.mednote.pl/demo/), Enova itp. W wiekszości jest tam angular i mają jakieś swoje dedykowane biblioteki i rozwiązania do zarządzania widokami. Czy ktoś z Was podjął się pisania czegoś takiego np. w React, z jakie biblioteki i rozwiązania polecanie?
0
0
Tworzyłem takie rozwiązania zarówno w angularze jak i react. Do gustu przypadł mi zdecydowanie angular. Jednak tworzenie kodu był prawdziwym koszmarem, jeżeli chodzi o czas, do tego jeśli dodaliśmy, że na starszych komputerach latencja była po prostu tragiczna - doszło coś innego... Zobacz na angular jest już dwójka, za chwilę przestaną wspierać jedynkę, a wy utkniecie z projektem w starej wersji albo będziecie musieli przebudować wszystko od nowa, tak aby było zgodne z najnowszą wersją biblioteki - jeśli będzie chcieli skorzystać z nowych możliwości.
W rezultacie zrezygnowaliśmy z angulara i reacta, na rzecz bardzo prostego rozwiązania. Widoki są renderowane przez serwer - czyli jeśli klient, przeładuje tabele (sortowanie) - tabele renderujemy po stronie serwera, zaś do browsera wysyłamy html, jquery zamienia element - zaś użytkownik widzi nowy widok.
Działa kosmicznie szybko - bez względu na komputer z którego korzysta użytkownik. Sprawa druga, nie przejmujemy się "innowacjami" developerów angulara i reacta.
Angular/reac jest świtny w dwóch przypadkach (nie koniecznie branych pod uwagę razem):
- Dla dużych zespołów
- Dla prostych projektów
Jeżeli projekt jest skomplikowany zaś developerów nie jest zbyt wielu, lepszym wyjściem będzie zastosowanie jakiejś komercyjnej biblioteki np. kendo ui.
W przeciwnym wypadku będziesz zdany na łaskę/nie łaskę vendora - i częsciej będziesz się zastanawiał jak ominąć coś w angularze/react niż zająć się rozwojem aplikacji.
0
Kiedyś natknąłem się na fajną odpowiedź w wątku Angular vs React:
It's about Agile libraries vs Big monoliths.
AngularJS is a "monolithic" framework composed by Models, Views and Controllers, as we all know.
This structure is perfectly fine when you start a small to medium project that will start and end on a predefined timespan, with all the exceptions that may occur during the development phase.I say that is perfectly fine because a small or medium project is "easy" to rewrite if you need to, and tools like AngularJS (or Ember, for that matter) gives you a powerful toolset to kickstart your project and build it at incredible speed.
Now, the problem with big to huge codebases is very different.
A big to huge project can span on many years, being worked on by many different people with many different skills, best practices and preferences.
This means that over the years, as technologies and demands changes, the codebase also needs to reflect these changes.That's one of the many reasons why nowadays our folks prefer small specific library tied together instead of a huge monolithic framework that is very hard to replace altogether.
ReactJS happens to be one of those, only a very efficient, clean, nice written and very very popular one.
Dlatego jeżeli już decydujesz się na coś to wybrałbym ReactJS. Osobiście polecam jeszcze http://materializecss.com/ jeżeli szukasz czegoś, co wyglądem przypomina Angulara, ale wykorzystuje tylko jQuery.
0
@Desu jednak wybierając teraz reacta - wymaga to w chwili obecnej ECMAScript 6, który nie jest wspierany przez browsery:
http://kangax.github.io/compat-table/es6/
Wyjścia masz trzy:
- pisać w starym js - jednak kod będzie koszmarem
- dołączyć kompilator do skryptu (1 MB)
- kompilować po stronie serwera - w chwili obecnej jako tako działa to tylko z nodejs - w przypadku reszty języków jest po prostu męczarnia
0
Nie jestem front-endowcem, ale moi znajomi piszą z użyciem babel'a i jakoś to działa, więc widać można. Mówię tu o kodzie produkcyjnym, bo ja to sobie rekreacyjnie w tym robie.
0
@Desu oczywiście, że można - ja napisałem tylko o kosztach. Wygoda to pojęcie względne.
3
@Desu jednak wybierając teraz reacta - wymaga to w chwili obecnej ECMAScript 6, który nie jest wspierany przez browsery:
http://kangax.github.io/compat-table/es6/Wyjścia masz trzy:
- pisać w starym js - jednak kod będzie koszmarem
- dołączyć kompilator do skryptu (1 MB)
- kompilować po stronie serwera - w chwili obecnej jako tako działa to tylko z nodejs - w przypadku reszty języków jest po prostu męczarnia
nie wiem czemu pominąłeś czwarte i najczęściej stosowane rozwiązanie - piszesz w EcmaScript 6, ale kompilujesz podczas developmentu za pomocą Babela do EcmaScript 5. Nie potrzebujesz do tego serwera. Po prostu programista musi zainstalować sobie na komputerze NodeJS i Babela (a pewnie też Browserify czy Webpacka), a co jest na serwerze to już całkowicie obojętne, bo kompilacja może się równie dobrze odbywać na komputerze programisty.
Poza tym można pisać oczywiście w React w starym JS, ale zgadzam się, że "kod będzie koszmarem". Chociaż myślę, że nie ze względu na ES6, a bardziej ze względu na brak JSX (które w ogóle jest poza standardami, ale Babel je kompiluje).
0
dabra napisał(a):
W rezultacie zrezygnowaliśmy z angulara i reacta, na rzecz bardzo prostego rozwiązania. Widoki są renderowane przez serwer - czyli jeśli klient, przeładuje tabele (sortowanie) - tabele renderujemy po stronie serwera, zaś do browsera wysyłamy html, jquery zamienia element - zaś użytkownik widzi nowy widok.
Nie spotkałem się z takim rozwiązaniem, możesz napisać coś więcej na ten temat?:) Rozumiem że po stronie frontEndu nie macie żadnego frameworka?
Ja ze swojej strony moge dodać iż ES6 nie musi być renderowany po stronie serwera. Jeszcze korzystamy np. w webApi, nasze View do osobny projekt gdzie można sobie podpiąć gulpa, webPacka, tam kilka fajnych skryptów i wszystko zostanie przekompilowane np. przez Babelify. Odnośnie UX obecne biblioteki css z material ui mają jeden problem który je troche dyskwalifikuje przy użyciu w dużym systemie. Kontrolki są dosyć duże co utrudnia umieszczenie ich na stronie w większych ilościach. Dlatego jak kolega wyżej wspominał firmy decydują sie na pisanie własnych bibliotek css z mniejszymi elementami (głównie o inputy chodzi, jakieś zarzadzanie oknami etc.). Od strony ux warto stosować się do jednej zasady aby użytkownik widział w danym momencie faktycznie to co jest mu potrzebne.
Tak jak pisaliście chyba lepiej użyć Reacta (przy angularze 1 może to być za duży dług technologiczny bo 2 już jest). Z Reactem jest tylko taki problem ze obecnie też cały czas coś sie zmienia i jak szukasz np. poprawnego routingu to wyskakuje Ci 30 tutoriali a w każdym jest to inaczej zrobione w tym połowa jeszcze w starszym Ecma Script.
0
nie wiem czemu pominąłeś czwarte i najczęściej stosowane rozwiązanie - piszesz w
EcmaScript 6, ale kompilujesz podczas developmentu za pomocą Babela do EcmaScript 5.
Nie potrzebujesz do tego serwera.
Nie tyle pominąłem, co napisałem w punkcie nr 3 i przyjąłem jako pewnik u reszty :)
Nasz kod js jest generowany pod klienta, czyli defakto kompilacja musiała by być po stronie
serwera.
Jednak tak masz rację - jeśli kod nie jest dynamiczny możesz go wygenerować na komputerze
developera.
Nie spotkałem się z takim rozwiązaniem, możesz napisać coś więcej na ten temat?:)
Rozumiem że po stronie frontEndu nie macie żadnego frameworka?
Po stronie frontendu jest zaledwie kilkaset własnych linii, które głownie ograniczają się do warstwy komunikacyjnej, obsługi form oraz systemem okienek + jquery.
Zasada jest bardzo prosta i korzysta z tego mechanizmu naprawdę dużo projektów. Poniżej
szablon strony wygenerowany z omówioną tabelką po wejściu usera na widok:
<html>
<body>
...
<div id="containerXXX">
<table>
..
</table>
</div>
</body>
</html>
Po wygenerowaniu akcji przez klienta (np. kliknięcie na kolumnę) wykonujemy powiedzmy $.get("url")
i zwracany jest kod
<div id="containerXXX">
<table>
..
</table>
</div>
który zamieniamy z tym istniejącym na stronie. To rozwiązanie jest na tyle ważne, że po stronie serwera renderujemy i formatujemy tylko de dane, do których dany klient ma prawo wglądu.
Na tym prostym przykłądzie możemy
generować zawansowane widoki stoując jeden silnik (po stronie serwera) w jednym języku.
0
@dabra rozwiazanie jest bardzo ciekawe, ale chyba wymaga nie lada wspolpracy miedzy backend a frontend devami? Ja stosowalem takie podejscie ale gdy otrzymywalem response z serwera (np. Zwykly json) i opakowywalem go w htmla z poziomu js wstrzykujac do widoku.
0
@Sebastiano, współpraca nie jest ani mniejsza ani większa niż w przypadku standardowego projektu. Po prostu wymaga spojrzenia na to w inny sposób. Jak mawiał Bill Gates, do najtrudniejszego zadania wybieram najbardziej leniwego pracownika. Tutaj zasada jest taka sama - rozwiązanie jest banalnie proste - takie, że wielu odrzuca ten pomysł i zastępuje je gigantycznymi bibliotekami, których linia nauki, tylko niepotrzebnie podnosi koszt wykonania produktu i go wydłuża.
0
No dobra, ale co to znaczy generowanie JavaScriptu pod klienta? Zakładam, że nie macie tam żadnego myślącego automatu, który programuje, a po prostu programiści definiują odpowiednie skrypty, więc dlaczego nie mogliby sami robić w ES6 i kompilować przed wrzuceniem do szablonu? Przypuszczam, że i tak logika skryptów zostaje taka sama, zmieniają się zapewne tylko dane.
Nie chcę krytykować całego rozwiązania, bo może to się sprawdza w waszych projektach (i wrzucanie na siłę ES6 czy Reacta mogłoby być porażką z perspektywy biznesowej/praktycznej), ale jakoś nie kupuję tego od strony czysto technologicznej, że niby "nie da się" ;)
0
Zakładam, że nie macie tam żadnego myślącego automatu, który programuje, a po prostu programiści definiują odpowiednie skrypty
Skrytp jest generowany pod użytkownika i jego profil - np. przynależność do grupy - generuje np. dla niego router i kontrolery dla tabel, do których ma dostęp.
więc dlaczego nie mogliby sami robić w ES6 i kompilować przed wrzuceniem do szablonu?
Chodzi o czas - całość jest generowana na żywo przez serwer. Poza tym, nie potrzebujemy dodatkowych programistów JS.
Przypuszczam, że i tak logika skryptów zostaje taka sama, zmieniają się zapewne tylko dane.
Dokładnie tak - ale najważniejsza dla nas jest latencja, jeśli podłączyć kompilator live es6 + json to okazuje się, że aplikacja robi się powolna. W tej sytuacji es6 tylko komplikuje sytuację - nie chcemy być trendy - chcemy zarabiać $$$ i robić to jak najszybciej.
ale jakoś nie kupuję tego od strony czysto technologicznej, że niby "nie da się" ;)
Ależ da się - co nie jednokrotnie udowodniłeś - ale nie widzimy w tym naszego zysku.
0
Poczytałem troche o tych enginach do generowania htmla, musze przyznać że temat jest faktycznie wart uwagi. Temat mustachejs też bardzo fajny, chyba sam skorzystam z tego w swoim projekcie:) Odnośnie szybkości React, w sumie został stworzony po to aby orzyśpieszyć rendering po stronie klienta co również wiąże sie z trendem że cały js ma się wykonywać po stronie użytkownika a nie na serwerach:)
0
@Sebastiano Raczej głównym celem Reacta było uproszczenie tworzenia złożonych aplikacji - tak przynajmniej twierdzą sami twórcy. Zresztą jednym z ficzerów Reacta jest właśnie server-side rendering.