Czy HTML5 / JS ostatecznie zastąpi wszystkie języki po stronie klienta? [Zamknięte]

12

Zastanawiam się tylko nad przyszłością tego wszystkiego. IMHO istnieją 4 siły, które określają kierunek rozwoju technologii: Microsoft, Apple, Google, Adobe.

Wygląda na to, że w urządzeniach Apple iPhone / iPad iAD można teraz programować w HTML5. Czy to oznacza, że ​​HTML5 ostatecznie zastąpi cel-c?

Ponadto Microsoft przeniósł teraz swoją uwagę z WPF / Silverlight na HTML5 i zakładam, że Visual Studio 2011 będzie dotyczyło obsługi narzędzi dla HTML5. Ponieważ tak właśnie robi Microsoft. (Przybory). Za kilka miesięcy IE9 ostatnia duża przeglądarka będzie obsługiwać HTML5.

Podobnie Adobe korzysta z modemu HTML5 i pozwala eksportować zawartość flash do HTML5 w swoich najnowszych narzędziach.

Wszyscy wiemy, ile kosztuje Google w HTML5. Heck, ich najnowszy system operacyjny (Chrome OS) to tylko gruba przeglądarka internetowa.

Aplikacje na urządzenia mobilne (iPhone, Android, WM7) są dla firmy bardzo trudne do zaprogramowania, szczególnie na wiele różnych urządzeń (każde z własnym językiem), więc zakładam, że nie potrwa to zbyt długo. Tj. HTML5 będzie językiem jednoczącym. Jest to trochę smutne dla twórców aplikacji, ponieważ teraz użytkownicy będą mogli grać w „fajne” aplikacje HTML5 za darmo w Internecie i będzie za nie ciężko za nie płacić.

Czy więc mocno pisane języki są naprawdę skazane, a w przyszłości, powiedzmy za 5-10 lat, czy programowanie po stronie klienta będzie tylko w HTML5? Czy wszyscy zostaniemy programistami javascript? :) Ponieważ znaki z pewnością wskazują w ten sposób ...


źródło
1
Ci zwolennicy stopniowego ulepszania muszą już krążyć w grobach.
Gio Borje,
2
czy mówisz, że zalety silnego pisania nie będą już potrzebne?
Aaron Anodide
1
Myślę, że będzie to VS 2012, a nie VS 2011.
DeadMG
6
Jeśli tak jest, będę musiał się zabić.
Job
2
Mam dość martwienia się o kompatybilność przeglądarki. To cholernie dziecinne.
The Muffin Man,

Odpowiedzi:

14

Myślę, że błędem jest sugerowanie, że HTML5 / JS zastąpi WSZYSTKIE języki po stronie klienta. Czy wiele aplikacji pójdzie w ten sposób w przyszłych latach? Tak, prawdopodobnie. Czy wszyscy? Nie.

Innym ważnym punktem, na który należy zwrócić uwagę, jest to, że krajobraz stale się zmienia. HTML5 to świetna technologia, która obiecuje rozwiązać wiele problemów, które napotykają obecnie programiści, próbując pisać aplikacje działające na różnych platformach. Jasne, HTML5 / JS może rozwiązać wiele z tych problemów, ale krajobraz się zmieni i pojawi się nowy zestaw problemów. HTML5 będzie w końcu wydawać się przestarzały.

Za 10 lat zadaj sobie pytanie, czy HTML5 / JS było rozwiązaniem wszystkich problemów i mogę zagwarantować, że odpowiedź będzie przecząca. Za 20 lat samo pytanie prawdopodobnie wyda się śmieszne.

Damovisa
źródło
+1 Całkowicie się zgadzam. Spoglądając trochę w przeszłość, „najnowszy i największy” zawsze zastępuje się nowym „najnowszy i największy”. Jest to część tego, co jest tak wspaniałe w programowaniu, że zawsze będzie ewoluować.
Beth Whitezel,
rzeczy ewoluują przy różnych prędkościach - na przykład interakcja użytkownika komputera - karty uderzeniowe, następnie klawiatury, a następnie myszy - często zastanawiam się, co będzie dalej, ponieważ może to okazać się dużym przełomem w tworzeniu aplikacji klienckich - mowa, 3D - dodają - ale coś zastąpi Myszka klawiaturowa? Myślę, że tak - choć nie jestem pewien, kiedy.
Aaron Anodide
6

JavaScript jest bardzo słabym językiem programowania. Tłumaczenie ze statycznie wpisanych języków programowania, takich jak Java z GWT, staje się coraz bardziej popularne. JavaScript może stać się tym samym językiem jednoczącym co asembler - możesz pisać w nim bezpośrednio, ale rzadko jest to dobry pomysł.

Don Reba
źródło
1
Nie wiem tylko o statycznie pisanych językach, ale jeśli wrzucisz tam jQuery, MooTools itp., Zgodzę się z tobą :)
Damovisa
8
Nie zgadzam się z tobą, że JavaScript jest słabym językiem, to absolutnie niepoprawne! :) Wygląda na to, że jest wielu leniwych programistów, którzy znają Javę lub inne języki po stronie serwera przez wiele lat i nie chcą się poprawiać poprzez naukę nowych języków i mówią, że JavaScript jest słaby: D Dlatego jest tak wiele narzędzi i frameworki do generowania JavaScript z językami po stronie serwera! JavaScript nie jest zabawką internetową, to prawdziwy język!
Zango,
Ja też się nie zgadzam. Uważam, że takie umieszczenie komentarza na temat JavaScript jest niewłaściwe. Wielu profesjonalistów i odnoszące sukcesy produkty nie zgodziłyby się. Czas jest najlepszym testem, a jak dotąd JS wykonuje świetną robotę, znosząc zegar technologiczny.
Nie mogę sobie wyobrazić, dlaczego wolałbym pisać 50 wierszy Java, mając nadzieję, że moja zmiana może zostać zmieniona na gorąco, kiedy mogę napisać dziesięć wierszy JavaScript i po prostu ponownie załadować stronę. A może zrestartowano serwer WWW, kiedy nie szukałem?
kevin cline
5
Podczas mojej kariery napisałem oprogramowanie komercyjne w kilkunastu językach i codziennie piszę JavaScript. JavaScript jest rozsądnym językiem, biorąc pod uwagę, że został opracowany i wdrożony przez kilka tygodni w 1995 roku. Mimo to nie rozumiem apologetów JavaScript. Ma poważne wady, które wymagają odpowiedzialnych programistów, aby całkowicie unikali niektórych funkcji językowych i używali innych w sposób, który pierwotnie nie był przeznaczony do zapewnienia brakującej funkcjonalności. Może nie używają go do dużych projektów? Przekonałem się, że używanie go w dużych systemach z wieloma koderami jest stosunkowo trudne.
PeterAllenWebb
1

Tak.

Dlatego. Aplikacje składają się z kodu interfejsu użytkownika i danych zaplecza. Kod interfejsu użytkownika jest uruchamiany w HTML5 / CSS3 / JavaScript. Kod zaplecza może być zastrzeżony i działać w dowolnym języku. Ponadto jQTouch i podobne biblioteki mogą być używane do emulacji interfejsów użytkownika podobnych do iPhone'a, ale open-source i napisane w JavaScript / HTML5 / CSS. jQTouch wykazał, że jeśli przeglądarka zapewnia programistom JS dostęp do zdarzeń interfejsu użytkownika urządzenia, programiści JS będą emulować dowolny styl interfejsu, który jest modny dla tej samej platformy.

Programiści Javascript będą bardziej poszukiwani niż kiedykolwiek. W architekturze model-widok-kontroler model i kontroler znajdują się w zapleczu, ale kod widoku najlepiej jest napisać w przeglądarce. tj. HTML5, JavaScript, CSS. I musisz napisać kod JS, aby uzyskać dostęp do danych zaplecza, szczególnie przy dużym kodzie AJAX.

Wzrost wydajności będzie dotyczył dynamicznie interpretowanych języków. Ponieważ procesory stają się coraz szybsze, wydajność programistycznego kodowania, wydajność sysadmin i wydajność aplikacji i administratora mają większy wpływ na ogólną wydajność. Po prostu nie musisz się już martwić szybkością działania maszyny wirtualnej lub kompilatora twojego języka programowania. Teraz musisz się bardziej martwić, ile kosztuje zapewnienie i obsługa aplikacji.

Moim zdaniem większość samodzielnych aplikacji nie jest tak świetna. Podobnie jak kilka świetnych, samodzielnych aplikacji na komputery PC, a najlepsze z nich są przekształcane w aplikacje internetowe. W rzeczywistości lepiej jest rozdawać aplikację kliencką HTML / JS / CSS bezpłatnie i pobierać miesięczną opłatę za dostęp do danych zaplecza i logiki biznesowej. Programiści lepiej sprzedają subskrypcje niż aplikacje jednorazowe.

BTW obejrzyj ten film na temat pisania części samodzielnej aplikacji internetowej w przeglądarce Webkit. To interesujące...

Jay Godse
źródło
1
Cóż, jedną fajną rzeczą w aplikacjach „one-shot” jest to, że nie musisz robić całej irytującej nazwy użytkownika / hasła, jak prawie wszędzie w sieci. Stan jest zapisywany lokalnie. Ponadto wiele aplikacji po stronie klienta tak naprawdę nie potrzebuje zaplecza. Pomyśl o grach flash. A kto na świecie kupi abonament na gry flash dla mam piłkarskich? Nikt. A kto na świecie kupuje aplikacje mobilne? każdy. Niestety, obawiam się, że HTML5 zabije aplikacje. Miło było mieć raz niezależnych programistów zarabiających pieniądze.
@ Schnitzel - Niezależni programiści będą zarabiać, jeśli również zbudują zaplecze.
Jay Godse,
2
-1 dla „Wzrost wydajności pójdzie na dynamicznie interpretowane języki” - to moim zdaniem bardzo fałszywe. Jestem znacznie bardziej produktywny w językach o typie statycznym i kompilowanym , takich jak Scala. Błędy znajduję znacznie szybciej, bezpośrednio w moim IDE, niż w dynamicznych językach takich jak PHP, Python i Ruby.
Jonas
Naprawdę nie widzę żadnych korzyści z używania PHP / Ruby / Python zamiast Scali.
Jonas
@Jonas - Twoje własne pytanie na stronie programmers.stackexchange.com/questions/7516/... sugeruje, że dynamiczne języki prowadzą na czele pakietu produktywności.
Jay Godse,
1

Istnieje wola zastąpienia języków programowania aplikacji, takich jak C ++, Java ..., HTML / JavaScript. Jest wiele przyczyn tego, niektóre z nich:

  • Szybszy rozwój
  • Tańsza siła robocza
  • Łączność jest wbudowana
  • Łatwiej wyprodukować coś, co wygląda dobrze
  • Tekst jest dostępny dla silników indeksujących

Być może jednak pojawią się inne języki, które będą używane jako zastępcze zamienniki JavaScript. W końcu trudno jest mieć język, który potrafi zrobić wszystko dobrze, pozostając językiem na wysokim poziomie! JavaScript jest już dostępny od dłuższego czasu i zebrał pewne niedociągnięcia.

JavaScript może okazać się głównym językiem po stronie klienta, ale nie sądzę, że może to być jedyny język, ponieważ ponieważ JS jest językiem opartym na standardach, zaprojektowanym przez komisję, to po prostu zabije innowacje na tym poziomie (języki programowania).

Rolf
źródło
0

Zależy to również od umiejętności większości programistów i narzędzi, których używają. Wspomniani giganci technologiczni mogą napędzać technologię w oparciu o narzędzia, które zapewniają. Na przykład ludzie mówią, że HTML5 jest zabójcą Flasha, ale wydaje mi się, że jest zbyt daleko, ponieważ jest wielu programistów Flasha i przeniesienie ich umiejętności do JavaScript jest trudne. Co ostatecznie się zdarza, umiejętność pozostaje taka sama, ale wydajność zmienia się. W tym przypadku Adobe wychodzi z narzędziem do konwersji HTML5.

Musisz także pomyśleć o wydajności aplikacji klienckich. Tam, gdzie to konieczne, zostanie wykorzystane narzędzie specyficzne dla platformy. Bierze na przykład gry i aplikacje na iOS. Wiem, że WebGL wychodzi dobrze, ale czuję, że ludzie nadal używają C do tworzenia gier. Albo stworzą język gry, który tworzy gry o wysokiej wydajności. Apple początkowo chciał tylko aplikacji internetowych, ale gdy programiści zobaczyli cuda Cocoa, wskoczyli na nie, aby stworzyć eleganckie aplikacje.

Podsumowując, zawsze pojawią się nowe narzędzia / język / technologie, które zawsze będą fajniejsze niż obecne.

Manish
źródło
0

Nie wszystkie, ale prawdopodobnie najbardziej. Może javascript może stać się wystarczająco szybki, aby zastąpić HashCalc, ale nie ma internetowej alternatywy dla VLC (przeglądarki nie obsługują wszystkich tych kodeków). Wątpię, czy przeglądarka internetowa zezwoli mi na dostęp do dowolnego pliku, który chcę, lub na zapisanie listy ostatnich plików (bez „jest to w porządku, aby uzyskać dostęp” za każdym razem, gdy kliknę najnowszy plik) i nie podoba mi się pomysł dystrybucji aplikacji, które są 99% przeglądarkami internetowymi (kilka MB) z moim 100kb kodu, jeśli chodzi o przypadki, w których kod się psuje, przeglądarki bc nie są wstecznie kompatybilne z HTML lub potrzebuję wariantu / niewielkiej modyfikacji webkita.

-edit- również lubię języki statyczne, a nie dynamiczne, ale zakładam, że mogę używać dobrego języka z LLVM, który powinien być obsługiwany przez przeglądarkę.


źródło
-1

Myślę, że będziemy podążać w tym kierunku, dopóki przeglądarka nie stanie się systemem operacyjnym, a następnie wszystko zacznie się ponownie cyklicznie w tej samej kolejności, ale z wyciągniętymi wnioskami i ulepszeniami.

Aaron Anodide
źródło