szukam jakiegoś frameworka JavaScript, który działałby podobnie do mechanizmu Twittera, tzn.:
nie potrzebuję bindowania, modeli
nie chcę generować widoków po stronie klienta
kliknięcie w link (pushState) wykonywany jest request
widoki generowane są po stronie serwera i przekazywane w JSON.
autobindowanie eventów na klikniecie w link / button
Niestety BackboneJS, AngularJS, EmberJS generują widoki po stronie klienta, bindują elementy i robie jeszcze parę innych rzeczy, których tak naprawdę nie potrzebuję. Czy istnieje jakaś biblioteka JS, która ma podobną funkcjonlaność czy trzeba pisać od zera ewentualnie dopasować wymienione frameworki ?
tak, masz racje to znalazłem, ale dokumentacja do FlightJS (w tym przykłady wykorzystania) są w bardzo opłakanym stanie. Ale z tego do czego doszedłem to FlightJS robi tylko bindingi, dokumentacja nic nie mówi o requestach czy pushstate.
Turbolinks nie robi tego czego szukam. Oczywiście, obsługuje pushState ale on żada całej strony html łącznie z layoutem i poprostu podmienia body, poza tym request wysyła GETem, co w pewnych sytuacjach się nie sprawdzic, np. usuwanie elemntu.
Po weekendzie z FlightJS stwierdzam, że to jest nawet, nawet. Szkoda tylko, że to aż tak okrojone jest (pushState i requesty z ich obslugą trzeba samemu wywolywać)
W sumie to po pierwsze nie dubluje logiki, którą teraz tylko trzymam po stronie serwera, a po drugie nie muszę ładować wszystkich szablonów na samym początku (oczywiście można też nie ładować szablonów na samom poczatku w ror + client side) ale to wymaga wykorzystanie RequireJS lub czegoś podobnego.
Poza tym jakoś nie jestem przekonany do wykorzystywania rozwiązań client side w bardziej rozbudowanych projektach, jeszcze nie spotkałem strony client side w której by wszystko działało prawidłowo (a winowajcą jest jak zwykle JS).
@wafcio to zgaduę że nie jeste ś fanem nowego forum ;).
Nie spotkalem się z frameworkime który robi to co potrzebujesz. Prawdopodobnie coś takiego łatwo samemu stworzyć, chociażby na bazie jQuery. Sama procedura wygląda jednak dziwnie, renderowanie HTMLa po stronie serwera i pakowanie go w JSONa, deserializacja po stronie klienta i zamiana HTMLa… myślę że nie tędy droga.
Potrzebujesz bindowania eventów, chociażby do obsługi formujlarzy i linków via JavaScript. AngularJS jest dość minimalny (nie ma np. warstwy modeli w sensie Backbone/Ember) i prawdopodobnie możesz go wykorzystać w podobnym scenariuszu, z tym że widoki się wyrenderują po stronie klienta.
Do bindowania eventów w sam raz nadaje się FlightJS, niestety nie ma on jakiejs wbudowanej, łatwej w użyciu obsługi PushState, (żeby np. Back Button nie wariował).
Po przerobieniu tutoriala z AngularJS jakoś dziwnie się w nim podpina aplikacje za pomocą ng-app.
Nie twierdzę, że te rozwiązanie jest dobre, ale problemach, które przerobiłem w Backbonie, skłaniam się teraz do rozwiązań bardziej server side, ale nie chciałbym z udogodnień JS. Szukam czegoś pomiędzy.
W tym przypadku pewnie lepiej by bylo zwracac te renderowane serwerem widoki jako kawalki HTML/XML/plain text (czyli bez jsona), skoro kazdy i tak bedzie stanowic pewna zamknieta calosc (z pktu widzenia klienta js, ktory nie bedzie tego jakos specjalnie obrabiac, byc moze poza bindowaniem eventow)
Backbone nie nadaje się do budowania czegoś większego niż proste widgety.
Jeżeli chodzi o to co napisałeś, tzn. że nie widziałeś jeszcze aplikacji javascriptowej, z którą nie byłoby żadnych problemów, to tutaj się zgodzę, to jest jeszcze w dużej części dziki zachód - frameworki nie są jeszcze dopracowane do wszystkich zadań, do których chce się je wykorzystać i część rzeczy, które są banalne do zrobienia w standardowej aplikacji railsowej (nawet posiadającej trochę javascriptu) mogą być dosyć trudne. Jednak te problemy powoli są rozwiązywane. Nie wiem jak jest teraz w świecie Angulara, ale Ember bardzo szybko się rozwija i obsługuje coraz więcej scenariuszy, które zaczynają być widoczne przy różnego rodzaju aplikacjach.
Co do błędów jeszcze, to pamiętaj też, że taka architektura jak opisujesz też nie będzie taka łatwa do ogarnięcia. Nowy basecamp jest zbudowany w podobny sposób (requesty javascriptowe pobierają wygenerowanego HTMLa) i na początku było tam sporo różnych błędów, już nawet po oficjalnym lauchu po becie, np. dużo błędów z cache’owaniem.
Co więcej/mniej szukasz?