[mk321]

Czemu do tworzenia stron używa się HTML (XML) zamiast JSON?
Pytanie wydaje się głupie? Ale słuchajcie, pytam poważnie.

Taka przykładowa strona w HTML:
http://wklej.org/hash/ecbd999a9b2/txt/
Ma 153 znaki.

Jakby opisać to samo, tylko zamiast znaczników XML, to użyć JSON, to mogłoby to wyglądać np. tak:
http://wklej.org/hash/faf6342deeb/txt/
Ma to niby 162 znaki.

Ale usunąć niepotrzebne wcięcia i spacje (minifikacja):
http://wklej.org/hash/f0f311da5e9/txt/
http://wklej.org/hash/9eca8309f98/txt/
To jest 118 (HTML) vs 98 (JSON) znaków.

Czyli wychodzi z korzyścią dla JSON-a. Czemu się go nie stosuje?

Ja wiem, że w zamierzchłych czasach wymyślono HTML i tak zostało do dzisiaj. Ale świat idzie naprzód, wymyślono coś nowego i lepszego. Czemu przechodzi się z WebServices SOAP (XML) na usługi REST (JSON)? Bo są lżejsze.
Dodatkowo JSON jest naturalnym obiektem dla JavaScriptu (a więc obiekt, który dostajemy przez REST jest łatwiejsze przetwarzać w JS). A strony internetowe powinny być naturalne dla JS-a, który to jezyk został dla nich stworzony. Zawsze było czuć ten zgrzyt pomiędzy kodem HTML w JS-em.

Wszystkie strony obecnie są w HTML, więc w okresie przejściowym przeglądarki musiałyby obsługiwać oba formaty. A do starych przeglądarek mógłby być jakiś translator (tłumaczyłby JSON<->HTML). Aż wreszcie większość stron byłaby tworzona w JSON.
Dało się przeforsować rzeczy, które nie przynosiły aż tyle korzyści, więc dałoby się i to.

#webdev #programowanie

[makak]

Problem jest takie. Po co? Oszczednosc zadna, problem w tworzeniu nowej specyfikacji. Wez przepisuj teraz wszystko od nowa.

Nie podrzucaj takich pomyslow, bo jeszcze komus do lba strzeli, potem cala dolina krzemowa sie rzuci na nowinke i bedziemy w dupie :)

[mirko_chat]

@mk321: Tak z ciekawości: Jak zrobisz linka w JSONie?

[JestemZSosnowca]

@mk321: w sumie nie głupie, ale bardziej bym obstawial coś na yml, np Haml

[kulmegil]

@mk321: Pewnie się da, ale czy warto?
Oszczędność niewielka, problemem są rosnące coraz bardziej JS (setki frameworków zależności, itp), wideo, obrazki pod te wszystkie retiny, itp.

Poza tym i tak większość html'a generowana jest z JS, więc nic nie stoi na przeszkodzie.

[mk321]

@makak: jak żadna oszczędność? Wszyscy co tworzą webserwisy zgodzą się, że JSON jest bardziej oszczędny od XML. Weź teraz miliardy podstron i niech wszystkie zapytania będą troszkę mniejsze. Jest to ogromna różnica w skali całego internetu.
Co chwila wydają nową wersję HTML-a, więc mogliby zrobić i taką specyfikację, dla W3C to pewnie nie problem. A przynajmniej realna korzyść. Zwłaszcza, że jakieś translatory XML<->JSON są, więc wystarczy przyjąć ogólne zasady, a resztę

[grzesiek123321]

@mk321: JSON nie jest odporny na pomyłki, bardzo łatwo byłoby się pogubić w tej składni dodając do tagów atrybuty, wszelkie apostrofy powodowałyby konieczność dodawania znaków ucieczki. Można wiele minusów jeszcze podać.

A tak poza tym objętość pliku źródłowego HTML jest akurat w obecnych czasach najmniejszym problemem. Te wszystkie zależności są teraz kluczem do zmniejszenia transferów i przyśpieszenia ładowania stron.

[mk321]

@grzesiek123321: W JSON łatwiej popełnić błąd, bo nie jesteśmy do niego przyzwyczajeni (mi też trudniej w nim się pisze niż w XML). Według obecnej opinii XML jest bardziej czytelny dla ludzi niż JSON. Jednak dla młodszych osób (które np. zaczęły pracę z JS i REST), JSON wcale nie jest nieczytelny. Uważają, że jest tak samo czytelny jak XML albo nawet bardziej (bo zajmuje mniej miejsca i łatwiej ogarnąć). To z myślą

[mk321]

@makak: @mirko_chat: @JestemZSosnowca: @kulmegil: @grzesiek123321:

Mam już nawet nazwę na to wszystko.

Format danych.
Obecnie: HTML (HyperText Markup Language)
Nowe: HTJL (HyperText JSON Language) lub HJL (HyperJSON Language)

Protokół przesyłania.
Obecnie HTTP (Hypertext Transfer Protocol)
Nowe: JHTTP (JSON Hypertext Transfer Protocol) lub HJTP (HyperJSON Transfer Protocol)

Wyobrażacie to sobie? Mielibyście do wyboru dwie strony:
http://www.wykop.pl/ (strona w HTML)
hjtp://www.wykop.pl/ (strona w HTJL)
Przeglądarka sama wybiera odpowiednią wersję

[kulmegil]

@mk321: po co nowy proto, skoro wystarczyłoby coś dodać do żądania (np do nagłówka Accept nowy mime-type) a serwer sam by wysyłał już w odpowiednim formacie.

[grzesiek123321]

@mk321: Apostrofy - chodziło mi o cudzysłowy http://wklej.org/id/2903908/txt/

Minifikacja jak najbardziej. Ale w samym pliku głównym, czy to będzie HTML czy JSON niewiele się zaoszczędzi. O wiele lepiej wysiłki na utworzenie z JSON-a nowego HTML-a przekierować na udoskonalenie kompresji video, obrazków, czy nawet prace nad CSS. Zobacz ile zostało zaoszczędzone na transferze gdy wszedł CSS3 i zaokrąglone rogi robiło się za pomocą kilku linijek CSS-a zamiast obrazków.

W HTML jak nie

[mk321]

@kulmegil: w sumie racja. To tak jak negocjowanie reprezentacji zasobu w Springu właśnie przy wystawianiu usług REST (bo są najczęściej w JSON, ale mogą być jednocześnie w XML czy HTML - klient wybiera co chce otrzymać).

[estemen]

@mk321: eee, przecież przykład z linkiem pokazuje, że w json masz więcej znaków, w pierwszym wpisie pytasz gdzie popełniłeś błąd i sam sobie odpowiedziałeś, myślisz, zbyt płytko i zakładasz, że taki zapis będzie miał zawsze mniej znaków,

[q.....u]

@mk321 to htjp to jest bez sensu, przecież http nie służy tylko do htmla a do każdego rodzaju danych, po http przesylasz jpgi, cssy, zipy itp, po cholerę nowy protokół do nowego formatu pliku?

[epi]

@mk321: a może by w tym jsonie od razu trzymać gotowe drzewo DOM? ( ͡° ͜ʖ ͡°)

[toshibaas]

@mk321: Chciałbym np. dodać 2x po sobie i co wtedy? :)

[Pukie]

@mk321: przecież znaczniki to nie tylko to co widzimy, w tle jest o wiele więcej tego kodu(w shadow DOM) jak pzy inputach,selectach itd.

[aviato]

A nie lepiej jakiś binarny format? Przecież obrazki nie są zapisywane jako json tylko jako PNG, JPG etc. Czemu sama strona musi być w formie tekstowej.

[b0lec]

@mk321: Douglas Crockford wpadł na coś podobnego tyle że jego pomysł jest o wiele bardziej rozbudowany, a w skład wchodzi silna kryptografia i pozbycie się DNS-ów
https://youtu.be/O9AwYiwIvXE

[mirko_chat]

@mk321: Więc główną korzyścią, którą chcesz osiągnąć zmieniając format i protokoły, jest oszczędzenie kilku znaków przed gz'em? Można to zrobić o wiele prościej:

Zamiast:
`
Zastosować:
`

Zmiana o wiele mniejsza, prostsza do ogarnięcia i oszczędzająca więcej znaków niż JSON.

[kulmegil]

@mk321: ps nie chcę Cię martwić ale nie uwzględniłeś paru rzeczy, które zapewne nieco skomplikują i wydłużą tą JSONową strukturę, np:

- nazwa tagu jako klucz nie jest najlepszym pomysłem, element może zawierać wiele dzieci tego samego typu (np

zawiera wiele |) Do tego mogą być przemieszane ze zwykłymi text-nodami.

- nie uwzględniłeś kodowania atrybutów (których nazwy są dowolne i mogą pokrywać się z nazwami tagów elementów)

- JSON nie