Dnes se podíváme na zoubek novému frameworku koa. Koa je lehký serverový framework, který používá ECMA6 generátory pro tvorbu middleware. To má několik důsledků, například se v aplikaci nevyskytují nepřehledné callbacky a middleware se chová jako skutečný middleware, tedy může provádět akce před i po předání řízení nižším vrstvám aplikace.
Jak je to s přístupností mobilního menu z klávesnice? Používáte odkazy “více” a “zde”? Znáte rozdíl mezi aria-label, aria-labelledby a aria-describedby? Je PDF strojově čitelný formát z pohledu zákona o přístupnosti?
Posledních pár let mě baví se zabývat bezpečností aplikací. Čistě technicky. A když člověk tyhle věci implementuje, dostane se k zajímavým problémům, které by ho ani nenapadly. A tak se stalo, že jsem se dostal k proxy. Jako slepý k houslím.
Proč jsou ECMAScript moduly lepší než CommonJS? Už nastal ten správný čas přepsat všechny své NPM balíčky na ECMAScript moduly?
n versus nvm
Je nejaka vyhoda pouzit
nproti podle me rozsirenejsimunvm?Na n jsem narazil dříve, pravděpodobně to je jedno.
Re:
Jen je potreba to poustet trochu jinak pomoci:
NODE_ENV=development PORT=3000 DEBUG=* nvm run v0.11.12 --harmony app.js
nvm místo n
Díky za tip
Výhody oproti jiným
Chtěl bych se zeptat, jaké výhody (klidně osobní názor) má koa oproti jiným frameworkům jako třeba Sails, Meteor nebo třeba geddy? Nikdy jsem v koa ani v expressu nic pořádného neudělal a teď objevuju Sails, ale pořád mi koa připadá moc low-level, kdežto třeba právě v Sails mám rozvrženou architekturu, modely, ORM, automatické routování na controllery, a tak dále. Možná je ta výhoda právě v té úplné svobodě. Možná to vyplívá z určité lenosti, ale podle mě je pohodlnější používat nějakou nadstavbu, která může mít třeba právě koa jako takové jádro.
Re: Výhody oproti jiným
Dobrá otázka.
Express je vlastně taková nadstavba nad connect (+ velice jednoduchý scaffold, který se časem opět odštěpil). Vše důležité je udržováno v connectu a pokud se middleware ukázalo jako „věc názoru, preference,“ přechází potom do express a tam se opět časem vyštěpí do samostatného mudulu (příkladem třeba může být
connect.multipart())Koa je nástupcem expressu a connectu v tomto smyslu. Jeden z hlavních vývojářů (TJ Holowaychuk) je také iniciátorem tohoto projektu.
Koa se nesnaží v současné době nahradit express ani connect (vysvětlení zde), pouze jde dál a používá nové jazykové prostředky, jak tomu je u mladých (nebo přelomových technologií). Porovnejte například .NET 1.1 a 3.5. Proto pořád v perexu to ECMA6 (no, vlastně jen generátory). Snaha je ukázat, že to jde jinak/lépe již se „stávajícími standardy“
Sails je oproti tomu komplexní framework včetně scafoldu, který začátečníkovi nabízí vše co ho napadne.
Comet je oproti tomu úplně jiný přístup k celé aplikaci. Tímto směrem se se ubírá Meteor.
Můj osobní názor je, že se technologie v určitých oblastech bude posouvat směrem k Meteoru, ale netřeba nyní spěchat. Dan Steigerwald (snad to mohu prozradit) se v blízké době chystá psát o Reactu v souvislosti s Polymerem a Angularem, tak se budu těšit…
Musím přiznat, že Meteor mě hodně zaujal jak pozitivně tak i negativně, ale to už je ta věc názoru :-)
Re: Výhody oproti jiným
Omlovám se, zapomněl jsem reagovat na geddy. Neznám, ale vy padá to zajímavě. Má spoustu použitých modulů a mezi nimi třeba i socket.io.
Můžeš uvést pár odkazů na přiklady? Možná, jestli máš zkušenost, nebylo by marné napsat krátký článek nebo zprávičku! :-)
Re: Výhody oproti jiným
Díky za rozsáhlou odpověd. Koncept middleware, jak je chápan v connect/express/koa a implementován formou
use, je vážně dobře vymyšlen. Jen tak na okraj, nedávno jsem narazil na tohle, což mi přijde docela brutální.Jinak s těmi novými jazykovými prostředky, takovéto probublávání requestu dolu a zpátky nahoru pomocí
yield, to mě vážně zaujalo. A třeba časem přijdou s dalšími novinkami z ECMAScriptu 6, uvidíme.Se Sails jsem teď začal, protože mě baví Angular a potřebuji jenom backend, který mi vytvořit v Sails přijde velmi pohodlné, protože je tam právě vše předpřipraveno. A začlenení socket.io má taky zajímavé. Protože jestli jsem to správně pochopil, nabízí i klientskou knihovnu a spolu umí vytvořit Real-time REST nebo jak to nazvat.
Meteor se mi taky líbí a jeho propojení serveru s klientem je vážně super (díky za odkaz na Comet). Taky jsem ho zkoušel, a přijde mi docela uzavřený, nic moc k nakonfigurování. Ale nic pořádného jsem v něm nevytvořil.
A co se týče geddy, tak ten jsem bohužel ani nezkoušel, pouze jsem na něj narazil, tak jsem ho uvedl jako příklad. Takže odkazy bych uvést mohl, ale jen bych googlil. Každopádně o Sails, až ho pořádně prozkoumám, bych článek napsat klidně mohl, kdyby byl zájem :-).
Re: Výhody oproti jiným
Taky mě teď napadlo, že ta provázanost klienta se serverem v Meteoru nám neumožňuje styl napsat si backend a ten používat např. pomocí RESTu na více klientech (browser, iOS, Android, …). Nebo to tak není?
Prostě všechno má svá pro a proti. Každopádně, vím, co jsem potřeboval, díky.
Tak to je vážně síla :-D Takový kód/modul raději vyloučit na začátku. Jistě to lze vyřešit lépe i bez použití nějakého promise modulu, například pojmenováním funkcí.
chrome://flags/#enable-javascript-harmony) a tento stav potrvá, dokud nebude ES6 dokončenaDobrá zpráva ale je, že už dne tu je traceur, takže novinky lze používat již nyní ale rychlost a efektivita bude pravděpodobně nižší.
Ano, to je nevýhoda, nevím jakým způsobem to Meteor řeší, ale programátor by to měl řešit segregací modelu a aplikační logiky. Meteor je ještě mladý a neotestovaný a potenciálně nebezpečný pro nezkušeného programátora (vynesení aplikační logiky na veřejnost), jistě není vhodný na veřejně dostupné účetní a bankovní aplikace