W naszej firmie musimy zbudować interfejs WWW na wbudowanej platformie Linux. Widzę 2 opcje: używasz technologii, w której HTML i JavaScript są generowane po stronie serwera (Think JSP, Grails, ale jest to coś, co używa C ++ i generuje HTML / JavaScript) lub tworzysz „klienta” HTML5 aplikacja, która komunikuje się z backendem generującym JSON lub XML.

Mam wrażenie, że obecnie aplikacje internetowe mają tendencję do korzystania z tego drugiego, ale jakie są zalety tego (programiści projektu wybierają ten pierwszy, głównie na podstawie tego, że znają C ++ znacznie lepiej niż HTML i JavaScript)

AJAX

Myślę, że twoje pytanie sprowadza się do: „Czy moja aplikacja internetowa powinna generować HTML po stronie klienta, czy po stronie serwera?” Generowanie po stronie klienta komunikuje się z serwerem za pomocą AJAX, chociaż X (XML) zasadniczo został zastąpiony JSON, ale większość ludzi nadal nazywa go AJAX, ponieważ brzmi lepiej. Po stronie serwera, serwer tworzy po prostu HTML na serwerze.

Mam duże doświadczenie z XML-em i prawie żadne z JSON-em. Wszystko, co wiem o XML, sprawia, że ​​sugeruję używanie JSON, jeśli to w ogóle możliwe.

Zalety AJAX:

• Wysyłaj mniej danych przez HTTP (S), aby mogły działać szybciej.
• Serwer jest zasadniczo usługą internetową, dzięki czemu inne osoby (lub Ty) mogą pisać własnych klientów. Może to pomóc przy tworzeniu mobilnej wersji witryny. Ponadto wiele wynalazków zyskuje popularność z powodów, których ich twórca nigdy nie zamierzał. Usługi są bardziej przyjazne dla osób, które znajdą nowe zastosowania dla Twojego kodu.
• Wygląda jak nowsza aplikacja

Wady AJAX:

• Debugowanie JavaScript
• Złożoność?
• Rzeczy, które możesz zrobić za pomocą JavaScript, są często całkowicie niemożliwe dla osób niewidomych lub niepełnosprawnych.
• Może wymagać więcej kodu ogółem (większa ogólna pamięć na urządzeniu wbudowanym)

Klient / serwer

Wszystkie aplikacje internetowe używają architektury klient-serwer. Protokół HTTP wymusza zachowanie aplikacji internetowych w ten sposób. AJAX stosuje obejście tego ograniczenia projektowego, ale podstawowym modelem bazowym HTTP jest nadal klient-serwer. Nie chciałbym odrywać się od wszystkiego, co do najlepszego sposobu zastosowania MVC do aplikacji internetowych. Jeśli musisz robić MVC z powodów politycznych, sprawdź, jak to robi Ruby / Rails. W rzeczywistości Railsy to świetna architektura do kopiowania (lub używania).

Usługa kontra aplikacja.

Dobra usługa jest prawie zawsze lepsza niż aplikacja. Ale wykonanie dobrej usługi jest trudne! Być może trzeba będzie złożyć wniosek, zanim będzie można napisać wystarczająco dobrze zaprojektowaną specyfikację dla usługi. Nie rób trudniejszej pracy niż trzeba. W wersji 1 skoncentruj się na stworzeniu świetnej aplikacji. Dopóki twoja aplikacja nie będzie względnie stabilna i nie będziesz pewny, że spełnia ona wymagania użytkownika, posiadanie usługi prawdopodobnie i tak nic ci nie da. Zbyt wczesne projektowanie niewłaściwej usługi to strata czasu, którą trzeba tracić, próbując naprawić interfejs usługi i zajmując się masowym refaktoryzowaniem kodu serwera i klienta, który nastąpi.

C / Web

Łał. Pracowałem w C and Assembly przez 3 lata, zanim przestawiłem się na tworzenie stron internetowych. Nie mogę wymyślić gorszego języka do pisania aplikacji internetowych - szczególnie z punktu widzenia bezpieczeństwa. Sprawdzanie poprawności danych wejściowych i zmiany wartości wyjściowych są tak krytyczne ... SANS publikuje listę najczęstszych błędów każdego roku. Przepełnienia bufora, zastrzyki, problemy między witrynami (nieprawidłowe kodowanie danych wyjściowych) ... Wszystkie te błędy są naprawdę łatwe do wykonania w C lub w asemblerze. Przynajmniej język taki jak Java ma ciąg znaków, który jest odporny na przepełnienia, oraz mechanizm obsługi wyjątków, który na ogół zapobiega błędnym kodom dostępu do pamięci systemowej. Nie wspominając już o obsłudze międzynarodowych zestawów znaków (w miarę możliwości używaj UTF-8 ).

Jeśli musisz użyć C ze względu na pamięć lub oprogramowanie układowe, musisz to zrobić. Tylko bądź ostrożny!

Obsługa przeglądarki

Pierwszym krokiem do stworzenia aplikacji internetowej jest odkrycie, które przeglądarki będą używane przez Twoich klientów? W3Schools i Wikipedia są dobrym źródłem ogólnych statystyk, ale YMMV.

W miejscu, w którym teraz pracuję, obecnie potwierdzamy, że nasza aplikacja tworzy tylko poprawny przejściowy kod HTML XHTML 1.0. Używamy również określonego Doctype i formatowania niezbędnych do uniknięcia Trybu dziwactwa w IE, co ułatwia pisanie HTML w różnych przeglądarkach (zobacz wskazówki na moim blogu ). Testujemy na najnowszych 3 wersjach IE, a także Firefox i Chrome w systemach Windows i Linux (Safari używa tego samego silnika renderowania co Chrome). Dzięki tej weryfikacji i testowaniu nasza aplikacja działa prawie wszędzie (Windows, Mac, Linux, iPhone, Android itp.) Oprócz BlackBerry.

BlackBerry nigdy nie miał prawdziwej przeglądarki z JavaScriptem, więc nie obsługujemy go. Użytkownicy BlackBerry są przyzwyczajeni do tego, że nie mają prawdziwej przeglądarki internetowej, więc nie narzekają. Może to się zmienia? Spróbuję zapytać kilku klientów, jakich przeglądarek używają, i upewnij się, aby przetestować te przeglądarki.

streszczenie

Wszystkie strony internetowe są oparte na HTML i HTTP. Podczas tworzenia aplikacji miej dobre informacje na temat tych technologii. Podczas tworzenia aplikacji, nawet z zestawem narzędzi, natkniesz się na problemy wymagające podstawowej znajomości tych technologii w celu ich rozwiązania.

Prawdopodobnie musisz także czuć się komfortowo z CSS i kompresją obrazu, aby stworzyć coś, co wygląda przyzwoicie i szybko reaguje. JavaScript, serwery sieciowe i przeglądarki to dodatkowe obszary wiedzy, których ostatecznie będziesz potrzebować.

Jeśli zbudujesz HTML po stronie serwera, Twoja baza kodu prawdopodobnie będzie mniejsza i nie będziesz musiał uczyć się JavaScript. Model po stronie serwera oznacza, że ​​programiści będą pisać (C?) Kod, który generuje HTML, na który mogą spojrzeć bezpośrednio przed wysłaniem go do klienta. Model AJAX oznacza, że ​​programiści będą pisać JavaScript, który generuje HTML. Nie znam wielu narzędzi do sprawdzania poprawności, a nawet przeglądania kodu HTML generowanego przez JavaScript w przeglądarce, co utrudnia prawidłowe programowanie.

Tam, gdzie teraz pracuję, stosujemy podejście hybrydowe, które czasami obejmuje kod Java, który generuje JavaScript, który generuje HTML. Jeśli jesteście nowicjuszami w tworzeniu stron internetowych, nie jest to miejsce na początek. Chyba muszę powiedzieć, że jeśli nie masz istotnych powodów, aby używać modelu AJAX, zacznę od starszego modelu generowania HTML po stronie serwera i sprawdzę, jak daleko cię to zaprowadzi.

Ta ostatnia ma tę zaletę, że sprawia, że ​​Twój „zaplecze” jest ogólną „usługą danych” (cokolwiek to może oznaczać w twoim kontekście).

Twój klient HTML jest wtedy tylko jednym z wielu potencjalnych konsumentów tych danych. Pomyśl o aplikacji na iOS, Andriodzie, Windows 8, interfejsach API itp. - tak jak inni klienci.

Coraz powszechniejszym sposobem aplikacji internetowej jest połączenie obu, z jednej lub drugiej strony.

Pierwsze podejście jest bardziej tradycyjny, został tam od lat i jego dobrze udokumentowane, (c ++, chociaż na ogół nie jest to język popularny do tego).

Druga opcja jest bardziej nowoczesny, i jest obecny w blogach i forach rozwoju dzisiejszych czasach. Jednym z powodów tego jest rosnąca potrzeba obsługi tej samej aplikacji na innych interfejsach, interfejsach mobilnych i usługach API. Drugie podejście zmierza w kierunku bogatszego klienta i bardziej responsywnego.

Podsumowując, zależy to od innych ograniczeń, takich jak znajomość zespołu i uzasadnienie biznesowe.

Niektóre pytania, które mogą pomóc Ci ocenić opcje:

1. Czy zespół ma doświadczenie w języku i platformie?
2. Czy zespół chce nauczyć się nowego podejścia i technologii?
3. Czy aplikacja korzysta z możliwości łatwiejszego programowania dla innych urządzeń (iPhone, Android, Windows 8 itp.)
4. Czy inna, wewnętrzna lub zewnętrzna aplikacja zintegrowana z usługami lub danymi będzie dostępna dla aplikacji?

Do takich aplikacji „intranetowych” stosuję podejście typu „gruby klient” (aplikacja JavaScript / HTML5 + JSON) z ExtJS4.

W przypadku normalnych witryn internetowych korzystałbym z bardziej „klasycznego” podejścia.

Klienci i tak muszą renderować witrynę, więc dlaczego nie obciążyć ich całym procesem i po prostu dać im dane do wypełnienia. To po prostu kod serwera do generowania odpowiedzi (tylko zwykły JSON lub XML), co oszczędza wydajność. Ponadto, ponieważ zawsze jest więcej klientów niż serwerów, cały system skaluje się znacznie lepiej, jeśli klienci wykonują więcej pracy.

Kod klienta jest dostarczany z HTTP, nadal możesz łatwo wysyłać nowe wersje do użytkowników bez żadnego niejasnego mechanizmu aktualizacji. (Wystarczy wymienić HMTL / JS / CSS)

Jedynym powodem, dla którego wolę klasyczne podejście na normalnych stronach internetowych, są wyszukiwarki.