Brave

Mivel valaki ma Google Chrome alternatívaként említette, ismét ránéztem.

Még mindig szar.

1, Az Users\AppData\Locals-ba települ. Nem választhatsz más helyet. A telepítésnél 1 opciód van: akarod telepíteni? Igen/nem.
2, Homályosak a betűk, ugyanazon a gépen semelyik másik böngészővel nincs probléma. Video driver friss.
3, Valami tokenes, jutalmazós rendszerrel akar rávenni, hogy reklámok megjelenhessenek a reklámszűrője mellet. Amikről úgy gondolja. Ő.
4, Nem is gyorsabb, mint a ffox vagy a chrome.
5, Randa.

Eltávolítás után a komplett telepítési mappát meghagyta, csak a Brave.exe hiányzik. MINDEN más ottmaradt.

Ez egyszerűen értelmetlen.

Egy darabig nem nézek rá, bár sanszos hogy soha többet.

Én régóta használom, főleg Macen, de nagyon fura dolgai vannak, amik miatt esélye sincs, hogy elsődleges böngészőként gondolhassak rá.

Néhány site-on elrontja a scrollozási sebességet (néha hiperűrsebességre kapcsol), vagy állandóan mutatja a belépéshez szükséges, elmentett nevet és jelszót tartalmazó popupot, vagy néha úgy dönt, hogy eleget nyomkodtam már lapozáshoz a le-nyilat, és akkor megint rá kell kattintani a tabra, hogy kegyeskedjen figyelni. Legalább egy évig tartott nekik kijavítani azt is, hogy amikor egy linket új tabban nyitunk meg (pl középső egérgombbal), akkor az új tabon ne a location bar és benne az URL legyen alapból fókuszban és kiválasztva -- ez engem rettentően zavart, mert billentyűzettel szeretek lapozni.

Mindegy, ingyenes, és kísérletnek jó.

( TCH | 2019. 01. 28., h – 08:28 )

Mit vártál? N+1 krómilyum fork, ráadásul az a fickó felelős érte, aki a dzsuvaszkriptet a világraszarta.

Anno én is fikáztam, amikor ránéztem egy-egy JS kódra, mert olyan átláthatatlan spagetti áradat volt sz összes. Viszont amióta belementem a JS világába, azóta rájöttem, hogy sok jó dolgot lehet vele csinálni és szépen. Viszont én csak kliens oldali nyelvként tekintek rá. Egyszerűen nem bírom amikor szerver oldalon is azt nyomják, vagy kliens oldalon mindent a JS csinál meg.

---
"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

Ennyi. Van aki értelmesen is tudja kezelni. Igen vannak benne tervezési defektek, de ha valaki veszi a fáradtságot, kicsit belemegy, akkor ezek mind kezelhetők. Én pont azok miatt kezdtem el JS-t tanulni, akik szerint szar. Kíváncsi voltam, ha ennyi ember utálja, akkor miért ennyire elterjedt?! Elolvastam egy csomó könyvet, megnéztem egy tonna előadást róla. Már máshol is mondtam, nem vagyok programozó, nem programozok, valamiért szeretek programozási nyelvekről olvasni, videókat nézni. Szeretek megismerni "új" nyelveket.

A JS -- ahogy említetted -- hozzáértők kezében nagyon hatékony és biztonságos eszköz. El kell olvasni Douglas Crockford nagyon vékony könyvét arról, hogy mit kell benne elkerülni, és kész. Mivel rettentően dinamikusan fejlődik (ez főleg az "örökzöld" böngészőknek köszönhető), olyan lehetőségekhez férhet hozzá bárki, amit például C#-ban külön "be kell kapcsolni" (Linq). Ha valaki a típusos megközelítést preferálja, annak igen jó hír, hogy a TypeScript fejlesztését (JS-re fordul) ugyanaz az illető koordinálja, akinek a C#-ot köszönheti az emberiség.

Szóval ki lehet röhögni a JS-t, de ez csak azt bizonyítja, hogy a röhögcsélő jóember nem konyít hozzá, illetve leragadt valamikor a 2000-es évek elején, és ez utóbbi főleg eléggé kínos lehet.

> Szóval ki lehet röhögni a JS-t, de ez csak azt bizonyítja, hogy a röhögcsélő jóember nem konyít hozzá, illetve leragadt valamikor a 2000-es évek elején, és ez utóbbi főleg eléggé kínos lehet.

Erre csak ugyanazt tudom mondani, mint ennek a posztnak a második bekezdésében.

Az igaz, hogy még annál is szarabbul használják, mint amennyire a nyelv szarsága önmagában indokolná, de miért használják így? Mert a nyelv megengedi. Mert ez a nyelv mindent megenged. Aztán meg olvad a CPU az alaplapban, amikor értelmezni kéne azt a gigászi katyvaszt, ami lesz belőle. Nem lehet az egészet a webgányerekre kenni, max. a felét. Abban igazad van, hogy agyatlan barmok agyatlan szar kódot írnak benne, de sajnos maga a nyelv is agyatlan.

Szerintem az nem a nyelv hibája, ha könnyen lábon tudod magad lőni vele (meg másokat).

A C is mindent megenged, mégse szidják. Talán azért, mert sokkal jobban érzed, amikor lábon lőtted magad, és ezért hamarabb megtanulod, hogy mit ne tegyél. 

int getRandomNumber() { return 4; }  // ← aláírás
//szabályos kockadobással választva. garantáltan véletlenszerű.  xkcd

Nem, az az ostobak miatt szukseges. A Math.abs(x) == x egyertelmuen megmondja, hogy a szam pozitiv vagy nulla-e, ennek az eredmenyet kell negalni ha negativot keresel. Es ez Vanilla.js

Az npmjs.org -on szerintem kmplett frameworkok vannak az osszeadasra is. A legszomorubb az egeszben, hogy ezektol mas komplett frameworkok fuggenek.
--
Blog | @hron84

Szerintem Math.abs(x) != x -t használni arra, hogy megnézd, hogy negatív-e eléggé "hacky", csökkenti az olvashatóságot és valószínű performancia szempontjából sem a legelőnyösebb.

valamint: 


isNegative = function(n) { return Math.abs(n) != n }

isNegative("-1") -> true
isNegative("a") -> true
isNegative([]) -> false
isNegative({}) -> true

Ha számít az ilyen típusú kiszámíthatatlanság, akkor beleírhatunk n < 0 -t is

Szóval ha biztosra akarunk menni akkor: 

typeof n === "number" && n < 0

Bár biztos van amikor ez sem működik, mert az isNegative a legújabb verzióban a typeof-ot lecserélte 

toString.call(n) === '[object Number]'

-ra

(Btw a typeof esetén miért nem kell zárójel?)

Update: meg is van miért nem szabad typeof-ot használni a típus ellenőrzésére: 

isNegative(("hello", -1)) -> true

logikus...

A typeof egy operátor, nem egy függvény, ezért nem kell zárójelbe tenni.
És azért nem jó a typeof-os ellenőrzés, mert ha a = new Number(5); akkor typeof a értéke "object".
És azért nem lehet a.toString()-et használni, mert ekkor a végeredmény "5" lenne, viszont a toString.call(a) értéke "[object Number]".
De hát ehhez ismerni kell a JS-t rendesen, nem elég csak felületesen tudni a dolgokat.

Ez nem nyelvfüggő, az IEEE 754 szabvány szerint a NaN semmivel nem egyenlő, önmagával sem.
Valamint a szabvány szerint bármely műveletre, ha annak inputja NaN, az eredménynek is NaN-nak kell lennie.
Ez a két viselkedés (azaz f(NaN) értéke NaN, valamint NaN != NaN) adja a fenti eredményt. És nem nyelvfüggő dolog ez, hanem az IEEE 754 miatt van.
De ehhez meg az IEEE 754-et kell ismerni, meg azt, hogy a JS-ben a number típis igazából IEEE 754 duplapontosságú lebegőpontos számok, ahol van NaN.

De az, hogy ezt implementaltak, megiscsak egy tudatos dontes volt. Es ennek a dontesnek az ertelmet vonom ketsegbe.

Mert ha valami nem egy szam, az engem baromira nem hoz lazba. Egy betu se egy szam, meg egy metodus se, aztan a tipusuk megse Not a Number, pedig tok igaz.

Engem nem az erdekel, hogy az adott valtozo mi _nem_, hanem az, hogy mi _igen_. Ha nem szam akkor mi? Jahogy parseolni akartam, vagy szamtani muveletet vegezni vele, de nem lehet? Akkor a megfelelo mukodes a(z) (lekezelheto) error, nem pedig valtozo ertekkent letarolni, hogy az adott valtozo mi nem.

Miért vonod kétségbe a döntést? Az IEEE 754 jelenleg a lebegőpontos számításokra kifejlesztett legjobb szabvány, a legjobb ismereteink vannak benne, amit lebegőpontos számításokról tudni lehet.

És az IEEE 754 szerint érvényes fogalom a NaN, pont olyan értékek jelzésére, amik nem értelmesek (például 0-nak a 0-ik hatványa, vagy a végtelen/végtelen alakok). Nem véletlenül létezik, és az, hogy valami NaN, nem azt jelenti, hogy bármi, ami nem szám (objektum, string, dátum, függvény), hanem egy speciális lebegőpontos érték, okkal létezik.

Szép is lenne, ha mondjuk van egy lebegőpontos számokat használó függvényed, és JS-ben másként működik az aritmetika, és ezért mást eredményez, mert ők nem követik az IEEE 754-et.
Az egésznek a lényege, hogy a számítás reprodukálható legyen bármelyik IEEE 754-kompatibilis platformon, és minden ésszerű lebegőpontos platform IEEE 754 kompatibilis.

> vagy a végtelen/végtelen alakok). Nem véletlenül létezik, és az, hogy valami NaN, nem azt jelenti, hogy bármi, ami nem szám (objektum, string, dátum, függvény), hanem egy speciális lebegőpontos érték, okkal létezik.

En ezt el is hiszem, de a JavaScript kontextusaban a NaN sajnos egy szinten van a fuggvennyel, datummal, stb. Ha Number.NaN lenne a tipusa, semmi problema nem lenne.

De meg mindig: ha a szamitasom eredmenye nem ertelmes, arrol azonnal akarok visszajelzest, hogy ne kelljen PHP fele error_get_last() fele szornyusegekkel foglalkozni.

Tovabba arra utaltam, hogy a masik EcmaScript nyelvben ezt meg tudtak oldani ertelmesen, es nem random vannak dolgok elszorva a nevterben, hanem normalisan rendezve vannak hierarchikusan...

https://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/Num…

Mi olyan specialis a "nem vagyok szam" ertekben, hogy nemhogy kulon erteket kell neki adni, de egyes nyelvek szerint ugyanolyan fontos fogalom, mint mondjuk a kulcsszavak, vagy a beepitett fuggvenyek, hiszen ugyanazon az absztrakcios szinten erheto el, mint azok?

Az szerintem nem külső függőség - a rendkívül komplex tesztet JavaScriptben írták. Az NPM-en minden tizenegysoros függvényhez külön csomagot írnak – amit ott látsz, az néha vicc :-)

int getRandomNumber() { return 4; }  // ← aláírás
//szabályos kockadobással választva. garantáltan véletlenszerű.  xkcd

Ha valaki ilyen dologra függőséget kell használjon, az menjen inkább kukoricát kapálni. Attól, hogy mindenféle sz@rt össze tud taknyolni egymással, még nem tesz senkit programozóvá. Aztán meg a nyelvre mutogat, hogy szar. Meg kellene tanulni rendesen használni. Nem kell félreérteni, nem védem a JS-t, ennek is megvannak a hibái, mint más nyelveknek.

De miért programozza le mindig mindenki ugyanazt, esetleg hibásan, és tartsa karban?
Az egész amiatt van, hogy JS weakly és dynamically typed, nem pedig egy erősen típusos nyelv.
Amiatt kell csomó utility lib, hiszen nem tehetsz feltételezést a bemenetként kapott paraméter típusával kapcsolatban, így az értékkészlete is totál rejtély a kód számára. Ha pedig az értékkészlete a kapott paramétereknek rejtély, akkor bizony nehéz egy állapotgépet biztonságosan működtetni, class invariantokat kikényszeríteni stb.

A C koránt sem enged meg annyi mindent nyelvi szinten, mint a JS. Az, hogy nincsenek típusok, csak különféle bitszélességű számok vannak, meg pointerek, meg offsetek, az nem jelenti, hogy mindent megenged. JS-ben viszont elméletileg vannak típusok, viszont gyakorlatilag ezek össze vissza kutyulódnak, néha olyan inkonzisztens módon, hogy az ember csak fogja a fejét. https://i.stack.imgur.com/35MpY.png

Aztán meg olvad a CPU az alaplapban, amikor értelmezni kéne azt a gigászi katyvaszt, ami lesz belőle.

Nekem nem csinal ilyet, de még az a 20 nodejs service is igen elenyésző CPU időt fogyaszt itt fejlesztés közben. Hogy kell fogni, hogy ilyen nagyon rossz legyen?
--
HUP Firefox extension | Hupper hibajelentés

Akkor olvasd el még egyszer, mert én azt írtam, hogy fifty-fifty a felelősség eloszlása az agyatlan nyelv és az agyatlan fejlesztők között.

Ami pedig a keretrendszereket illeti: de részei a nyelvnek. Nem a nyelv felépítésének, vagy a specifikációjának, de egy nyelv ezeken túlmutat. Egy nyelvhez nem csak a szintaxis vagy a compiler/interpreter tartozik, hanem a mögötte álló fejlesztői társadalom és annak a kúltúrája is. És ennek a kúltúrának - az ún. "webkettő" kúltúrának - bizony szerves része az, hogy húszezer megoldás születik ugyanarra a problémára, amiből tizenkilencezer-kilencszázkilencvenkilenc teljességgel agyatlan. Mert a nyelvek maguk is agyatlanok. És populárisak. (Igen, ez a PHP-ra is vonatkozik.) Sokan foglalkoznak velük, ezért sok megoldás készen van hozzá - csak éppen a fent említett agyatlansági aránnyal, mert egyfelől ezek a nyelvek mindent megengednek, tehát könnyű bennük "programozni", másfelől meg könnyű hozzájuk anyagot találni a pouplaritásuk végett, ezért mindenki "ért hozzá" és ezért rengetegen csinálnak saját "keretrendszert", amiben egyrészt a többiből ollóznak össze marhaságokat, részben pedig saját kútfőből szállítanak olyan megoldásokat, hogy néha csak pislog az ember, mint egy intel-vezérelt szemafor. A mainstream irányvonal fluktuációjáról meg jobb nem is beszélni, egyik héten ez a framework a menő, a másik héten meg az, és az előzőt már ott fikázzák, ahol csak tudják, hogy elavult, meg szar, meg amit csak akarsz. Pedig ez nem hús, hogy egy hét alatt megromoljon. Ha most szar, akkor eddig is szar volt.

A webkettő kúltúra tagjainak elsöprő többségének gőzük sincs arról, hogy mit csinálnak és hogyan és ez kurwára meglátszik a mai weben.

Sz*rk: Ja, ezt kifelejtettem: a JS esetén még ott van a böngészőmotoronkénti eltérő implementáció; minden böngésző máshogy értelmezi a kódot. Ezért is van annyi böngészőspecifikus megoldás (meg króm-only oldal).

Háttérben futó, zenehallgatásra megnyitott soundcloud tab: Memory footprint: 983MB, JS memory: 441MB, CPU time: 2h 59m 42s

Szerintem ez nem annyira oké, bár tény, hogy 20-at is elbírna belőle a gépem, de valószínű a 20 évvel ezelőtti gépem is le tudott játszani ennyi mp3-at egy időben.

( pehsa | 2019. 01. 28., h – 11:18 )

A Brave-t én is nézegettem régen, de nekem se jött be. Amikor hallottam a hírt, hogy ilyen saját rendszert raktak bele, ami igazából tiltja a reklámokat, de megszabhatod, hogy melyik oldalnak fizessen a Brave na akkor már temettem.

---
"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"