Frontend a Java Web

0

Czy jedynym normalnym rozwiazaniem dla czesci klienckiej , frontendu w nowoczesnych aplikacjach webowych w java to html,css,js i jego frameworki? Czy moze sa jakies sensowne alternatywy?

Bo JSP, JSF i jakies wynalazki z generowaniem widokow z serwera nie wydaja mi sie sensowne a raczej przedpotopowe. Java backend ok, jest co wybierac...

0

W zasadzie to nie jest kwestia Javy tylko ogolnie ogolnie czy jestesmy skazani na JS?

Czy ą jakies technologie kompilowane do JSa, które są... ok?

0

Spring MVC z Freemarkerem dobrze się sprawdza w większości aplikacji. Dodatkowe wstawki jQuery + ajax tabelki przeliczenia formularzy.

Oczywiście są aplikację gdzie serwer side wydaje się bez sensu jak np edytor graficzny, chat, gry. Ale w standardowych app binzesowych to nie ma takiego znaczenia

0

Tylko w sumie po co to. Ja chyba tylko troche korzystalem z thymleafa.

ale na chwile obecna czuje, ze lepiej mi bedzie pouczyc sie js/css/htmla niz bawic sie w cos takiego...

0

no chyba tylko jak trzeba pare stronek wygenerowac.
Wedlug mnie takie oddzielenie client i server side jest bardzo sensowne, a dla js/html nie widze alternatyw.

a te cudowne 'frameworki' nie przypominaja lżejszej pracy tylko właśnie rzeźbienie.
JSP to juz w ogole....

0

Ale to w zasadzie czego szukasz? o_O Bo podejscia są dwa:

  • UI robisz w JS/html/silniku szablonów a to wszystko serwowane jest przez jakiegoś Spring MVC
  • UI robisz w jakimś komponentowym frameworku jak JSF, GWT/GXT, Vaadin czy Wicket

Jak ty byś chciał zeby to wyglądało?

0

No sklaniam sir bardziej ku 1 opcji.

U mnie mamy spring boot, mvc i jersey, pare thymleafow, html5 i angulara.

2

Jest jeszcze opcja: UI robisz w Html5 Bootstrap i AngularJS a backend wystawiasz w RESTowym Springu

0
scibi92 napisał(a):

Jest jeszcze opcja: UI robisz w Html5 Bootstrap i AngularJS a backend wystawiasz w RESTowym Springu

I to wydaje się dużo bardziej sensowne.

No może poza tym, że JS ma to do siebie, że AngularJS 2.0 ma nie przypominać 1.0 (zasłyszane)
JS zmiana frameworka kilka razy w roku :D

0

No właśnie JS jest aktualnie jak Java klika lat temu. Gdzie ludzie się zastanawiali co wybrać, teraz w Java jest dosyć jasny wybór (choć nie prosty) typu Action Based (Spring MVC,Play,..) vs Component Based(Vaadin,JSF,...). W JS jest szaleństo, myślę, że za 3 lata się ogarną Angular 4.0 :-) . Mojej firmy nie stać aby co 2 lata przepisywać aplikację bo wyszła nowa wersja, a stara jest porzucana. Piszemy soft i zarabiamy kasę czy się bawimy?

0

Czy ą jakies technologie kompilowane do JSa, które są... ok?

Scala.js :]

0

AngularJS 1 zaczął się w 2009
Teraz mamy 2016, chyba to nie jest zmiana co pół roku...

0

Sprawdziłem pliki w paczkach TGZ z Angularem 1:

  • wersja 0.9.0 ma pliki z 21.10.2010r
  • wersja 1.0.0 ma pliki z 14.06.2012r

Angular 2 jest jeszcze w wersji beta.

Poza tym plan jest chyba taki, żeby utrzymywać Angulara 1 nawet po wydaniu Angulara 2.

0

Chodzilo mi o to, ze Angular 2.0 ma nie byc za bardzo podobny do 1.0 a to rodzi problemy.

@Wibowit Scala.JS? Myślisz, że to faktycznie jest fajne i może się przyjąć? Ogólnie trochę popatrzyłem to wygląda przyzwoicie.

0

Chodzilo mi o to, ze Angular 2.0 ma nie byc za bardzo podobny do 1.0 a to rodzi problemy.

Ścieżka migracji jest: https://angular.io/docs/ts/latest/guide/upgrade.html
Warstwa kompatybilności między Angularem 1, a Angularem 2 ma sprawić, że będzie się dało płynnie (stopniowo; bez potrzeby przepisywania w całości naraz) przejść z jedynki na dwójkę.

A jak ktoś teraz startuje z aplikacją to moim zdaniem może spokojnie zacząć od bety Angulara 2.

@Wibowit Scala.JS? Myślisz, że to faktycznie jest fajne i może się przyjąć? Ogólnie trochę popatrzyłem to wygląda przyzwoicie.

Wygląda i działa spoko. Bawiłem się z tym z kolegami z pracy, jednak w firmowym projekcie nie stosujemy Scala.js, bo ugrzęźliśmy w Lifcie. Czy się przyjmie to nie wiem (trzymam kciuki), ale dla Scalowca Scala.js to świetna sprawa - można współdzielić kod Scalowy między backendem i frontendem.

0

Zamiast Scala.js większą szansę na popularność ma TypeScript: dobre wsparcie od Microsoft. I oczywiście Angular2, który ugruntuje pozycję TypeScript. Kotlin też umożliwia kompilację do JS. Kotlin raczej widzi mi się jako lepsze Java, rozsądny kompromis między Java, a Scala na backendzie. Znacznie trudniej napisać dziwny i nieczytelny kod w Kotlinie jak w Scali (modna biblioteka scalaz z pięknymi operatorami).

0

Bo Scala to inny lepszy język, a Kotlin tylko lepsza Java. Poza tym to dalej 1.0. tylko.

tu jest porownanie ficzurów i w sumie spoko to wygląda:
http://www.scala-js.org/

i jeszcze takie ciekawostki:
https://github.com/ThoughtWorksInc/Binding.scala
http://widok.github.io/

0

Pojęcie lepszy język jest mocno subiektywne. Czy narzędzie jest lepsze czy nie zależy od umiejętności programisty i konkretnego zadania / problemu. Nadmierne poleganie na implicitach jest moim zdaniem praktyką niebezpieczną, gdyż wydłuża czas czytania kodu, bo stwarza możliwość napisania nieczytelnej logiki. Kod się częściej czyta niż pisze. Uczę się Scali (bo to tylko kolejny język i będzie w tym coraz więcej roboty), ale póki co mam mieszane uczucia. Trochę jak w C++ można dużo ułatwić, można też dużo utrudnić.

W Scali podoba mi się znacznie krótszy zapis niż w Javie i masa bajerów jak tuple, intefejs CLI, przyjemny system typów, rekurencja ogonkowa. Irytuje mnie czas kompilacji.

Wydaje mi się, że dobre biblioteki, które powstaną w Scali będą też dostępne z innych języków np. Kotlina (oficjalne bindingi). I nie będzie to wyglądało tak paskudnie jak w tłustej, opasłej Javie. A po co używać bardziej skomplikowanego języka niż jest potrzebny do zadania. Im prościej tym lepiej. Ostateczne wyeliminowanie instrukcji null też może być mocno uzdrawiające.

0

Irytuje mnie czas kompilacji.

Niektórzy się z tego cieszą, bo to jest argument by tworzyć oddzielne mikroserwisy.

0

Nie każdy problem warto rozwiązywać za pomocą mikroserwisów. Istnieją nisze, w których znacznie lepiej sprawdzają się aplikacje monolityczne np. systemy typowo transakcyjne (operujące np. intensywnie na bazach czy raportujące). Czasem nadużywanie mikrousług to po prostu przedwczesna optymalizacja, tyle że w architekturze.

0

Moim zdaniem jest właśnie odwrotnie. Zwykle brak rozdziału na mikroserwisy (albo chociaż niezależne moduły - chociaż tutaj ciężej zachować dyscyplinę) jest spowodowany lenistwem, a sam powoduje, że tworzy się wielka plątanina klas, którą nie sposób rozplątać. Mikroserwisy powinny posiadać lekkie API, bo ciężkie API jest pracochłonne i sugeruje silne powiązania (tight coupling). Dyscyplina jest automatyczna.

Zbyt dużo pracowałem z monolitycznym poplątanym dziadostwem, by nie doceniać mikroserwisów. A transakcje i raporty spokojnie da się zrobić na mikroserwisach - obecnie w firmie (banku) pracuję nad projektem, w którym są delikatne transakcje, masa raportów (generowanych na żądanie jak i automatycznie) i podział na mikroserwisy (chociaż niektóre z tych serwisów już trochę obrosły i pasowałoby je bardziej nazywać mini, a nie mikro).

Przyjemność pracy z wielkim poplątanym modułem jest mniej więcej taka sama jak praca z wielką pętlą z setkami instrukcji goto.

0

Nie rozumiem.
W Scali jesli chcesz to mozesz pisac jawnie. Ktos broni? Nie trzeba wcale korzystac ze wszystkich dostepnych mechanizmow scali. Mimo to daje wolnosc, ale to niesie tez inne problemy i trzeba umiec za to wziac odpowiedzialnosc. Ale czy to na pewno zle?

Z czasem kompilacji jest juz duzo lepiej, nie przesadzalbym z ttm.

0

Co do mikrouslug to ponoc powinno sie najpierw robic monolit a pozniej dzielic ;)

0
Biały Mleczarz napisał(a):

Co do mikrouslug to ponoc powinno sie najpierw robic monolit a pozniej dzielic ;)

No do pewnego stopnia tak to przebiegało. Kolejne mikroserwisy powstawały przez wydzielanie z poprzednich.

Moim zdaniem, mikroserwisy powinno się robić od razu gdy to ma sens - czyli wtedy gdy da się zrobić mikroserwis z API zdecydowanie lżejszym niż ukryta pod nim logika.

0

@margor90 co do scali. No i? Niezaleznie od jezyka wszyscy programisci powinni pisac kod tak, zeby byl czytelny dla wszystkich.

0

No i testów nie może zabraknąć. Jak jest test to najczęściej od razu widać co kod ma robić.
I w javie jak brak testów to też może okazać się, że trudno zrozumieć taki kod, już nie mówiąc o zmianach.

0

To się wyzywa ludzi na code review, ale nie mozna czegos skreslac bo jest skomplikowane. Bo to nie znaczy, ze jest zle.
A wedlug mnie to Python mial chwilowy boom, a jego rola zacznie maleć, m.in. z powodu braku funkcyjnych featurow i jest po prostu wolny.
Im dłuzej bawię się Scalą tym łatwiej mi jest zrozumieć jej kod.
Ale w absolutnie każdym języku można pisać nieczytelnie.

Kotlin tez ma szanse zawojowac, bo jest hype, bo jest JetBrains i podjaranie w świecie Javy + moze wspomoc ludzi na androidzie.

0

Zgadzam się, że code review jest niezbędne jak się pisze w Scali i pozwala uniknąć wielu problemów. W szczególności jak się trafi na fanatyków chcących każdy problem rozwiązać za wszelką cenę funkcyjnie, bo można, nawet jeśli dotyczy to stanowej logiki i utrudnia jego odczytanie / jego zapis funkcyjny jest trudniejszy i mniej czytelny niż kod imperatywny i nie ma powodów możliwości / aby to wykonywać równolegle. Dlatego uważam, że Scala jest super narzędziem dla pragmatycznych, dojrzałych zespołów deweloperskich. Gdybym uważał inaczej nie uczyłbym się tego języka w wolnym czasie. Oczywiście warto unikać stanowości gdzie można, ale niektóre problemy są z natury stanowe.

Mocną cechą Kotlina jest marketing i prostota, już teraz dodali np. wsparcie dla Spring Boot i to promują i dobrze.

1

C# też ma masę bajerów i jakoś nie widać, by ktoś narzekał. Są konwersje implicit i metody rozszerzeń, a więc w zależności od użytych importów działanie kodu może się zmieniać. Z drugiej strony, taka wtyczka do obsługi Scali w IntelliJ potrafi pokazać zarówno konwersje implicit jak i parametry implicit i wiadomo co się dzieje.

Wolę skomplikowany kod, który można normalnie prześledzić od skomplikowanego kodu, który jest ukryty i siedzi nie wiadomo gdzie. Weźmy takiego Hibernate - niby klaski są POJO, ale w trakcie odpalanie aplikacji Hibernate wzbogaca je swoim dziadostwem, które nie sposób przeanalizować. Potem nie wiadomo kiedy jest 1 zapytanie, a kiedy N + 1, kiedy jesteśmy w transakcji, a kiedy nie, kiedy mamy świeże dane, a kiedy przestarzałe, itd (wiem, przesadzam, po X latach studiowania Hibernate można mieć to w małym palcu, ale mnie Hibernate nie jara). Wolę mieć wszystko pod kontrolą, nawet jeśli w wielu miejscach są przekazywane implicity.

0

Wedlug mnie jesli Kotlin jakos wygra to tylko przez marketing. A jedna z najwazniejszych rzeczy dla nowych jezykow to chyba przede wszystkim dobre wsparcie IDE. ;)

1 użytkowników online, w tym zalogowanych: 0, gości: 1