Szoktál használni CoffeeScript-et JavaScript-hez webfejlesztésnél?

Programozás

Igen
3% (8 szavazat)
Nem
55% (142 szavazat)
Csak az eredmény érdekel
42% (107 szavazat)
Összes szavazat: 257

( Hevi v | 2017. 09. 19., k – 21:03 )

Vegyuk el a scriptet onnan es akkor igaz :)

( kisbetu v | 2017. 09. 19., k – 21:40 )

Nem szoktam használni CoffeeScript-et JavaScript-hez webfejlesztésnél.

( realkry | 2017. 09. 19., k – 22:09 )

Van itt bárki aki ezt napi szinten hatékonyan használni tudja? Ha igen - és nem titkos - pár szóban összefoglalná hogy minek/miért/mire jó ez?

A Coffeescript első verziója 2009-ben jelent meg és egy csomó olyan feature volt benne, ami csak mostanában kezd beszivárogni a JS specifikációba: class-ok, fatarrow functions, string literals, deconstucting assignments, multiline strings (még egy await-szerű dolog is volt icedcoffeescriptben)

Emiatt szerintem egyértelműen kényelmesebb volt benne fejleszteni és kevesebb vizuális noise-t generáltál.

Manapság ezek már bekerültek a JS-be is, így valóban kevesebb ok van a használatára, de én pl továbbra is preferálom, mert sok olyan dolog van benne amit napi szinten használok és a vanilla JS-be (még) nem került bele. pl.:

- A C#-ból származó Existential Operator : any?.thing?.value (nem kell minden szinten ellenőrizni, hogy null-e)
- Array/Object iteration: for key, val of object, for val in array
- Array Slicing: array[0..5]
- Array comprehensions: res = (val * 2 for val in [1,2,3,4,5] when val > 3) # [8,10]

( dragi v | 2017. 09. 19., k – 22:20 )

Nem, mert typescriptet használok :)

( Aadaam v | 2017. 09. 19., k – 22:44 )

Mindig lusta voltam ezeket megtanulni, ES5, esetleh ES2016 (magyarul: javascript, böngészők által is érthető edition)

+1, főleg mióta a régebbi böngészők (IE) is könnyedén megcélozhatóak babelnek köszönhetően.

Ezekkel a JS-re leforduló csoda nyelvekkel az a fő probléma, hogy korlátozza őket erősen a célnyelv. Szóval vagy túl retek lesz a generált kód, azaz ha gond van vele, esély sincs kinyomozni mi lehet a baj, vagy gyakorlatilag JS lesz az új nyelv is, ugyanazokkal az erősen error-prone hülyeségekkel (this kulcsszó hol, mire mutat pl.), csak rászorva egy adag syntactic sugar (TypeScript pl. ilyennek tűnik nekem).

JS baromságait úgyis tudni kell ha kliens oldalra gányol az ember, más nyelvből forgatás csak tovább bonyolítja a frameworkok által egyébként is borzasztóan túlbonyolított okádék bloat JS világot. A babeles JS -> JS fordítás is már erősen büdös, de ott legalább nem kerülsz túl messzire az eredeti nyelvtől.

> "esély sincs kinyomozni mi lehet a baj"

Használj source mapet, az erre van kitalálva!

> "erősen error-prone hülyeségekkel (this kulcsszó hol, mire mutat pl.)"

Ez vaskosan PEBKAC.

> "syntactic sugar (TypeScript pl. ilyennek tűnik nekem)"

A TypeScript korántsem csak szintaxisban különbözik -- pont a különbségben van a lényeg.

> "A babeles JS -> JS fordítás is már erősen büdös, de ott legalább nem kerülsz túl messzire az eredeti nyelvtől."

Ebben viszont egyetértek veled -- eszem ágába' se volna Coffeescriptet használni.

( kiuka | 2017. 09. 20., sze – 11:38 )

ha 2 évvel ezelőtt élnék biztos használnék:)

( gee v | 2017. 09. 20., sze – 12:25 )

Se CoffeScriptet, se JavaScriptet nem használok webfejlesztésnél.

Nem használnék szívesen olyan klienst aminek fejlesztője:
A) letölteti állandóan minden lépésben a teljes view-t, ahelyett, hogy az adatra koncentrálna
B) nem érti a webtechnológiát.

Aki nem ért a javascripthez itt és most az nem ért a webes szoftverek fejlesztéséhez és pont.

Láttam én már PL/SQL-ből hajtott ExtJS-t meg sok egyéb ocsmányságot, a vége mindig használhatatlan szoftver lett felhasználói (és így minden nem tisztán "SQL fejlesztő szakmai") szemmel.

Lehet szórakozni a TypeScripttel, persze, van sourcemap is, de érteni kell, mire fordul. Majd ha transzparens lesz a szálkezelése pl, visszatérhetünk rá, de a c-ből fordított cuccok rgyelőre életveszélyesek (Az LLVM compilert emscriptennek hívják, de van python java és c# frontend is ilyen)

Uxpin vagy proto.io pl C-ben van írva, és abból van JS-re fordítva. Magyarországon a leopoly ilyen; itt találsz egy listát:

https://github.com/kripken/emscripten/wiki/Porting-Examples-and-Demos

(Mégegyszer elmondom: ha nincs nyomós okod C-ben webappot fejleszteni - a HR ok miszerint nem értesz máshoz nem tartozik a nyomósak közé- akkor ne tedd!)

Tudsz olyan use case-t mondani nekem, amikor tényleg indokolt C-ben írni, és fordítani? Tényleg érdekel, JS-t ennél jóval kevesebb dologra használok csak, jelenleg csak kísérleti projectként látom hasznát, az asm.js-nél is ezt láttam (nem teszteltem, mennyire életképes pl. játékok portolására), esetleg a portability, hogy "minden" böngészőn, js motoron fut.

Persze, van egy kész C projekted (linux kernel, legacy szoftver, stb) amit weben kell futtatnod.

Ki ne próbáld ha nem muszáj, de pl. ha azt a feladatot kapod hogy egy windows 95-re írt app fusson webről akkor ahelyett hogy citrix remote-oznád, van webes win95 emulátor, elfuthat abban szépen.

Szinte mindig érdemesebb teljesen portolni, de erre nem mindig van idő. Szerencsésebb esetben csak egy-egy lib az ami C-ben fut, tipikusan valami rendering engine.

A leopoly-nak volt valami desktop app-kezdeménye asszem, és azt rakták át. A gfx-intenzív cuccok általában C-ben vannak, ilyen a figma rajzprogram. Ennek sokszor az is az oka hogy az engine-ekhez jól értő szakemberek általában a C-hez értenek, aztán valahol API lesz a sráccal, van hogy kimegy frontendig.

A figma azért is vicces mert ugyan webes, de brutálisan gfx kártya igényes. Egy tanteremben próbáltuk használni, az intel videókártyás gépekkel konkrétan fűteni lehetett volna...

A DOM manipuláció még mindig egy szálon működik.
A Service Workerek és AJAX többszálúságát meg a nyelv nem is specifikálja, az a runtime dolga.
Magában JS-ben és TS-ben nem tudsz többszálú alkalmazást csinálni, nincs eszközöd arra, hogy megmond, hogy ez a függvény vagy az a függvény melyik szálon fusson (expliciten szálat sem tudsz definiálni).
Az csak a runtime felelőssége, hogy az I/O az ugyanazon a szálon, vagy más szálon fut, mint a DOM manipuláció. Ugyanúgy, a Service Worker is futhatna ugyanazon a szálon. Ez totálisan runtime implementáció-specifikus dolog, nem nyelvi specifikum.

Ezért mondom hogy nem transzparens a szálkezelés, mert arra használod amire a szálakat használnád leginkább, de mégse szál.

Az hogy nem a nyelv része az érdektelen, az AWT se a nyelv része hanem a platformé.

Amíg nem volt let deklaráció, addig egyszeri java programozó azt se értette, hova tűnt a változója, biztos bugos a firefox.

Az AWT sem a nyelv része, de a szálak azok igen, a nyelv specifikációjának része, hogy milyen az egyszálú és többszálú végrehajtása egy Java programnak.
Nos, ECMAScript esetén ilyen nincs, a szál definíciója sem létezik a nyelvben. Eleve nincs konkurens programozás a nyelvben, a program végrehajtása szigorúan egyszálú.
Lásd: http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.p…
"A Job is an abstract operation that initiates an ECMAScript computation when no other ECMAScript
computation is currently in progress. A Job abstract operation may be defined to accept an arbitrary set of
job parameters.
Execution of a Job can be initiated only when there is no running execution context and the execution
context stack is empty."

Illetve:
"An execution context is a specification device that is used to track the runtime evaluation of code by an
ECMAScript implementation. At any point in time, there is at most one execution context per agent that is
actually executing code."

A végrehajtás definíció szerint szigorúan egyszálú. Egyszerre csak egy Job (= ECMAScript computation) futhat.

ECMAScriptben NINCS szálkezelés, ezt kéne megérteni. Épp ezért egy nyelvi transpiler sem tud "transzparens" szálkezelést csinálni. Per definitionem nem tud foglalkozni olyan dolgokkal, hogy szálak, mert a célnyelv specifikációjában nincs ilyen.

A DOM API-kban vannak olyan részek, amelyeket lehet implementálni úgy, hogy másik szálon végezze a végrehajtást. De ez nem nyelvi elem.

Tudom hogy nincs, pont azt magyarázom hogy érteni kell az architektúrát ahhoz hogy hatékony legyél.

Szerintem az AWT-t nem a Java Language Specification definiálja, azért hoztam azt példának mert te csak a nyelvre vonatkozó szabványt írtad, a java sem csak ebből áll.

Van a VM-ekre is külön speckó valahol, tudom hogy a HTML5 javascript API része de a CommonJS definiálja talán hogy ebből mit kell szerveroldalon is tudni..

WUT?

A Java nyelv az bizony csak a JSL-ből áll.
A Java SE meg API-k egy halmazából, amit egy Java SE konform implementációnak biztosítania kell.
Ugyanígy a Java EE is API-k egy halmaza.
A nyelv mindegyiknél Java. A JLS-ben leírtakat sem a Java SE, sem a Java EE API halmazok nem változtatják meg.

A VM-ek működésére maga az ECMAScript a specifikáció. Az írja elő, miképp kell egy ECMAScript programot értelmezni és végrehajtani.

CommonJS: API-kat definiál, amiknek minden JavaScript implementációnak támogatnia kéne.
Semmi köze ahhoz, hogy egy ECMAScript programot miként kell végrehajtani. API-k csak, a nyelv nem változik, annak szemantikája ugyanaz marad. És az ECMAScript még mindig egyszálú egy Program végrehajtása során.

A CommonJS az talán a Java SE/EE dolgokhoz hasonlítható. De a nyelv, és annak szemantikája még mindig ECMA-262.
Bár nme igazán látom, a CommonJS mit akarna jelenteni: http://www.commonjs.org/specs/ Ez maga a spec? :D :D :D
Vagy ez mondjuk a Worker spec? http://wiki.commonjs.org/wiki/Worker

Na ne nevettess.

Vagy hogy máshogy mondjam: ChakraCore, V8, SpiderMonkey, JavaScriptCore: ezek mind-mind ECMAScript implementációk (VM-ek).
A node.js és társai meg V8/Chakra/whatever ECMAScript VM-et használ, csak nem éppen W3C API-kkal, hanem más API-kkal.
De ettől még a többszálúság nem része a nyelvnek. Így persze nem része a TypeScriptnek sem.

Ha új végrehajtási context kell, ahhoz új V8/Chakra VM indul el, mert definíció szerint egyszerre egy végrehajtási context létezhet csak.
Az egy dolog, hogy a node.js ad API-t arra, hogy egy új végrehajtási contextben egy *másik* Programot elindítsál. De ez egy új V8/Chakra instance-ot és egy új processzt is jelent valójában.
Lesd csak itt meg:
https://nodejs.org/api/child_process.html

Értsd már meg, itt sincs többszálúság. Nem lehet. Minden ECMAScript engine implementáció egyszere csak egy execution contextet tartalmazhat, nincs párhuzamos végrehajtás egy folyamaton belül.

Odáig eljutottunk hogy JSL ~= EcmaScript és java ee ~= commonjs

Azaz nem ecmascript ~= java ee, legalábbis eddig én így értettem hogy mit hasonlítgatsz, almamagot az almával.

Akkor következő körben abban kéne megegyezni, hogy a V8 meg a SpiderMonkey nem pusztán ecmascript implementációk, mint ahogy egy JRE sem tisztán jsl implementáció, mert hiába implementál a gcc is JLS-t, nem fog rajt elindulni egy java program se magától. Hogy a commonjs-en kívül mi mindent implementálnak még a gyakorlatban használt javascript vm-ek közösen, az részletkérdés, elő kéne kotornom.

Aztán utána rátérhetnénk az eredeti kérdésre, hogy miért kell fejből fújni a JS-t, amiben szerintem eredetileg is egyetértettünk, hogy ezeket mind tudni kell fejből ahhoz, hogy értelmesen tudj benne fejleszteni, mivel pl nincs 1-1 megfeleltetés a threadek és a workerek közt, annak ellenére se, hogy sok problémát amit C-ben hagyományosan threadekkel oldanál meg (konkrét példa: legrövidebb út számítása pl. dinamikus disktra-val), azokat javascriptben workerekkel érdemes.

A V8-ot ne a JRE-vel (amiben van rt-jar is), hanem a JVM-mel (jvm.dll) hasonlítsd össze.
Elindítasz egy V8-ot vagy Chakrát, és csak azok az objektumaid és API-jaid vannak, ami az ECMAScript specifikációban van. Semmi DOM, semmi más W3C API, nincs XMLHttpRequest sem.
Nyugodtan próbáld ki.
Nem véletlenül nincsen XmlHttpRequest node.js-ben sem, hanem saját API-juk van: a V8 nem ad W3 API-kat futásidőben.

És még mindig: ECMAScripben nincs olyan, hogy Worker. Nézd meg a specifikációt.

Ugyanúgy, mint ahogy az AWT-nek, a a JAXP-nek, a JAXB-nek, a Swingnek, az RMI-nek sincs semmi köze a JLS-hez és a JVM-hez, azok csak az rt.jar (illetve a java.base module) részei.

De a java.lang.Thread az bizony része a JLS-nek: minden Java programban elérhető kell legyen, muszáj, része a specifikációnak: minden szál a java.lang.Thread class által van reprezentálva, és nincs is más mód új szálak indítására a JLS szerint.

Mint ahogy a Number vagy az Array pedig minden ECMAScript programban elérhető kell legyen, muszáj, mert része a nyelv specifikációjának. De a Worker nem. Az bizony W3 API. Van, ahol elérhető, van ahol nem.

Semmi köze a nyelvhez.
A TypeScript pedig a nyelvvel dolgozik, nem az API-kkal, ezt kéne megértened.
A TypeScriptnek édesmindegy, hogy a runtimeban van-e Worker API, van-e másmilyen API, nem törődik vele. Számára nagyon kevés objektum létezik. Ezt kéne megértened. Ezért nincs semmi, de semmi értelme arról beszélned, hogy mennyire "transzparens" a TypeScript "szálkezelése". Maga a nyelv (sem a TS, sem az ES) nem ismeri azt a fogalmat, hogy szálkezelés.

Olyan ez, mintha azt kérdeznéd, hogy milyen a Java nyelv XML kezelése és az hogyan viszonyul a Scala nyelv XML kezeléséhez. Nos, nincs egyiknek se olyanja.

"Ezért mondom hogy nem transzparens a szálkezelés, mert arra használod amire a szálakat használnád leginkább, de mégse szál."

Egyébként ez konkrétan miben akadályoz meg téged, hogy nem a "klasszikus" értelemben vett módon tudod kezelni a szálakat? Milyen usecase létezik, ahol jobb volna magadnak létrehozogatni, futtatgatni, szívni lockolással, miegymással? (Egyébként ha akarsz, már azt is tudsz)

Nincs shares memory space, ennek minden implikációjával (expanzív adatfeldolgozás halott)

Pl tegyük fel hogy tudod hogy 3 lépésben dupláuódni fog az adatok száma, 10 dologból 20, abból 40 lesz, majd visszaredukálódik.

Mi sem egyszerűbb, inditasz mindkét szinten két szálat - ja, amíg rá nem jössz, hogy az adat amivel dolgozol másolódok, és a másolás több időt eszik mint amennyit spórolnál a párhuzamosítással.

Még mielőtt valaki jönne hogy ez exponenciális: ismert véges térben maradnak a műveletek. Rakás térképészeti probléma ilyen - meg kell nézni a szomszédos vagy épp az "alatta lévő" cellákat vagy egyéb kötegeket.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Globa…

Mondjuk ez szerintem mar tenyleg megeroszakolasa a JS-nek. Nem sok usecase-t tudok azon kivul, hogy a Piratebay-en meg a filmezz.eu -n a hatterben futo crypo miner egyszerre égethesse az összes core-t a gépeden/telefonodon. [via]

A) előnye: a kinézethez úgy lehet hozzányúlni, hogy minden kliens azonnal frissüljön. Lásd mondjuk a hybrid mobilappok: az alkalmazást frissíteni a te munkádon felül 2-3 nap egy store-ban, míg a te kontrollod alatt lévő kiszolgálót frissíteni, az csak tőled függ. És van, amikor életbevágóan fontos javítani. Mint például akkor, amikor egy GPU bug miatt elhal a WebView, ha scaled canvast használsz. Ilyenkor kitenni egy olyan klienst, ami nem crashel, nem csak tőled függ, hogy mennyi idő. Míg ha szerver oldalon dől el a rendering, akkor rajtad múlik minden.
Hasonlóképpen, kisteljesítményű kliensek meghálálják azt, hogy nem pörög fel a laptop ventilátora, amikor böngészel. Egy előre legyártott HTML struktúrát sokkal gyorsabban renderel a böngésző, mint a DOM-manipulációs JS-sel összeállított HTML struktúrát.

Igen, ez az előnye, a hátránya pedig az, hogy nincs konkrét interakció oldalújratöltés nélkül. Képzelj el egy chat alkalmazást, ami minden sor beírása után újratölti az oldalt, és még X másodpercenként, hogy lássad az új üzeneteket.

Szándékosan extrém példát alkalmaztam. Arra akarok rámutatni, hogy nem mindenhol életképes az, hogy szerveroldalon rendereljük a kész oldalt, hiába előny az, hogy kevésbé pörög a venti. Hasonlóan sok helyen felesleges a kliensoldalon futtatni dolgokat. Lásd pl, a HUP egész jól elvan a szerveroldali rendereléssel, némi JS kiegészítéssel.

A dolog szépsége az, hogy bár mindkettőnek megvan a helye, emberek folyton azon vitatkoznak, hogy melyik a jobb, és bizonygatják, hogy a másik miért szar :)

Mondjuk DOM-heavy chatet sem jó dolog szerintem HTML-ben megoldani. Én azt sem szeretem, hogy ma már szinte minden multiplatform alkalmazás Electronnal megy, aztán csodálkozunk, hogy nem reszponzív, lassú, memóriazabáló alkalmazásokat használunk.

Lásd: Atom, Brackets, Visual Studio Code: atomlassúak egy rendes natív szerkesztővel szemben.

Beszelhetek en itt a levegobe, dehat ha csak a kalapacsot ismerik az emberek...

De az meg hagyjan lenne, hogy lassu, de mivel altalaban webdevek keszitik ezeket az asztali programokat, ezert alapvetoen a usability valahol a beka segge alatt van.

Ja weben elvannak, meg fasza, reszponziv, de egy desktop appnak teljesen mas felteteleknek kell megfelelnie.

Szar az egesz, na.

Lehet szidni az Electront, meg utálni a webalkalmazásokat, de

1) Kisebb biztonsági kockázatot jelent egy böngészőben futó webapp, mint egy random alkalmazás, ami hozzáfér mindenhez a gépeden. Nevezz paranoiásnak, de lásd pl a híreket arról, hogy a skype kliens kutakodik a home mappádban, vagy lásd a jogosultságokat, amiket a FB mobil alkalmazás elkér magának Androidon.

2) Legalább léteznek. Egyébként mint Linuxos kénytelen lennék wine-vel szórakozni, ami vagy működik, vagy nem, mert sajnos a szoftverek készítői ha natív alkalmazást csinálnak, akkor vagy leragadnak a Windowsnál és az OSXnél, vagy kiadnak Linuxra is valamit, ami funkciószegény, és nincs karbantartva egyáltalán. Szóval akkor már inkább legyen egy webapp, ami fut mindenhol, és csomagolják be electron app-ba, vagy böngészőkiterjesztésbe.

1. Az Electron ugyanolyan jogokkal fut, mint egy Skype, szerinted hogyan tudna megnyitni tetszőleges fájlt például? :D Ugyanúgy kutakodhat egy Electron app a home mappádban - ja, az új Skype is Electronos ám.

2. Natív technológiákkal is lehet multiplatform alkalmazásokat készíteni, lásd: Qt. .NET is van minden platformra, ha kell.

Légyszi olvasd el ismét, amit írtam. Az első pontban a biztonságnál szándékosan nem említettem az electront, csak a webappokat.

A kettes pontban tök igazad van. Elméletben. A gyakorlat viszont az, hogy régóta van a fejlesztőknek lehetősége több platformot támogatni úgy, hogy egy kódbázist tartanak fent, mégsem teszik. Hiába van .net/mono, hiába van java, qt, akármi. Legalábbis ez a tapasztalat.

Sőt, electron is hiába van, ha nem készül belőle release a platformodra. De ott legalább megvan az esélye, hogy az elektron appok mellett létezzen weboldal, hiszen a fejlesztők a kettőt egy csapásra meg tudják valósítani.