Tror mange vil skrive om webapplikasjonene for å ta i bruk WebAssembly

[Harald Brombach (digi.no)]

Tror mange vil skrive om webapplikasjonene for å ta i bruk WebAssembly

[zeebra]

Shit. Et internett av binærfiler som kjører maskinkode?

 

Fyttegrisen.

[2J37JHPB]

Shit. Et internett av binærfiler som kjører maskinkode?

 

Fyttegrisen.

 

Hehehe, hysj! Ikke avslør galskapen, la ungdommen få en sjanse til å drite i buksa selv ...

[Rudde]

Hvordan vil dette fungere på tvers av arkitekturen? Som x86, og Arm, eller PowerPC?

[Tonje Tambur]

Så moralen er: Lag webapplikasjonen heller så lette som mulig, både m.h.t. HTML, grafikk, CSS og JavaScript!

[DF4QRNUD]

Hvordan vil dette fungere på tvers av arkitekturen? Som x86, og Arm, eller PowerPC?

 

WebAssembly representeres som kompakt og enkelt verifiserbar portabel bytekode, og oversettes til maskinkode etter nedlasting.

[0laf]

Så moralen er: Lag webapplikasjonen heller så lette som mulig, både m.h.t. HTML, grafikk, CSS og JavaScript!

 

Jepp !!!

[Rudde]

 

Hvordan vil dette fungere på tvers av arkitekturen? Som x86, og Arm, eller PowerPC?

WebAssembly representeres som kompakt og enkelt verifiserbar portabel bytekode, og oversettes til maskinkode etter nedlasting.

 

Er ikke helt sikker på om jeg henger helt med her. Så du kompilerer koden din til WebAssembly som ikke er maskin instruksjoner, denne lastes ned til browsere som støtter det og de tar binær WebAssembly og komplierer det til maskinkode on the fly?

[DF4QRNUD]

 

 

Hvordan vil dette fungere på tvers av arkitekturen? Som x86, og Arm, eller PowerPC?

WebAssembly representeres som kompakt og enkelt verifiserbar portabel bytekode, og oversettes til maskinkode etter nedlasting.

Er ikke helt sikker på om jeg henger helt med her. Så du kompilerer koden din til WebAssembly som ikke er maskin instruksjoner, denne lastes ned til browsere som støtter det og de tar binær WebAssembly og komplierer det til maskinkode on the fly?

Det er riktig. Det er ikke engang nødvendig å kompilere til maskinkode; Google implementerer også en interpreter (som de bruker for å starte kjøringen så snart koden er lastet ned uten å vente på et kompilatoren skal bli ferdig), og i prinsippet kan denne brukes til å eksekvere kode i miljøer hvor det ikke er mulig å generere maskinkode under kjøring, men det gjelder vel stort sett ikke webben.

 

Fordelene med wasm er bl.a. at koden er kompakt og derfor kan lastes ned raskt; at den er statisk typet og kan kompileres kun en gang (og ikke stadig rekompileres ettersom typeinformasjonen endrer seg, som i JS) og derfor har en forutsigbar ytelsesprofil og ingen merkbare pauser; og at den er maskin-nær og kan konkurrere på ytelse med C og C++, om den oversettes til maskinkode etter nedlasting.

 

Kompileringen til maskinkode kan ta litt tid, men her er det rom for ganske mange løsninger. For det første kan den kompilerte koden caches. For det andre kan kompileringen foregå mens bytekoden streames. For det tredje kan man velge en "two-tier" løsning som nevnt ovenfor, enten med en interpreter+kompilator, eller med to kompilatorer, en kjapp en som genererer grei kode og en optimerende som kan bruke lenger tid. Det er også mulig å tenke seg en mer JIT-aktig løsning hvor en funksjon kompileres første gangen den kalles, er litt usikker på om noen prøver på det akkurat nå.

[_dundun_]

Endelig kommer Java-applets tilbake!

Endret 22. mars 2017 av Audun_K

[Rudde]

 

Så moralen er: Lag webapplikasjonen heller så lette som mulig, både m.h.t. HTML, grafikk, CSS og JavaScript!

 

Jepp !!!

 

Nå er nok ikke dette rettet mot folk som skal presentere litt infromasjon på webben, men som sagt apputviklere og de som lager komplekse løsninger i nettleseren.

[GeirGrusom]

 

Shit. Et internett av binærfiler som kjører maskinkode?

 

Fyttegrisen.

Hehehe, hysj! Ikke avslør galskapen, la ungdommen få en sjanse til å drite i buksa selv ...

 

Det er ikke galskap i det hele tatt. Fremgangsmåten de bruker er godt dokumentert og testet. Nettleseren din kompilerer allerede til maskinkode, men på grunn av at JavaScript er et ganske dårlig språk for både som kompileringsmål, og kompilerigskilde, så er det nødvendig å ha et språk med lavere abstraksjonsnivå og strengere regler.

[Ompa Kaiiizer]

 

 

Så moralen er: Lag webapplikasjonen heller så lette som mulig, både m.h.t. HTML, grafikk, CSS og JavaScript!

 

Jepp !!!

Nå er nok ikke dette rettet mot folk som skal presentere litt infromasjon på webben, men som sagt apputviklere og de som lager komplekse løsninger i nettleseren.

Men hvor går skillet mellom "litt informasjon på weben" og "komplekse løsninger i nettleseren"? Det er ikke alltid helt åpenbart, og jeg tror mange kan "kommer i skade" for å kaste seg på dette på samme måte som de kastet seg på EJB og ESB (uten sammenlikning for øvrig) en gang i tiden.

[Rudde]

 

 

 

Så moralen er: Lag webapplikasjonen heller så lette som mulig, både m.h.t. HTML, grafikk, CSS og JavaScript!

 

Jepp !!!

 

Nå er nok ikke dette rettet mot folk som skal presentere litt infromasjon på webben, men som sagt apputviklere og de som lager komplekse løsninger i nettleseren.

 

Men hvor går skillet mellom "litt informasjon på weben" og "komplekse løsninger i nettleseren"? Det er ikke alltid helt åpenbart, og jeg tror mange kan "kommer i skade" for å kaste seg på dette på samme måte som de kastet seg på EJB og ESB (uten sammenlikning for øvrig) en gang i tiden.

 

De fleste komplekse webløsninger handler om interaksjon mellom bruker å side. Ja om du ikke trenger noe som helst fra bruker og bare skal vise han informasjon er det jo lett og droppe js helt. Men om du skal ha data fra bruker som siden skal gjøre logisk prosessering av før det den sendes til en server eller parses eller hva som gjøres med den vil det være svært fordelaktig og kunne kjøre native kode.

[0laf]

De fleste komplekse webløsninger handler om interaksjon mellom bruker å side. Ja om du ikke trenger noe som helst fra bruker og bare skal vise han informasjon er det jo lett og droppe js helt. 

 

Man klarte da dette helt fint uten javascript tidligere, og forsåvidt også enda, med vanlige skjemaer og GET/POST forespørsler uten ajax.

 

Interaktivt dilldall, animasjoner og den slags er det dog verre med uten JS, selv om CSS har kommet langt i å implementere vås stilark aldri var tenkt å brukes til.

Endret 22. mars 2017 av adeneo

[Rudde]

 

De fleste komplekse webløsninger handler om interaksjon mellom bruker å side. Ja om du ikke trenger noe som helst fra bruker og bare skal vise han informasjon er det jo lett og droppe js helt.

 

Man klarte da dette helt fint uten javascript tidligere, og forsåvidt også enda, med vanlige skjemaer og GET/POST forespørsler uten ajax.

 

Interaktivt dilldall, animasjoner og den slags er det dog verre med uten JS, selv om CSS har kommet langt i å implementere vås stilark aldri var tenkt å brukes til.

 

For det første kan du få ekstremt mye mer responsiv side ved å bruke SPA. Om som alle [burde] vite, brukes ikke javascript og web-teknologi kun til å levere informasjon lenger. Det brukes [som sagt] til å lage webløsninger som er litt mer enn en blogg. Det brukes til å lage mobilapplikasjoner, det brukes til å lage desktopapplikasjoner.

[0laf]

For det første kan du få ekstremt mye mer responsiv side ved å bruke SPA.

 

Å droppe nye sidelastninger gjør ikke nødvendigvis nettsiden din mer responsiv.

 

Om som alle [burde] vite, brukes ikke javascript og web-teknologi kun til å levere informasjon lenger. Det brukes [som sagt] til å lage webløsninger som er litt mer enn en blogg. Det brukes til å lage mobilapplikasjoner, det brukes til å lage desktopapplikasjoner.

At javascript brukes til webløsninger kommer ikke akkurat som noen overraskelse, men det brukes vel fint lite til å lage mobil- og desktopapplikasjoner?

 

Med mindre du snakker om såkalte "webapps" eller PhoneGap, Sencha, Ionic, NW eller lignende, som oversetter "webspråk" til andre språk osv. De fleste velger nok Swift, Java eller hva enn platformen støtter for å utvikle applikasjoner, i det minste "native apps".

[Rudde]

 

For det første kan du få ekstremt mye mer responsiv side ved å bruke SPA.

 

Å droppe nye sidelastninger gjør ikke nødvendigvis nettsiden din mer responsiv.

 

Om som alle [burde] vite, brukes ikke javascript og web-teknologi kun til å levere informasjon lenger. Det brukes [som sagt] til å lage webløsninger som er litt mer enn en blogg. Det brukes til å lage mobilapplikasjoner, det brukes til å lage desktopapplikasjoner.

At javascript brukes til webløsninger kommer ikke akkurat som noen overraskelse, men det brukes vel fint lite til å lage mobil- og desktopapplikasjoner?

 

Med mindre du snakker om såkalte "webapps" eller PhoneGap, Sencha, Ionic, NW eller lignende, som oversetter "webspråk" til andre språk osv. De fleste velger nok Swift, Java eller hva enn platformen støtter for å utvikle applikasjoner, i det minste "native apps".

 

Og ha all data en bruker skulle trenge i webportalen din lagret lokalt på brukerens enhet og la de navigere den uten å trenge å hente noe nytt på en server gjør løsningen veldig mye mer responsiv jo.

 

Det er noen løsninger som prøver å kompilere til andre språk, men ikke de du nevner, de gjør som jeg sa tidligere kjører i et webview.

 

De fleste velger ikke, kommer ikke til å velge og burde ikke veldige Swift eller Java for utvikling av ikke grafikk-baserte applikasjoner. Sett at de vil ha en bedrift som er profitabel da.

[0laf]

Og ha all data en bruker skulle trenge i webportalen din lagret lokalt på brukerens enhet og la de navigere den uten å trenge å hente noe nytt på en server gjør løsningen veldig mye mer responsiv jo.

Høres ut som utopi for de fleste nettsider, og også for en del applikasjoner?

SPA-løsninger er jo nærmest utelukkende basert på ajax, sockets eller lignende?

Har man en nettside som kun har én enkelt side, og som ikke trenger å laste nye sider, så har man jo egentlig ikke en SPA-løsning, men en særdeles snever nettside med sannsynligvis svært lite innhold dersom man kan sende alt til klienten i første og eneste "sending".

 

Det er noen løsninger som prøver å kompilere til andre språk, men ikke de du nevner, de gjør som jeg sa tidligere kjører i et webview.

Det er helt riktig, de kjører i et såkalt webview og lar deg lage applikasjoner som virker "overalt" med enkle webspråk.

 

Jeg forsøkte dog å lese litt oppover i tråden, men kan ikke se hvor du nevner den slags applikasjoner eller webview med et ord?

 

De fleste velger ikke, kommer ikke til å velge og burde ikke veldige Swift eller Java for utvikling av ikke grafikk-baserte applikasjoner. Sett at de vil ha en bedrift som er profitabel da.

Nå vet ikke jeg hva du mener med "grafikk-baserte applikasjoner", men de fleste velger vel språk ut i fra platform, ikke grafikken? Skal man lage en applikasjon for en iPhone eller iPad så velger man vel Swift, og skal man lage en applikasjon for Android, så velger man vel Java?

Endret 22. mars 2017 av adeneo

[Rudde]

 

Og ha all data en bruker skulle trenge i webportalen din lagret lokalt på brukerens enhet og la de navigere den uten å trenge å hente noe nytt på en server gjør løsningen veldig mye mer responsiv jo.

Høres ut som utopi for de fleste nettsider, og også for en del applikasjoner?

SPA-løsninger er jo nærmest utelukkende basert på ajax, sockets eller lignende?

Har man en nettside som kun har én enkelt side, og som ikke trenger å laste nye sider, så har man jo egentlig ikke en SPA-løsning, men en særdeles snever nettside med sannsynligvis svært lite innhold dersom man kan sende alt til klienten i første og eneste "sending".

 

Det er noen løsninger som prøver å kompilere til andre språk, men ikke de du nevner, de gjør som jeg sa tidligere kjører i et webview.

Det er helt riktig, de kjører i et såkalt webview og lar deg lage applikasjoner som virker "overalt" med enkle webspråk.

 

Jeg forsøkte dog å lese litt oppover i tråden, men kan ikke se hvor du nevner den slags applikasjoner eller webview med et ord?

 

De fleste velger ikke, kommer ikke til å velge og burde ikke veldige Swift eller Java for utvikling av ikke grafikk-baserte applikasjoner. Sett at de vil ha en bedrift som er profitabel da.

Nå vet ikke jeg hva du mener med "grafikk-baserte applikasjoner", men de fleste velger vel språk ut i fra platform, ikke grafikken? Skal man lage en applikasjon for en iPhone eller iPad så velger man vel Swift, og skal man lage en applikasjon for Android, så velger man vel Java?

 

Som sagt, webløsninger gjør mye mer idag enn de en gang gjorde, de prosesserer daten din og kan sende det litt ettervært som det er klart.

 

I en webløsning jeg jobber med nå lar jeg brukere bruke data de har lagt inn i løsningen og manipulere den selv før de har fått bekreftelse på at det er lagret i databasen, det gjør siden veldig mye mer responsiv da de de kan gjøre neste steg i sitt arbeid umiddelbart etter de avsluttet sist steg, websiden bryr ikke brukeren med respons fra server eller database.

 

Den opparbeider seg en backlog med data som må sendes til server, men jeg tvinger ikke brukeren til å vente på det.

 

Ja, nettopp...

 

https://www.diskusjon.no/index.php?showtopic=1766950&p=23804325

 

 

Hvis du ikke skal lage grafikk, altså tegne ting i f.eks. 3d på brukerens skjerm er det i 97% av tilfellene helt bortkasta og skrive en app to ganger for å ha den på android eller ios. Bedrifter og mange utviklere har ofte ikke luksusen og kunne eksklusivt holde seg på android eller iphone, det hadde jo vært helt idiotisk.

 

Skal du kun hente inn simple data, bruke simple sensorer på en måte som ikke krever kontinuerlig real-time overvåkning selv om services gjør det ganske bra idag. Så er det ingen poeng i å skrive applikasjoner mer komplisert enn du trenger med swift eller java, du en webview løsning vil spare de for tid om de skal utvikle for en platform og spesielt om de skal på 2 eller flere plattformer.