JAVA, PHP czy Node.js

Mossar napisał(a):

robiłem najbardziej podstawową obsługę GET i POST w Javie

Java!=JavaScript

Wydaje mi się, że nauka PHP jest ważniejszym elementem, bo to fundament działania strony internetowej. JS zawsze można wyłączyć w przeglądarce i wtedy bach... :)

turson napisał(a):

Mossar napisał(a):

robiłem najbardziej podstawową obsługę GET i POST w Javie

Java!=JavaScript

No bez przesady, chyba nie myślałeś, że mylę te dwa pojecia. Tak jak pisałem, używałem HTTP Servleta w Javie z Glassfishem do obsługi GET i POST.

Wydaje mi się, że nauka PHP jest ważniejszym elementem, bo to fundament działania strony internetowej. JS zawsze można wyłączyć w przeglądarce i wtedy bach... :)

No właśnie w związku z możliwością wyłaczenia JS, użycia jakiś NoScriptów, etc. Dlatego też zastanawiał mnie sens używania Node.js.

Node.js działa po stronie serwera, więc skutek wyłączenia JS w przeglądarce byłby taki sam jak przy każdej innej technologii backendowej.

Moim zdaniem, zamiast babrać się w PHP i/ lub generowanie HTMLa na serwerze, idź od razu w RESTa oraz we frontend w frameworku JavaScriptowym. Backend możesz np zaklepać w Javie i Pythonie, żeby sobie poćwiczyć łączenie różnych technologii :]

Podstawowym pytaniem jest jakie języki znasz najlepiej. Wolisz JavaScript, Javę, Pythona, Rubiego, Perla, czy co tam chcesz? Jak bardzo jesteś oblatany w tych językach. Mówisz, że pisałeś FE - czyli znasz dobrze JavaScript. Jeśli tak to Node.js. Jeśli zajmowałeś się bardziej webmasteringiem (czyli HTML + CSS) to warto zacząć od nauczenia się właśnie JSa i RESTa od strony przeglądarki (możesz też spróbować od razu jakiegoś Backbone, Ember, Angular). Potem spróbować również sił w BE, a tam masz całą kawalkadę języków i technologii:

• Ruby - Rails lub Sinatra
• JavaScript (Node.js) - Meteor i co tam jeszcze jest
• Java/Scala - JSP, Spring, Play
• Groovy - Grails
• Python - Pylons, Django
• .NET - ASP.NET
• PHP - Zend, nie wiem co tam jeszcze się używa

Ogólnie hostingiem na razie się nie przejmuj. Na czas nauki nie potrzebujesz żadnego hostingu, a jak już będziesz miał co hostować to nie będzie miało znaczenia czy jest to hosting w Polsce czy za granicą. A za granicą masz całe multum hostingów/SaaS'ów/PaaS'ów i IaaS'ów do użycia:

• Windows Azure
• Google App Engine
• Amazon EC2
• Heroku
• Rackspace
• AppFog
• i dużo dużo innych

Część z nich możesz uzyskać nawet ze zniżką lub za darmo na pewien okres czasu lub do pewnej ilości zasobów.

tl;dr
Przejrzyj sobie co jest dostępne i wybierz z tego. Nie ma praktycznie złych wyborów (choć ja za taki uważam PHP).

winerfresh napisał(a):

Podstawowym pytaniem jest jakie języki znasz najlepiej.

Dość długi okres czasu pisałem m.in. gry 2d w C++, z C++ przeszedłem powoli na C#, ale nie mogę powiedzieć, że C# znam, bo niewiele w nim robiłem. Z konkretów jedynie aplikacja winformsowa do wyostrzania bitmapy przy użyciu bliboteki asemblerowej. Jave zacząłem ogarniać w tym semestrze z racji tego, że mamy taki przedmiot, ale nie jestem fanem tego języka. JavaScriptu kiedyś nienawidziłem, składnia i logika wydawała mi się strasznie ciężka, ale od czasu kiedy używam go częściej, zaczynam go lubić i rozumieć. Dlatego też myślałem o Node i prawdopodobnie nawet jak będę robić w czym innym to chętnie poznam node.js. Jeśli chodzi o Ruby, Pythona czy PHP to moja wiedza jest całkowicie zerowa.

Jeśli zajmowałeś się bardziej webmasteringiem (czyli HTML + CSS) to warto zacząć od nauczenia się właśnie JSa i RESTa od strony przeglądarki (możesz też spróbować od razu jakiegoś Backbone, Ember, Angular).

A mógłbyś przybliżyć trochę tego RESTa, jak to w praktyce wygląda? Bo z tego co czytam to jest to wzorzec, ale niestety pierwszy raz się spotykam z tym.

• JavaScript (Node.js) - Meteor i co tam jeszcze jest
• Java - JSP, Spring, Play
• .NET - ASP.NET

Właściwie to to są trzy możliwe wybory w mojej sytuacji. Poczytam więcej o nich i zastanowie się dokładnie co wybrać.

REST (eng. REpresentational State Transfer) to jest wzorzec architektoniczny, który używa czasowników HTTP do określania akcji wykonywanych na obiektach. Używa on CRUD by określić jaka ma być akcja, a URL jest identyfikatorem obiektu. Dzięki temu jesteśmy w stanie zapewnić API przez ten sam interface przez jaki udostępniamy standardowe widoki. I. e. adres /users/trevor odpowiada za jakiegoś użytkownika - przy pomocy zapytania GET możemy dostać informacje o nim takie jak imię, nazwisko, etc. Przy pomocy zapytania PUT aktualizujemy dane tego użytkownika, a zapytaniem DELETE usuwamy go. W ten sposób rozwiązujemy 2 problemy - prefetchingu oraz API.

Jeśli używałeś coś Javy to może Ci się kojarzyć coś jak SOAP. REST jest znacznie lżejszą i bardziej logiczną wersją Web Services. Do poczytania: http://rest.elkstein.org/2008/02/what-is-rest.html (jest trochę przestarzałe, ale podstawy ogarniesz).

Poza tym zalecam naukę JSa bez jQuery. Naucz się manipulować DOMem przy pomocy "surowych" funkcji, jak document.querySelector[All], przy pomocy podstawowych elementów DOM (https://developer.mozilla.org/en-US/docs/DOM/DOM_Reference). Dzięki HTML 5 jest to niewiele trudniejsze niż używając jQuery, a na pewno ogarniesz więcej.

winerfresh napisał(a):

Poza tym zalecam naukę JSa bez jQuery. Naucz się manipulować DOMem przy pomocy "surowych" funkcji, jak document.querySelector[All], przy pomocy podstawowych elementów DOM (https://developer.mozilla.org/en-US/docs/DOM/DOM_Reference). Dzięki HTML 5 jest to niewiele trudniejsze niż używając jQuery, a na pewno ogarniesz więcej.

Czytałem ostatnio jeden z wpisów Ferrante o jQuery o tym, że w wielu przypadkach lepiej korzystać z czystego JSa. Ale nie zaczynałem JSa od jQuery wbrew pozorom, do pierdółek wizualnych dotyczących pojedynczego elementu wykorzystuje JQuery (lub jeśli się da CSS3), ale gdy kod dotyczy większej ilości odwołań do elementów DOM to już staram się stosować JS bez frameworków.

Dziękuje bardzo za rozbudowane odpowiedzi :)

Do node.js próbowałem podejść kilka razy, jeśli masz projekt > 100 linijek to robi się gehenna, milionowy poziom zagnieżdżenia callbacków i w ogóle. To się nie nadaje do tworzenia czegoś innego niż nieskomplikowane aplikacje do zadań specjalnych.