Vývoj webových aplikací pro nenáročné

[registrovany_ava]

Já byl předloni ve stejné situaci, nakonec jsem si napsal dvě jednoduché aplikace v Elmu. Sice ten jazyk asi velkou budoucnost nemá, ale utekl jsem všem těm Javascriptům, npmkům, bylo to docela zábavné, něco jsem se naučil, a šlo to vcelku hladce.

[Reklama]

[Mlocik97]

Jdeš proti proudu, podle mě je lepší se to prostě naučit a nedělat weby 20 let starým způsobem.

PROČ?
Když chce dělat něco pořádně, může to udělat v Java.
Proč by si nemohl napráskat jednoduchou webovku jen tak bez hromady zbytečného balastu?

Není náhodou jQuery práve tým zbytočným balastom, a nie je práve WebPack, RollUP, a pod. to čo zabezpečuje že do aplikácie nejde zbytočný balast?

[Mlocik97]

Ak to chces robit rozumne, tak sa npm a Webpacku nevyhnes zial.

Webpacku se dá vyhnout docela dobře. Je dost modernějších bundlerů, třeba Snowpack nebo esbuild. Je dost nástrojů, které na Webpacku závisí, ale to asi nebude směr, kam registrovany123 míří.

Snowpack a Webpack je bundler a bundler... keď povedal WebPack tým myslel aj jeho alternatívy...

[Mlocik97]

To je přesně ten moderní trend co se mi vůbec nelíbí, pro jednoduchou webovku tahat bůchvíodkud megabajty balastu a výsledek je odpudivá rádobyprezentace dlouhá několik obrazovek, s pár fullHD obrázky na pozadí, olbřímým písmem a s informační hodnotou 0.

Viz třeba apple.com, anebo hloupá úvodní stránka googlu s logem a vkládacím vokýnkem pro hledání - má 1.2 megabajtu a dobu nahrávání v sekundách.

Kde jsou ty časy kdy se jednoduché webovky psaly v html, neco složitějšího, přístup do databáze a tak, v php, javascriptu.  Pár kilobajtů, největší nálož obrázky. V podstatě celý firemní web se vešel na disketu. :-( Na většinu freecoolin současných webů by to naprosto stačilo.

Ale sorry za OT :-/

A to pri tom dnes sú nástroje ktoré umožňujú robiť weby omnoho optimalizovanejšie než v Internetovej dobe kamennej (Code-spliting, lazy-loading, tree-shaking, bundlery, transpiléry, a omnoho lepší JavaScript, etc).

[Mlocik97]

Já byl předloni ve stejné situaci, nakonec jsem si napsal dvě jednoduché aplikace v Elmu. Sice ten jazyk asi velkou budoucnost nemá, ale utekl jsem všem těm Javascriptům, npmkům, bylo to docela zábavné, něco jsem se naučil, a šlo to vcelku hladce.

Hmm, a to pri tom mne osobne príde JavaScript ako najelegantnejší najjednoduchší a najrozumnejší programovací jazyk. Zaraždite ma.

Btw. tie keci typu "vyhnúť sa NPM, a ostatným stack bazmekom" od Java programátora, čo používa Maven, Gradle, JDK, JVM, a neviem čo, je ako teda o čom debata? To mi príde ako keby niekto povedal "v tomto musím 'zbytočne' vedieť X, a pri tom to viem v inom jazyku urobiť bez toho aby som vedel 'X'" (pri čom potajme zamlčíte, že v tom inom jazyku potrebuješ vedieť 'A', 'C', 'Z', 'Y', a 'K') Aneb tak mi príde kec "nechem používať NPM v JavaScripte, ale rád používam Maven a Gradle v Jave"

[Reklama]

[SB]

Případně taky Vaadin

...můžeš zkusit mrknout na Wicket....

Něco jako tyhle 2 jsem hledal - už jsem myslel, že nic takového neexistuje.
Ještě jsem našel
https://en.wikipedia.org/wiki/Apache_Struts_2 a https://en.wikipedia.org/wiki/ZK_(framework).

Mohl by mi prosím tyto 4 frameworky někdo, kdo v nich dělal, srovnat dle aktuálnosti a použitelnosti? Potřebuju to na přepracování těžkého klienta obchodní aplikace s GUI v Javě na webovou aplikaci.

[registrovany123]

Případně taky Vaadin

...můžeš zkusit mrknout na Wicket....

Něco jako tyhle 2 jsem hledal - už jsem myslel, že nic takového neexistuje.
Ještě jsem našel
https://en.wikipedia.org/wiki/Apache_Struts_2 a https://en.wikipedia.org/wiki/ZK_(framework).

Mohl by mi prosím tyto 4 frameworky někdo, kdo v nich dělal, srovnat dle aktuálnosti a použitelnosti? Potřebuju to na přepracování těžkého klienta obchodní aplikace s GUI v Javě na webovou aplikaci.

Proboha... To nepouzivej. Na to je React a Angular.

[Ondrej Nemecek]

Případně taky Vaadin

...můžeš zkusit mrknout na Wicket....

Něco jako tyhle 2 jsem hledal - už jsem myslel, že nic takového neexistuje.
Ještě jsem našel
https://en.wikipedia.org/wiki/Apache_Struts_2 a https://en.wikipedia.org/wiki/ZK_(framework).

Mohl by mi prosím tyto 4 frameworky někdo, kdo v nich dělal, srovnat dle aktuálnosti a použitelnosti? Potřebuju to na přepracování těžkého klienta obchodní aplikace s GUI v Javě na webovou aplikaci.

OMG - Struts, to už je dech historie. Ale koukám že se pořád vyvíjí.

Tak samozřejmě webových frameworků pro javu jsou tuny. Pro malý web nebo administrační rozhraní apod. nevidím problém použít třeba Sparkjava https://sparkjava.com/ jako templatovací engine třeba Velocity https://velocity.apache.org/ (nebo jiný co umí Sparkjava) a jako responsibilní framework vzít Bootstrap https://getbootstrap.com/ nebo srovnatelnou lehčí alternativu (https://bulma.io/documentation/). Nebude to frontendová single page app v javascriptu ale fungovat to bude hned. IMHO by k tomu šlo přilepit i to Vue.js a tazatel by IMHO byl tam kde chtěl být. Akorát si to pak bude must napojit na svůj backendový stack (databáze atd.) po vlastní ose. Proč ale nejít touto cestou?

Je to ostatně asi i důvod, proč takové framworky existují. Z dalších třeba https://quarkus.io/ https://javalite.io/ https://micronaut.io/ https://vertx.io/ https://javalite.io/ nebo třeba i ten i Spring Boot https://spring.io/ či obecně  „Java Web Microframeworks“.

Jiný přístup je aby si tazatel backendista udělal REST backend jak je zvyklý a k tomu připojit javascriptový framework pro single page app, ale tam se pak musí „zašpinit“ s javascriptem a těma js věcma kolem současného fronendového vývoje.

Ohledně připomínky co by mělo javistovi vadit na tom npm když používá mvn - asi tolik, že už tak má javista dost starostí se svým stackem a tak nemá chuť nabalovat další komplexitu v podobě frontendovýho js stacku, který se navíc stále mění pod rukama (= moje zkušenost pár let zpět).

[Pixe]

Obchodní aplikace znamená...? Spousta dynamicky se měnících čísílek a tak? Na to nejspíš žádný z těch zmiňovaných javovských frameworků vhodný není - tohle musí do prohlížeče

Potřebuju to na přepracování těžkého klienta obchodní aplikace s GUI v Javě na webovou aplikaci.

[L..]

...můžeš zkusit mrknout na Wicket....
Případně taky Vaadin

Něco jako tyhle 2 jsem hledal - už jsem myslel, že nic takového neexistuje.
Ještě jsem našel
https://en.wikipedia.org/wiki/Apache_Struts_2 a https://en.wikipedia.org/wiki/ZK_(framework).

Mohl by mi prosím tyto 4 frameworky někdo, kdo v nich dělal, srovnat dle aktuálnosti a použitelnosti? Potřebuju to na přepracování těžkého klienta obchodní aplikace s GUI v Javě na webovou aplikaci.

Struts ne, to je hodně těžká prehistorie.

ZK neznám, to je něco nového / malého.

Obávám se, že lidi co by měli větší zkušenosti ve více frameworcích aby mohli regulérně porovnávat asi moc nenajdeš, natož v těchhle konkrétních. O Vaadinu jsem slyšel, ale reálné zkušenosti nemám. Ve Wicketu jsem programoval pět let, programuje se v něm dobře, používá ho dost velkých firem, z bank třeba Air Bank nebo Fio.

Pokud chceš zůstat v Javě a HTML renderované na serveru vyhovuje, tak je to dobrá volba. Client-side frameworky jako React nebo Angular mají nějaké výhody, ale zas také nevýhody (nad to, že je to jiný jazyk a ekosystém). Pokud je to administrativní aplikace, tak server-side docela stačí. Kdybys tam ale měl řešit nějaké real-time aktualizace, tak je to spíš na ten client-side.

[Ondrej Nemecek]

Struts ne, to je hodně těžká prehistorie.

Obávám se, že lidi co by měli větší zkušenosti ve více frameworcích aby mohli regulérně porovnávat asi moc nenajdeš, natož v těchhle konkrétních. O Vaadinu jsem slyšel, ale reálné zkušenosti nemám. Ve Wicketu jsem programoval pět let, programuje se v něm dobře, používá ho dost velkých firem, z bank třeba Air Bank nebo Fio.

Pokud chceš zůstat v Javě a HTML renderované na serveru vyhovuje, tak je to dobrá volba. Client-side frameworky jako React nebo Angular mají nějaké výhody, ale zas také nevýhody (nad to, že je to jiný jazyk a ekosystém). Pokud je to administrativní aplikace, tak server-side docela stačí. Kdybys tam ale měl řešit nějaké real-time aktualizace, tak je to spíš na ten client-side.

Souhlas. Pro komplexnější úkoly porovnat Wicket vs. Vaadin a pro malé věci použít cokoli z těch mikro frameworků (mě vyhovuje ten sparkjava + velocity, na db používám jdbi3). Pokud to má být v prohlížeči hodně živé, je potřeba aby se to renderovalo client-side.

Pro business aplikace typu správa objednávek atd. je ještě možnost Sencha Ext JS https://www.sencha.com/products/extjs/ kde se dá pracovat jako při vývoji desktop aplikace (ale neplacená community verze je bez podpory).

A ještě je zajímavý Apache Isis https://isis.apache.org/ který má domain driver development (administrace se generuje z doménových objektů, má to automatickou podporu REST Swagger, na pozadí ORM persistence) a vypadá to hodně dobře (Apache Isis™ provides your apps with a standard, automatically generated UI. Apache Isis™ is open source, built on industry/de-facto standards, there's no vendor lock-in.), ale zatím jsem se nedostal k tomu to vyzkoušet.

Podobně funguje Brightspot Headless CMS https://www.brightspot.com/ ale na vlastní architektuře a vlastním řešení persistence. Ačkoli jsou některé verze na githubu, tak je tam nulová podpora neplacené verze a neřešené bugy. Jsou to oboje komplexnější řešení.

[mareolan]

Můžeš si zkusit, zda by ti pro rozčlenění vyhovovaly tzv. JavaScript modules. K těm npm nepotřebuješ, ale web server ano (otevření z file systému pomocí file:// protokolu nefunguje).

Použití s Vue.js by pak vypadalo nějak takhle:

index.html

Kód: [Vybrat]

<script src="https://cdn.jsdelivr.net/npm/vue@2/dist/vue.js"></script>

<div id="app">
  <grocery-list v-bind:list="foodList"></grocery-list>
</div>

<script type="module">
  import "./components/grocery-list.js";

  let app = new Vue({
    el: "#app",
    data: {
      foodList: [{ id: 0, text: "Vegetables" }, { id: 1, text: "Cheese" }]
    }
  });
</script>
components/grocery-list.js

Kód: [Vybrat]

import "./grocery-item.js";

Vue.component("grocery-list", {
  props: ["list"],
  template: `
    <ol>
      <grocery-item v-for="item in list" v-bind:item="item" v-bind:key="item.id" />
    </ol>
  `
});

components/grocery-item.js (s ukázkou templaty oddělené do samostatného souboru)

Kód: [Vybrat]

Vue.component("grocery-item", async () => {
  let templateResponse = await fetch(import.meta.url.replace(/\.js$/, ".html"));
  let template = await templateResponse.text();

  return {
    props: ["item"],
    template
  };
});
components/grocery-item.html

Kód: [Vybrat]

<li>{{ item.text }}</li>
V html si naimportuješ pouze ty komponenty, které v něm přímo použiješ, tranzitivní komponenty (grocery-item) se dotáhnou z těch přímých (viz import v grocery-list.js). A jestli chceš mít ty HTML šablony někde bokem, tak si je můžeš dotahovat tak, jak to dělá grocery-item.js. Pokud bys ty šablony chtěl mít přímo v .js souboru jako ne-string, např. JSX (nevím, jestli jsou Vue.js šablony kompatibilní s JSX), tak to by sis do stránky musel načíst něco jako babel, co by ti v podstatě provádělo transpilaci modulů (bývá to pořádný kusisko JS kódu).

[czu]

Ahoj, řešil jsem podobný problém - dělám spíš backend a čas od času jsem to chtěl i nějak odprezentovat na frontendu, ale zase jsem s tím nechtěl trávit moc času.

Kloním se k názoru, že "nenachčiješ proti větru" - frontend je hodně segmentovaný, projekty rychle vznikají a zanikají. Nemám čas ani chuť s tím držet krok, takže jsem chtěl něco de facto standardního a zároveň jednoduchého - to splňuje vue.js

Nad vue.js jsou dále postavené frameworky vuetify/quasar, které integrují celou řadu ready-to-use komponent. Ty dodržují Material design od Googlu. Není to žádná designová hitparáda a někdo může být Material designem oprávněně otrávený, ale fakt je, že se s tím dobře pracuje a hlavně uživatelé jsou na to zvyklí ze všech těch Google služeb.

Takže jsem tak nějak vysublimoval k použití quasar frameworku všude tam, kde potřebuju něco hodit na frontend. Jde použít i bez NPM, ale doporučuju tomu pár dnů až týdnů dát a používat celý framework tak, jak byl navržen. Pak už to jde víceméně samo.

[registrovany123]

Tak ja mam za to, ze jsem to asi vyresil:

Kód: [Vybrat]

vue-test.html

<!DOCTYPE html>
<html>
<head>
    <title>My first Vue app</title>
    <script src="https://cdnjs.cloudflare.com/ajax/libs/vue/2.2.6/vue.min.js"></script>
    <script src="https://cdnjs.cloudflare.com/ajax/libs/vue-resource/1.5.1/vue-resource.min.js"></script>
    <script src="https://unpkg.com/vue-chartjs@2.5.7-rc3/dist/vue-chartjs.full.min.js"></script>
    <script src="vue-test.js"></script>
</head>


<div id="components-demo">
    <button-counter/>
    <button-counter/>
    <button-counter/>
</div>


<script>

    new Vue({ el: '#components-demo' })

</script>
</body>
</html>



Kód: [Vybrat]

vue-test.js

var template = `
<button v-on:click="count++">You clfffckeddd me {{ count }} times.</button>

`;

Vue.component('button-counter', {
    data: function () {
        return {
            count: 0
        }
    },
    template
});

Neni to sice psani do tagu, ale diky tem `` se to da asi bude dat pouzivat, a moje IDE umi rozpoznat ze pisu uvnitr html. Asi to i takhle ve Vue.js zamysleli.

Tim padem si muzu takto rozdelit web do komponent, a mam timto hlavni prvek zajistujici skalovatelnost.

Jeste tak vyresiot ty importy, abych je mel pokiudmozno v 1 souboru, a budu importovat ten 1 soubor.

Wicket, Struts, Vaadin a dalsi Javovske komponentove frameworky - NIKDY! To uz radeji rozjedu NPM a budu pouzivat React.

[L..]

Neni to sice psani do tagu, ale diky tem `` se to da asi bude dat pouzivat, ...

Ve skutečnosti by tady fungovaly i normální uvozovky, ale možná je používá IDE pro detekci.

Wicket, Struts, Vaadin a dalsi Javovske komponentove frameworky - NIKDY!

Zajímavé. Proč? Struts jsou fakt prehistorie, ale Wicket jsem používal pět let a v rámci server-side render paradigmatu dobré.

Klidně beru i nelogické / osobní důvody. Já bych třeba nechtěl používat Vue / Angular (o Svelte ani nemluvě), protože nesnáším ty jejich templaty s magickými atributy a proměnnými. Pro mě je to hrozná prasárna a radši kydat žumpu, než tohle. Ale beru, že je to prostě nějaký můj subjektivní názor a ne objektivní pravda a někdo jiný to může vidět přesně opačně.