Kunstenares maakt gedetailleerd werk met alleen html en css

Kunstenares Diana Smith heeft zich erop toegelegd werk te maken met behulp van alleen css en html. Bijvoorbeeld een soort achttiende-eeuws schilderij van een vrouw, genaamd Pure CSS Francine. Een leuke bijkomstigheid is dat het er in verschillende browsers anders uitziet.

Smith zegt tegen Motherboard dat ze ongeveer twee weken doet over elk werk, dat op GitHub te bekijken is. Op de pagina van Pure CSS Francine legt ze de regels uit die ze zichzelf heeft opgelegd. Zo moeten alle elementen met de hand getypt worden, mag ze alleen de Atom-teksteditor en Chrome Developer Tools gebruiken en beperkt ze het gebruik van svg's.

Door het gebruik van alleen css en html zien haar creaties er in verschillende browsers anders uit. Daarover zegt ze tegen Motherboard: "Als je de afbeeldingen in verschillende browsers bekijkt, kijk je op een bepaalde manier terug op de geschiedenis van het internet en wat er in de tijd van werd verwacht." Dat de resultaten verschillen per browser, daar kwam ook de onlinegemeenschap in de afgelopen dagen achter. De resultaten zijn onder meer hier te bekijken.

Lees meer

IT-banen

Reacties (92)

Dreamvoid 4 mei 2018 19:47

Dat zouden meer websites moeten doen, gewoon HTML5/CSS zonder JavaScript.

IvoPlas @Dreamvoid • 4 mei 2018 20:19

HTML en CSS zijn leuk om te gebruiken voor vormgeving maar JavaScript gaat komende jaren het internet veranderen. We zijn op weg naar progressive web apps die de potentie hebben apps overbodig te maken. Zo krijgen progressive web apps de mogelijkheid om hardware aan te sturen zoals bijv. bluetooth en worden ze net zo snel als een native app.

Hier legt Google uit wat het precies is:
https://developers.google.com/web/progressive-web-apps/

Dreamvoid @IvoPlas • 4 mei 2018 20:35

Ja idd, en dat gaat in mijn ogen de exact compleet verkeerde kant op. We hebben niks geleerd van het Flash fiasco. Remote unaudited code van het web runnen, doe mij maar native apps die iig nog door een store check zijn gekomen en signed zijn door de developer. Als je de gemiddelde website opent draait er mystery JS code van twintig verschillende domeinen.

JorzoR @Dreamvoid • 4 mei 2018 23:00

Je argument met een mystery van JS code van verschillende websites is niet het probleem van Javascript zelf, maar ligt aan de beheerders van die websites

Met beheerders van sommige websites gaat het de verkeerde kant op, of anders gezegd; marketing afdelingen van bedrijven. Die willen alles van je weten en meten met externe diensten, dat is in native apps trouwens niet geheel anders

Ik ben helemaal voor PWA's. Alleen mobile Safari moet nog even goed meewerken. Zou sommige diensten ook een heel stuk goedkoper _kunnen_ maken als native apps niet meer nodig zijn voor iets wat een PWA ook prima kan

[Reactie gewijzigd door JorzoR op 24 juli 2024 14:35]

Ed Vertijsment @JorzoR • 5 mei 2018 00:07

Alleen mobile Safari moet nog even goed meewerken

Volgens mij kan je tegenwoordig prima Service Workers draaien op iOS: https://caniuse.com/#feat=serviceworkers

JorzoR @Ed Vertijsment • 5 mei 2018 17:09

Mobile Safari verliest compleet je vorige “state”. Dus bij iedere start kan je opnieuw beginnen. Dat is echt een hele slechte user experience voor PWA’s. In die zin is het redelijk onbruikbaar nog op Mobile Safari

Zie:
https://medium.com/@firt/...ios-are-here-d00430dee3a7

[Reactie gewijzigd door JorzoR op 24 juli 2024 14:35]

latka @JorzoR • 5 mei 2018 18:24

Uhm, jawel: de JS code kan van alles doen (en steeds meer) en er is geen enkel betrouwbaar mechanisme of te achterhalen welke JS code wat doet en waar het vandaan komt. Heeft niets met de beheerder van de website te maken maar met de ontwikkelaar die met behulp van NPM megabytes aan ongeverifieerde code in zijn project trekt om dat dan naar productie te laten zetten. Die code krijg ik dan op mijn CPU draaien en kan daar van alles doen waar ik niet om gevraagd heb (het permissie/sandbox model is erg beperkt). Een coinminer in JS meeleveren is een peuleschil en ik kan er niets tegen doen behalve JS uitzetten. Maarja, gracefull degredate dat maar eens. JS in de huidige vorm is gewoon Flash: mijn PC wordt trager door doe hoeveelheid bagger JS die meekomt en ik kan er weinig tegen doen. Volgens mij alles wat men tegen flash had indertijd.

JorzoR @latka • 6 mei 2018 11:05

of te achterhalen welke JS code wat doet en waar het vandaan komt.

In Chrome Dev Tools kan je anders prima zien wat er allemaal gebeurt, is voor iedereen toegankelijk. Uiteraard heb je wel wat technische kennis nodig.

Verder zijn de argumenten die je aanhaalt toch echt nog steeds een beheerder probleem; of een slechte developers probleem. Goede JS developers weten wel beter

[Reactie gewijzigd door JorzoR op 24 juli 2024 14:35]

latka @JorzoR • 6 mei 2018 13:20

Chrome devtools ken ik wel maar minified JS leest voor geen meter. En goede JS developers: zodra NPM aangeslingert word om is-even of is-odd te includen ga je mij niet meer wijsmaken dat je een goede developer bent (JS of iets anders).

JorzoR @latka • 6 mei 2018 16:51

Daar noem je ook een domme reden om NPM te gebruiken. Staat verder los van t feit waarom NPM wél handig is en er developers zijn die het wel goed inzetten

latka @JorzoR • 6 mei 2018 19:59

Nergens zeg ik dat NPM onhandig is, alleen de gemiddelde kwaliteit van de packages is discutabel en als je ziet hoe er mee gewerkt wordt in de praktijk (geen review van de 3rd party meuk die gedownload wordt) is het een recipe for disaster. Hele kuddes programmeurs gaan nog jaren geld verdienen met het onderhouden van deze code.

Verwijderd @latka • 7 mei 2018 10:07

Je kunt het leesbaar maken door in the devtools te klikken op { } > pretty print. Dat staat linksonder het venster waarin je de js-code ziet :-)

latka @Verwijderd • 7 mei 2018 13:42

Dan is de indentatie ok, maar alle variabele namen zijn vreselijk ;-)

unfold @JorzoR • 5 mei 2018 08:33

Technologie is niet neutraal. De keuze in welke richting we webtechnologie ontwikkelen maakt uit voor wat als 'normaal' en 'wenselijk' wordt gezien.

Gopher @JorzoR • 7 mei 2018 08:07

Ik weet niet, het is in het JS landschap soms best ingewikkeld en bijna onmogelijk om alles te controlleren.

Hier een heel leuke post met vrijwel alleen maar potentiele waarheden. Ik ben overigens een developer die met name met front-end ontwikkeling bezig is en het is een interessante post.

https://hackernoon.com/im...e-here-s-how-9a8cb347c5b5

Qlusivenl

@Dreamvoid • 4 mei 2018 22:51

Kop op de spijker. JS is leuk, maar dit is een flashback naar flash. De toepassingen zijn “eindeloos”, maar we moeten onszelf ook indekken en inzicht geven in de gevaren en mogelijkheden.

sxbrentxs @Dreamvoid • 5 mei 2018 01:43

Dit dus. Het mag, zoals @JorzoR zegt, dan wel aan de marketing afdeling liggen, maar dat betekent nog niet dat het gevaar verdwenen is. Hetzelfde gold namelijk voor Flash: Zolang je er goed(aardig) mee omgaat is er niks aan de hand. Maar zo werkt deze wereld niet. Kijk naar het hele Facebook schandaal. Prachtig voorbeeld. Google doet namelijk precies hetzelfde, maar op een verantwoorde manier en in een andere categorie. Maakt het constante toezicht houden op gebruikers dan minder erg? Nee, naar mijn mening niet. Hier dus precies hetzelfde.

Het is natuurlijk prima om p.w.a.'s te hebben zolang ze goed gedaan worden, maar ik heb liever dat het allemaal vanuit de gebruiker komt, en niet de browser. Ik heb het antwoord niet, maar JavaScript is niet de manier. Een wel bekende deface of hijack zou dan nog steeds voor de nodige problemen zorgen.

gamezfreak @Dreamvoid • 5 mei 2018 11:19

Vergeet niet dat er ook een hoop sites zijn, waarop een JS Mining script draait. Leuk voor diegene die de code heeft gemaakt (of gekopieerd), maar minder leuk voor de eindgebruiker.
Javascript is opzich wel een handige code, je kan de website wat interactiever maken.

Ik snap wat je bedoeld, de Flash gebeuren was goed bedacht, maar slecht uitgevoerd. We hebben nu ruime kennis van security en kunnen ook bepaalde trends voorspellen. Maar security en gebruiksvriendelijkheid gaan niet altijd goed samen... Mensen willen dat alles heel makkelijk te bedienen is, maar houden geen rekening dat hackers alles in staat zijn, vooral als de security erachter zwak is.

TFA is voor sommige mensen al irritant, omdat ze de code moeten overtypen...

OT:
Vind het echt knap dat iemand alleen met HTML en CSS zo'n portret kan maken. Er heeft wel heel veel tijd (en irritaties

) ingezeten om dit te maken. Ik hoop dat meer mensen dit soort dingen gaan maken! Wie weet wordt er straks een galerij geopend met dit soort kunstwerken

Bruin Poeper @gamezfreak • 5 mei 2018 13:36

TFA is voor sommige mensen al irritant, omdat ze de code moeten overtypen...

Niet daarom, maar dat mijn telefoon geclaimd wordt.
Wat daar in staat (=prive) koppel ik niet graag aan internetactiviteiten.
Geef je ze een telefoonnummer dan grijpen ze de hele hand.

Verwijderd @Dreamvoid • 5 mei 2018 19:52

ik zou graag een browser zien die alle opmaak stript en omzet naar je eigen voorkeuren, soort RSS deluxe, en optie voor granulair JS, waarbij je bepaalde functies kunt uitschakelen of in een sandbox kunt laten wroeten met bijvoorbeeld een dummy locatie, dummy IP adres en dummy browser/OS.

raro007 @IvoPlas • 4 mei 2018 21:02

Dat zal apple nimmer nooit toe laten.
Apple kan die lock in niet loslaten ehm zogenaamde veiligheid..

Dasprive @raro007 • 4 mei 2018 21:23

Ja verschrikkelijk, de grootste worden door gewoon geld te vragen in plaats van de data van je klanten te grabbel gooien.

En welke lock-in is dat dan eigenlijk? Ik stapte over van Windows/Android naar MacOS/ iOS en dat was nou niet bepaald appeltje-eitje, maar verre van onmogelijk. Ik zou niet weten waarom, maar omgekeerd zal dezelfde problemen zijn, niet meer of minder.

eternia16 @raro007 • 4 mei 2018 21:39

Ja, vreemde JS code draaien die hardware kan aansturen klinkt nou niet echt veilig. Het is maar goed dat Apple dit tegenhoudt.

[Reactie gewijzigd door eternia16 op 24 juli 2024 14:35]

R4gnax @eternia16 • 5 mei 2018 14:20

Ja, vreemde JS code draaien die hardware kan aansturen klinkt nou niet echt veilig.

Alle nieuwere browser APIs waarmee JS developers de hardware meer direct aan kunnen spreken vereisen allemaal expliciet toestemming van de gebruiker en allemaal zijn ze enkel te gebruiken over een beveiligde verbinding.

Even inlezen op de materie voordat je paranoide gaat doen, aub.

eternia16 @R4gnax • 5 mei 2018 16:10

[Reactie gewijzigd door eternia16 op 24 juli 2024 14:35]

latka @R4gnax • 5 mei 2018 18:28

Veilig verbinding zegt niets: een domain validated cert heb je in 10 seconden aangemaakt. De browser vind het dan goed, maar het is helemaal niet veiliger dan het was: er is nog steeds unsigned untraceable JS code in mijn browser waar ik niets tegen kan doen behalve ronduit blokkeren. Ik lees me regelmatig in maar vraag me af wat jij expliciete toestemming vind. Voor WebGL bevoorbeeld niet en dat zit vrij dicht op de hardware (zo dicht dat Mozilla in eerste instantie er niet zo voor was). En dan recent: Meltdown/Spectre: je hoefde alleen maar een timertje te draaien en geen permissie (of https) nodig om het geheugen te scannen. JS fanboys downplayen het, maar het is gewoon stierekak in JS land.

graey @latka • 5 mei 2018 21:26

Stierekak in de CPU ook, Meltdown/Spectre zijn geen javascript-kwetsbaarheiden pur sang...

latka @graey • 6 mei 2018 13:19

Correct, maar als ik JS aan heb in de browser dan is deze lokale exploit ineens een remote network exploit geworden. JS (en dan voornamelijk het niet kunnen verifieren van de JS code) versterkt dit soort zaken.

R4gnax @latka • 7 mei 2018 08:03

(en dan voornamelijk het niet kunnen verifieren van de JS code)

Browsers hebben de tooling al aan boord:

https://developer.mozilla...ity/Subresource_Integrity
https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

En verder kun je de schuld geven aan website-ontwikkelaars die dit niet correct toepassen; niet aan browsers.

[Reactie gewijzigd door R4gnax op 24 juli 2024 14:35]

eternia16 @R4gnax • 6 mei 2018 20:32

https://www.reddit.com/r/...icious_module_getcookies/

Het was een kwestie van tijd voordat ik mijn gelijk zou krijgen. JS veilig noemen is naïef, ook met de permissies. Want wellicht geef je toestemming aan een site om hardware aantesturen. Maarja, wie weet welke libs die site allemaal draait.

[Reactie gewijzigd door eternia16 op 24 juli 2024 14:35]

R4gnax @eternia16 • 7 mei 2018 07:46

https://www.reddit.com/r/...icious_module_getcookies/

Het was een kwestie van tijd voordat ik mijn gelijk zou krijgen. JS veilig noemen is naïef, ook met de permissies. Want wellicht geef je toestemming aan een site om hardware aantesturen. Maarja, wie weet welke libs die site allemaal draait.

Welk 'gelijk'? Wat je hier aanhaalt was een vulnerability in een package bestemd voor Node.js, wat een server-side JS oplossing is. Node.js is lang niet zo afgeschermd als een browser-omgeving. Bewust; het is bedoeld om server-side applicaties te draaien en vereist dus ook zaken zoals file-system access, etc. zonder dat een gebruiker interactief geprompt kan worden.

Heeft nul-komma-nul met je browser te maken.

Enige wat dit voorval bewijst, is dat package manager dependencies niet veilig zijn als je er niet op kunt vertrouwen dat publish tokens van auteurs veilig blijven.
Duh?

[Reactie gewijzigd door R4gnax op 24 juli 2024 14:35]

eternia16 @R4gnax • 7 mei 2018 08:20

NPM wordt voor meerdere onderdelen gebruikt en niet alleen Node.JS.
Je kunt ook gewoon lezen in de comments van de Reddit post dat de NPM pakket systeem waar veel JS frameworks frontend ook gebruik van maken kwetsbaar zijn door hoe de library systeem NPM werkt. 1 lib is weer afhankelijk van meerdere libs. Een kwetsbaarheid of malicious code in een van die child libs en je hele frontend is meteen gekraakt en beschikbaar voor een malicious hacker.

Als dit nul-komma-nul met je browser dan wil je vriendelijk verzoeken om je nogmaals te verdiepen in JavaScript en wellicht ook die roze zonnebril even af te nemen. JavaScript is onveilig, vooral hoe de JS community zichzelf ontwikkeld momenteel.

https://hackernoon.com/im...e-here-s-how-9a8cb347c5b5

[Reactie gewijzigd door eternia16 op 24 juli 2024 14:35]

R4gnax @eternia16 • 7 mei 2018 08:26

NPM wordt voor meerdere onderdelen gebruikt en niet alleen Node.JS.
Je kunt ook gewoon lezen in de comments van de Reddit post dat de NPM pakket systeem waar veel JS frameworks frontend ook gebruik van maken kwetsbaar zijn door hoe de library systeem NPM werkt. 1 lib is weer afhankelijk van meerdere libs. Een kwetsbaarheid of malicious code in een van die child libs en je hele frontend is meteen gekraakt en beschikbaar voor een malicious hacker.

Als dit nul-komma-nul met je browser dan wil je vriendelijk verzoeken om je nogmaals te verdiepen in JavaScript en wellicht ook die roze zonnebril even af te nemen. JavaScript is onveilig, vooral hoe de JS community zichzelf ontwikkeld momenteel.

https://hackernoon.com/im...e-here-s-how-9a8cb347c5b5

Hetzelfde argument kan ik ook opvoeren voor Python package management oplossingen. En Ruby. En PHP. En C#. Etc. Dat heeft niets meer met JavaScript meer te maken, maar is een algemeen probleem met code van package managers af halen.

Je moet er vanuit kunnen gaan dat ontwikkelaars die daar publiceren, te vertrouwen zijn. En je moet er vanuit gaan dat iemand anders niet code onder een vertrouwde naam kan publiceren doordat bijv. logingegevens gestolen worden.

En verder heb je zelf een verantwoordelijkheid als ontwikkelaar om zaken te controleren.

Hou alsjeblieft op te vissen naar een argument.

[Reactie gewijzigd door R4gnax op 24 juli 2024 14:35]

eternia16 @R4gnax • 7 mei 2018 08:37

Ik vis niet naar een argument, want er zit wel degelijk een verschil tussen Python C# en etc package management. Als ik met mijn browser een website bezoek moet ik er maar van uitgaan dat de developer netjes alles onderzocht heeft of zijn libs wel veilig zijn. Aangezien er gewoon vreemde code binnen wordt geschoten en draait op mijn browser. Als ik een desktop applicatie ga draaien moet ik dat doel bewust eerst downloaden en vervolgens aanklikken voordat de applicatie zijn code mag uitvoeren op mijn systeem.

Dat is inherent heel anders dan maar binnentrekken en draaien.

Stop met het geloven dat JavaScript een top taal is, dat is het niet. JavaScript is onveilig.

[Reactie gewijzigd door eternia16 op 24 juli 2024 14:35]

R4gnax @eternia16 • 8 mei 2018 08:38

Ik vis niet naar een argument, want er zit wel degelijk een verschil tussen Python C# en etc package management. Als ik met mijn browser een website bezoek (...) Als ik een desktop applicatie ga draaien (...)

Dat is inherent heel anders dan maar binnentrekken en draaien.

Ik kan een NuGet C# package maken met een DLL daarin die voor ASP.NET applicaties automatisch een HTTP module registreert welke alle binnenkomende POSTs logt en doorstuurt naar een extern verzamelpunt.

Of een HTTP module die malware injecteert voor remote code execution. Dat hoeft niet JavaScript te zijn. Hoe vaak zijn er wel niet vulnerabilities in de font rendering stack van Windows gevonden? Een speciaal geprepareerd webfont kan met zo'n vulnerability achter de hand al voldoende zijn.

Zelfde situatie dus. Stop met geloven dat JavaScript op dat vlak meer onveilig zou zijn dan andere talen, want dat is dus niet zo.

(Sterker nog: je kunt beargumenteren dat aangezien C# ge-precompiled wordt naar bytecode en de source niet meer te inspecteren valt, is het installeren van een NuGet C# package zelfs inherent nog meer onveilig dan een NPM JS package.)

Aangezien er gewoon vreemde code binnen wordt geschoten en draait op mijn browser.

Die 'vreemde code' kan niets buiten zijn sandbox verrichten wat niet via strak dichtgetimmerde APIs aangeboden wordt. Enkel als er via een exploit uit de sandbox gebroken kan worden, heb je een probleem.

En dat is in het verleden al meerdere malen gebeurd met: HTML5 video (o.a. stagefright); webfonts (Windows font rendering vulnerabilities); images (Windows GDI image rendering vulnerabilities); CSS (parser bugs die leiden tot exploitable crashes) en zelfs HTML zelf (ook parser bugs).

Toch zie ik jou niet heel panisch de voedingsstekker van je modem er uit trekken en het internet afzweren. Vreemd heh?

Als ik een desktop applicatie ga draaien moet ik dat doel bewust eerst downloaden en vervolgens aanklikken voordat de applicatie zijn code mag uitvoeren op mijn systeem.

En wil een website JavaScript uitvoeren, moet je eerst de URL bezoeken en de website pagina en resources door de browser laten downloaden en uitvoeren.

Je stapt even heel snel over het feit heen dat ook die applicatie die je zelf kiest om te downloaden; installeren; en lanceren ook op zichzelf staand extra zooi van internet kan plukken om uit te voeren. En daar heb jij als gebruiker een stuk minder (zeg maar gerust; geen) controle over dan met een browser, waar er nog allerlei beschermingsmaatregelen ingebouwd zijn of toe te voegen zijn middels extensies.

En zeg niet dat dat niet gebeurt met desktop applicaties uit gecureerde bronnen zoals app stores, want ook daar is het geregeld raak. Er zijn legio gevallen geweest van malafide apps die soms dagenlang, maar ook vaak genoeg wekenlang (of zelfs maanden) in de iOS of Android app stores bleven staan en die allerlei meuk van coin miners t/m keyloggers bevatten of binnenhaalden. Veelal via backdoors in SDKs van louche advertisement netwerken. (Eigenlijk het package probleem dat bij o.a. NPM ook speelt.)

En wat dacht je van bijv. het Sourceforge voorval? Waar ze op eigen houtje adware aan de installers van 'achtergelaten' open-source software toevoegden?

[Reactie gewijzigd door R4gnax op 24 juli 2024 14:35]

Anders @raro007 • 4 mei 2018 21:13

En niet te vergeten de commissie op alle aankopen via de appstore en in-app purchasing.

indigo79 @Anders • 5 mei 2018 08:55

Want als je iets in een fysieke winkel of een webshop koopt, is er geen commissie voor de eigenaar van die winkel of webshop?

RoelRoel @indigo79 • 5 mei 2018 09:12

Rare vergelijking want in dat verhaal zou er maar 1 winkel toegestaan zijn in het land die alles verkoopt en bepaald wat er wel en niet verkocht mag worden.

indigo79 @RoelRoel • 5 mei 2018 11:52

Dan gaat het over het monopolie en niet over de commissies. Daarmee ben ik het volledig eens. Dat is trouwens ook de reden dat ik ondanks alle gedoe met updates die zelden op tijd of zo lang als beloofd beschikbaar zijn toch nog voor Android kies in plaats van voor iOS. Zo kan ik tenminste nog via alternatieve repositories (F-Droid) of direct uit packages installeren (en ja, dat doe ik, ik gebruik zoveel mogelijk open source spul via F-Droid en ik installeer af en toe een package van een eigen app(je)).

Met mijn reactie bedoelde ik ook dat het monopolie en de beslissingsmacht wat jij op je toestel mag doen en zien het probleem is en niet de commissies. Ik had het wat uitgebreider moeten formuleren...

[Reactie gewijzigd door indigo79 op 24 juli 2024 14:35]

JeroenB89 @raro007 • 5 mei 2018 09:27

Hoe bedoel je? Apple heeft onlangs support voor ServiceWorker toegevoegd aan Safari, dus ook op iOS.

https://jakearchibald.github.io/isserviceworkerready/

Dat geeft niet gelijk toegang tot alle onderdelen voor PWAs, maar wel de belangrijkste.

jaquesparblue @IvoPlas • 5 mei 2018 08:57

Dat JS de wereld gaat overnemen roepen ze ze al 10-15 jaar, toen Web2.0 zijn hoogtij vierde en AJAX hot and upcoming was.

R4gnax @jaquesparblue • 5 mei 2018 14:22

Dat JS de wereld gaat overnemen roepen ze ze al 10-15 jaar, toen Web2.0 zijn hoogtij vierde en AJAX hot and upcoming was.

Heb je al eens gekeken wat er tegenwoordig feitelijk allemaal al op JS draait?
Ze hebben de wereld feitelijk al overgenomen. Het zit tegenwoordig overal.

D0phoofd @IvoPlas • 4 mei 2018 20:37

Nou ja, 'Native'... Er is gewoon een laag van abstractie toegevoegd. Namelijk de web browser.
Eerst codeert men in machine taal, toen kwam er high-level language om die machine taal uit te spitten en nu gaan de web-browsers de high-level language aanspreken om de machine iets te laten doen (en natuurlijk de rest van het OSI model wat er bij komt kijken).

[Reactie gewijzigd door D0phoofd op 24 juli 2024 14:35]

Ed Vertijsment @IvoPlas • 4 mei 2018 23:56

Een beetje een naieve reactie als je het mij vraagt.

JavaScript gaat komende jaren het internet veranderen.

Dat is natuurlijk een beetje een open deur, dit is 10 jaar geleden al ingezet en nu allang geen toekomstmuziek meer. Vooral het laatste "gaat komende jaren het internet veranderen" heb ik al echt véél te vaak voor van alles gehoord.

We zijn op weg naar progressive web apps die de potentie hebben apps overbodig te maken. Zo krijgen progressive web apps de mogelijkheid om hardware aan te sturen zoals bijv. bluetooth en worden ze net zo snel als een native app.

Een progressive web app betekent niet dat je native apps vervangt, daar zijn namelijk al n andere tools voor. Het is meer als een application wide design pattern om hoe om te gaan met internet. Daarnaast is het niets meer dan een leuke hipsterterm dat Google gebruikt om hun implementatie van Service Workers in Chrome te pushen. Feit is dat je prima een

- Offline website
- Die online gaat bij een verbinding
- Met lokale cache

kan bouwen zonder Service Workers (weliswaar op deprecated specs, maar lang leve abstractie). Het is gewoon voor 90% oude wijn in nieuwe zakken.

ONTOPIC:

Wat betreft het "kunstwerk", knap gemaakt, dat wel. Maar ik begrijp gewoon niet (naast zoveel andere CSS "kunstwerken") waarom er uberhaubt voor HTML/CSS gekozen wordt. Als het is om aan te tonen dat het mogelijk is is dat een beetje achterhaald (als je de codepen nieuwsbrief volgt dan wist je dat al) enige andere artistieke waarde van HTML/CSS ontgaat mij. Voor dit soort dingen is SVG bedacht.

indigo79 @Ed Vertijsment • 5 mei 2018 11:54

Wat betreft het "kunstwerk", knap gemaakt, dat wel. Maar ik begrijp gewoon niet (naast zoveel andere CSS "kunstwerken") waarom er uberhaubt voor HTML/CSS gekozen wordt. Als het is om aan te tonen dat het mogelijk is is dat een beetje achterhaald (als je de codepen nieuwsbrief volgt dan wist je dat al) enige andere artistieke waarde van HTML/CSS ontgaat mij. Voor dit soort dingen is SVG bedacht.

Omdat het kan? Meer moet dat toch niet zijn?

Toettoetdaan @IvoPlas • 5 mei 2018 01:26

Vroeger noemde dat een rich internet application, dat nu een nieuwe naam ongeveer hetzelfde betekent betekent niet dat het de toekomst veranderd.

Er zijn al behoorlijk wat app's die onderwater gewoon een PWA zijn en tegelijkertijd zijn er bizar weinig websites die in die richting bewegen. Ik zie dat niet snel veranderen. Ondanks de nieuwe aandacht is het niets nieuws en zijn er veel te weinig ontwikkelaars beschikbaar om extra uren in dit idee te steken.

WillySis @IvoPlas • 5 mei 2018 14:12

Hardware vanuit een browser aansturen lijkt mij niet echt gewenst. Dat brengt gelijk een heel scala aan beveiligingsproblemen met zich mee. Bovendien is er zoveel verschillende hardware dat het moeilijk wordt om de werking op elk toestel te garanderen.

Sandor_Clegane @Dreamvoid • 4 mei 2018 19:56

Eens, alleen dit is pure opmaak. Wil je een beetje collecties bijhouden e.d. en wat AJAX doen heb je het al snel nodig.

Waar ik wel voor ben: minder frameworks. Gewoon JS is prima en ook best een leuke taal.

Eerst een paar MB aan frameworks binnenhalen voor elk washee washee is echt een drama.

[Reactie gewijzigd door Sandor_Clegane op 24 juli 2024 14:35]

MiesvanderLippe @Sandor_Clegane • 4 mei 2018 20:31

Die paar MB is ook helemaal overbodig met een beetje een moderne transpiler. Zeker als je goede tests opstelt (wat sowieso aan te raden is met hoe groot web-apps zijn tegenwoordig) kun je alle ongebruikte code automatisch weggooien.

Er zijn altijd mensen die JQuery en twee libraries inladen voor het openen van een link in een nieuw tabje maar dat kun je nooit voorkomen.

Ik zie liever goed gestructureerde applicaties gebaseerd op goed geteste frameworks met meer manjaren ontwikkeling dan ooit gespendeerd zullen worden binnen het bedrijf zelf.

Sandor_Clegane @MiesvanderLippe • 4 mei 2018 20:34

Tja, maar dat is best een flinke klim qua kennis, voordat mensen daar een beetje in thuis zijn ga je nog heel wat Frameworks downloaden.

Het is ook wel een drama moet ik zeggen om dat allemaal bij te houden.

Extranion @Sandor_Clegane • 6 mei 2018 21:49

Valt wel mee hoor door middel van tree shaking doen de build tools dit al voor je. Je hoeft zelf alleen maar te importeren wat je echt nodig heb. Al het andere van de libraries wat je niet gebruikt word gewoon weggegooid en zal nooit in de productie code opgenomen worden. Rollup en webpack doen dit beide en de nieuwe build tool parcel bundler is tree shaking in ontwikkeling.

Daarnaast vind ik het altijd erg prettig om een framework/library te hebben. Enkele voordelen die je krijgt:
- vaste structuur/guidelines
- binding van data.
- routing
- makkelijker overdraagbaar aan andere developer
- niet opnieuw het wiel uit te vinden voor bepaalde logica

[Reactie gewijzigd door Extranion op 24 juli 2024 14:35]

Sandor_Clegane @Extranion • 7 mei 2018 09:19

Ik vind het wel mooi dat je schrijft dat het wel mee valt en in dezelfde reactie het alweer hebt over nieuwe tools die het nog weer beter gaan maken.

Extranion @Sandor_Clegane • 8 mei 2018 20:30

Tja het is allemaal in ontwikkeling de build tools. Maar de tree shaking zal bij alle 3 de build tools vrijwel hetzelfde werken. Zijn alleen andere smaakjes waarbij parcel bundler de nieuwste is en stuk sneller is.

Maar punt dat drama is om het allemaal bij te houden dat klopt wel xD gaat erg snel allemaal.
Vind dat eigenlijk ook wel leuk aan het vak dat het zo dynamisch is.

SuperDre @Sandor_Clegane • 4 mei 2018 21:48

tja, dat is dus het probleem van tegenwoordig, iedereen wil hun eigen framework gebruiken, want degene die zij gebruiken is op dat moment de beste..
En je gebruikt een framework natuurlijk niet voor niets, je gaat niet het wiel telkens weer opnieuw uitvinden (alhoewel gezien het aantal frameworks dat er is, dat dus wel veel gebeurd).

Old Swartly @Dreamvoid • 4 mei 2018 20:02

ik zie dit niet direct als een stellingname voor/tegen JS in browsers, mocht je er toch zo naar willen kijken is het eerder een geluid tegen de vele implementaties van 'standaarden' want het ziet er niet altijd even mooi uit. Zie bijv de link met door minder bekende browsers gerenderde versies

Volgens mij komt dit neer op glitches en edge cases van de standaarden in Chrome misbruiken tot het er mooi uitziet. Al zou je dat de definitie van webdesign in het algemeen kunnen noemen (grapje, webdesigners)

ard1998 @Dreamvoid • 4 mei 2018 20:20

het is een optie om de invoer door middel van een form doorsturen naar de zelfde pagina waar het verwerkt word en vervolgens de nieuwe pagina weergeven word. je kan een website ontwerpen rondom gebruik van javascript (zoals hier met de reactieknop) of een enkele reactiemogelijkheid bivenaan de thread waarin je kan reageren zonder javascript. het andere punt is dat met javascript de server cpu onlast kan worden door bepaals werk op de client uit te voeren. maar dingen zoals tekst opmaak hulpmiddelen zouden noet mogelijk zijn zonder javascript. ook zou het iedere keer verversen van de pagina veel bandbreedte kosten. en die is momenteel al schaars.

ja het is mogelijk, maar er zijn heel veel redenen situaties waarin het rekeninghoudend met de huidige staat van het internet en het verdienmodel hierom niet wenselijk is voor bedrijven en/of functionaliteit om zonder javascript te werken.

Verwijderd @Dreamvoid • 5 mei 2018 20:40

Enkel heb je wel degelijk Javascript nodig voor een groot aantal zaken. Lekker makkelijk roepen dat Javascript slecht is en het weg moet, een alternatief realiseren, niet. Met onderbouwde argumenten komen, ook al niet. Zonder Javascript bijvoorbeeld geen UI voor deze tekst editor. Zonder Javascript geen werkbare filter in Pricewatch. Zonder Javascript geen werkbare comment-sectie hier, zonder tussen elke moderatie/reply/etc. een page reload te doen en weer naar beneden te scrollen.

Zo zijn er genoeg websites die er op leunen voor basisfunctionaliteit. Elke webshop, elk forum, elke webmail client...

Dreamvoid @Verwijderd • 5 mei 2018 23:47

Ik zit op diverse forums met nog gewoon een reload na een reactie, niks mis mee. Filteren in pricewatch kan ook gewoon met een reload - functioneel is het maar zelden echt nodig als je goed ontwerpt. Ja, voor popup reclamebanners en webapps, maar daar gebruik je imo beter native apps voor.

[Reactie gewijzigd door Dreamvoid op 24 juli 2024 14:35]

Verwijderd @Dreamvoid • 6 mei 2018 00:17

Ajax calls hebben nog vele andere voordelen, zoals minder CPU kracht nodig serverside, snelheid en lage bandbreedte etc

[Reactie gewijzigd door Verwijderd op 24 juli 2024 14:35]

Dreamvoid @Verwijderd • 6 mei 2018 10:59

Klopt, en dat is juist de reden dat het nog steeds bestaat - als website kan je de cpu cycles naar de client pushen. Maar dat maakt het juist ongewenst - uit kosten besparing de gebruiker met security risico en hoge cpu load (accuduur!) opzadelen is niet echt een feest.

Verwijderd @Dreamvoid • 6 mei 2018 11:48

Nee, dat is niet waar ik op doel

via Ajax kun je gemakkelijk alleen je data verversen en sla je de rest van je applicatie over.

Extranion @Dreamvoid • 6 mei 2018 22:02

Het gaat ook niet alleen over load. Uit gebruiksperspectief wil je juist ajax calls doen.

Het is voor een gebruiker niet zo vervelend als dat die bij elke interactie even een wit scherm te zien krijgt en dat dan de hele pagina weer moet laden. Het moet snappy aanvoelen. Je klikt op een knop en je krijgt gelijk reactie je ziet dat de pagina direct veranderd en je kan gelijk door met wat je aan het doen bent. Doordat je het op die manier programmeert krijg je een website/ webapplicatie die snel aanvoelt en wat een stuk fijner is om te gebruiken dan dat je bij elke knop weer de website opnieuw moet inladen. Ook al maak je gebruik van cache voor je assets en dergelijke dan is dat nog trager dan dat je alleen de data ophaalt en ververst die je nodig heb.

Dreamvoid @Extranion • 6 mei 2018 23:48

Dat is de theorie inderdaad, maar een reload is met de huidige snelheden ook heel snel gedaan, zeker als je een pagina met weinig grafische elementen maakt. Ik ken menig JS/Ajax-based forum dat trager aanvoelt dan JS-vrije forums met reloads. Bovendien, wat is een halve seconde reload als je de veiligheid flink verbetert? Plus het enorm mindere RAM verbruik, de browser hoeft geen JS runtime voor elke tab/pagina/domein in de lucht te houden.

Nee, wat mij betreft mag er voor een 'web 3.0' (of 4.0?) best een striktere scheiding komen: websites draaien code enkel server-side en serveren HTML5/CSS zonder JavaScript aan de clients, en als je client-side code wilt draaien (of toegang wilt tot de webcam of local storage), maak dan developer-signed apps met JavaScript (of elke andere dev taal), zodat malware in elk geval nog ergens in de keten geaudit kan worden.

Extranion @Dreamvoid • 8 mei 2018 20:25

Over je eerste punt dat sommige js/ajax based forums trager aanvoeren dan kan kloppen maar dit is niet echt een representatief voorbeeld denk ik dan zo. Ajax hoeft minder data over de lijn dus is sneller. Computers zelf zijn snel genoeg om javascript berekeningen te doen.

Het tweede punt wat je aanhaalt is het enorm minder ram verbruik. Javascript zal inderdaad meer RAM vreten dan een website die puur server side gerenderd word. Maar als dit het gebruiksgemak verbeterd is een beetje meer RAM denk ik niet zo'n groot probleem voor de meeste hedendaagse computers. Als je gaat praten over hele 3D omgevingen en geluid, sprites en dergelijke dan is het een ander verhaal dat kan erg zwaar zijn op je systeem.

Qua veiligheid denk ik eerlijk gezegd dat een app waarbij je niet heel goed kan zien wat het doet misschien nog wel onveiliger is dan een webapp die je met wat technische kennis gewoon kan bekijken. Je kan uitzoeken wat de app doet en je moet bij vrijwel alle functies die iets met privacy te maken hebben permissie geven en op https draaien. Dat er eventueel malware aan de client kan in kan zitten dat kan natuurlijk maar je geeft daar uiteindelijk zelf permissie voor. Dat ze niet geaudit worden dat klopt, maar ik denk dat je met een browser tegenwoordig nog steeds beter beveiligd bent dan dat je een native app installeert. De lekken die in native OS zitten zijn vaak groter dan die je in een browser kan uithalen.

Verwijderd @Dreamvoid • 6 mei 2018 18:47

Kan, maar goed geimplementeerde JS verlaagt de laadtijden en load op de server gigantisch. Als er bij elke wijziging in een filter een reload plaatsvindt.... succes met even snel 3 filters aanpassen en tussentijds resultaten bekijken. Helemaal niet praktisch. Ik weet dat sommigen genoeg nemen met het leven in web 1.0 , en dat de keerzijde is dat sites JS ook misbruiken, maar het heeft wel degelijk nut. Ik denk dat een site als Tweakers, met tienduizenden bezoekers per dag, vrij dankbaar is dat niet iedereen elke pagina aan het reloaden is bij elke filterwijziging of post submit.

Dreamvoid @Verwijderd • 6 mei 2018 23:56

Ik denk niet dat er iemand terug wil naar web 1.0, met HTML5 kan je veel meer dan vroeger natuurlijk. Je zou het eerder web 3.0 kunnen noemen, een duidelijkere scheiding tussen JS code die serverside draait, en client side die enkel rendering doet.

Er wordt IMO teveel vanuit de kostenbesparing voor de serverside gedacht, zonder de cpu/ram belasting en security van de gebruiker mee te nemen. Begrijpelijk vanuit de website die enkel vanuit zijn eigen belang kijkt, maar niet wenselijk natuurlijk. Met de groei van bandbreedte anno 2018 houdt het argument dat reloads 'duur' zijn ook steeds minder stand - een minuutje Tweakers video van 1 gebruiker vreet meer bandbreedte dan 10.000 tweakers die een pagina van 2-3 kb verversen na een post.

Verwijderd @Dreamvoid • 7 mei 2018 00:05

Helaas is deze pagina alleen al 350kb (sans trackers/ads). Dus dat is nog wal wat. Het meeste daarvan zijn graphics/css. Statische content zoals video's kun je weer met servertechnieken als Varnish makkelijk afvangen. Dat kost weinig berekening, meer storage/bandwidth.

En met de steeds toenemende kracht aan de gebruikerskant, is het prima dat er berekeningen gebeuren aan onze kant. Wellicht kunnen we eerder kijken naar browsermakers, die ons geen controle geven over de resources die JS mag aanspreken, zoals we dat eerder ook deden bij iOS/Android, die ons te weinig controle gaven over app-rechten. Het zou prima mogelijk moeten zijn om te kunnen zeggen dat JS de browser storage niet mag aanspreken, maar x% processor mag gebruiken voor berekeningen, geen data naar externe partijen mag versturen (of uit die bron geladen mogen worden) animaties uit kunnen, etc, etc. Dit zijn allemaal functies die vastgelegd zijn en gedeeltelijk al door browser plugins kunnen.

Dreamvoid @Verwijderd • 7 mei 2018 09:23

De graphics zijn client-side al cached dus die hoef je geen tweede keer te sturen, net als de CSS in principe.

tinustate 4 mei 2018 20:11

Ik maakte vroeger plaatjes met html tabellen waar elke cell in de tabel een pixel is.
Dat is pas puur!

Sandor_Clegane @tinustate • 4 mei 2018 20:22

En tijdrovend

MiesvanderLippe @Sandor_Clegane • 4 mei 2018 20:27

Een paar millisecondes om precies te zijn 😉

Voorbeeldjes tijd:
https://pgl.yoyo.org/img2html/

[Reactie gewijzigd door MiesvanderLippe op 24 juli 2024 14:35]

laptopleon @tinustate • 5 mei 2018 01:18

Want.. het voelt beter als het 50x zo groot is als een gifje? Kijken of je browser al traag wordt bij een 'plaatje' van 1024 x 1024 td's?

Extranion @tinustate • 6 mei 2018 22:03

zo word je wel goed in mail templates maken xD

[Reactie gewijzigd door Extranion op 24 juli 2024 14:35]

swel 4 mei 2018 20:34

Geweldig!
..De pagina heeft 1337 lijnen code..

GhostShinigami @swel • 5 mei 2018 02:16

Haha, die viel mij ook wel op! Wat een werk zeg, erg netjes gedaan! en veelsteveel tijd...

Qalo 4 mei 2018 20:49

Een leuke variant van de Acid3 test....

_Zedd_ @Qalo • 4 mei 2018 22:01

Yep, leuke verschillen tussen de browsers. O.a. de wenkbrauw in Edge is niet helemaal goed.

Niets nieuws onder de zon.

g4wx3 4 mei 2018 21:03

in chrome kan ik het niet printen?

MrDummy @g4wx3 • 4 mei 2018 21:52

Printscreen of plugin gebruiken die screenshot maakt van pagina, en daarmee printen.
Dat is makkelijkste.

Core2016 @MrDummy • 6 mei 2018 01:52

F12 -> CTRL+SHIFT+P -> Type "print" en klik op Capure full size screenshot. Als iemand hier een snelere weg voor heeft. Ik hoor hem graag.

Tranze 4 mei 2018 20:07

Je moet er maar zin in hebben! Ik vind het knap gemaakt, zal vooral veel tijd kosten.

ongekend41 4 mei 2018 22:39

Met een beetje zoeken kan je ook haar linkerarm vinden

Ayporos 4 mei 2018 23:55

Op firefox ziet het er een stuk beter uit dan op chrome mijns inziens.. of iig op mijn browsers.
chrome heeft scherpere lijnen (minder blurring) en het wit glanst heel erg.
Hoewel je detail verliest zien de wimpers er op firefox echt veel beter uit.

[Reactie gewijzigd door Ayporos op 24 juli 2024 14:35]

Brawler1986 5 mei 2018 00:34

Echte kunst! Als je inzoomt (CTRL + +) dan zie je zelfs blauwe lijnen lopen over haar borst die heel subtiel de aders weergeven. Dit zal wel aardig wat werk gekost hebben.

Arcticwolfx 5 mei 2018 10:28

in Chrome en Edge ziet ze er hetzelfde uit, maar in Internet Explorer mist er net een beetje schaduw.

Op dit item kan niet meer gereageerd worden.

Kunstenares maakt gedetailleerd werk met alleen html en css

Lees meer

IT-banen

Reacties (92)

Sorteer op:

Weergave: