Gå til innhold

Web-programmeringsspråk

GeirGrusom

Anbefalte innlegg

Videoannonse

Videoannonse
Annonse
tickinghd

tickinghd

Skrevet
Skrevet

PHP er søppel, det har enda ikkje unicode støtte og alt er bare griseri. [...]

 

Ja PHP er ikke det mest elegante skriptspråket, men det er totalt urelevant.

 

"There are only two types of programming language:

The type everyone complains about.

The type nobody uses or cares about."

 

Bjarne Stroustrup

Lenke til kommentar
siDDis

siDDis

Skrevet
Skrevet

Ja for det er jævlig få som bruker og klager over f.eks Python.

 

PHP har så mange mangler at det aldri vil vere meir enn eit hobbyverktøy for hobbyutviklere.

Einaste grunnane til at PHP er populært er at det er lett å lære seg og at mange store prosjekter bruker det til å lage populære vevstadar(som automatisk betyr at då er teknologien bak bra).

 

Facebook er jo eit kjempeeksempel på kor feil valg av verktøy dei har valgt.

Lenke til kommentar
  • 1 måned senere...
....

....

Skrevet
Skrevet (endret)

Vel, idéen er å gjøre HTML, CSS og JavaScript til ett eneste sømløst backend språk. Hele DOM hierarkiet er objektorientert fra første stund, og ren HTML blir mer som en "inline assembly" mulighet der det er nødvendig.

 

Dersom en eksempelvis har noe slikt:

 

 

my_database : mysql.connection("username=anon;data source=localhost");
html
{
 script(source="Helloworld.js");

 body(bgcolor=color.red)
 {
   body.onclick()
   {
     alert("Hello World!");
   }
   my_link : link(href="http://www.helloworld.com");
   my_table = from "studenter" in my_database select "navn", "karakter";
   my_table.fill();
   foreach(entry in my_table)
   {
     div
     {
       entry.navn + br + entry.karakter.tostring();
       div.onclick()
       {
         my_link.content = entry.navn;
       }
     }
   }
 }
}

Det er ikke noen ny idé (dvs. det er en særdeles interessant idé). Her er noe lignende i Lisp, fra 1999:

 

(html
(head
 (title "BlaBlaBla - an introduction"))
(body
 (hr)
 "This is a test"
 (form :action program
       :method "post"
       (input :type "hidden" :name "action" :value "error")
       (input :type "submit" :value "ok"))))

I et funksjonelt språk kan man ta dette et steg videre og betrakte et «element» (som a) som en spesifikasjon for hva som skal gjøres med innholdet og «attributtene» som parametre til denne spesifikasjonen, dvs. ((a :href "http://www.foo.com/") "bar"), hvor kallet til a returnerer en funksjon som behandler "bar".

 

Usenet-posten dette er hentet fra er fortsatt treffende, til tross for at den er 11 år gammel. Mye av det som står om Perl beskriver også PHP:

 

 

ett slikt problem er kompleksiteten som er forbundet med syntaksen i forskjellige markup-språk, både når det gjelder lesbarhet og vedlikehold. her er et perlscript som viser hva jeg mener:

 

print "<HTML>\r\n"                      ;
print "<HEAD><TITLE>Blablabla - an introduction</TITLE></HEAD>\r\n" ;
print "<BODY><H1>blablabla - an introduction</H1>\r\n" ;
print "<HR>\r\n"                        ;
print "<FORM ACTION= $program METHOD=\"POST\">\r\n" ;
print "<INPUT TYPE=\"hidden\" NAME=\"action\" VALUE=\"ERROR\">\r\n" ;
print "<INPUT TYPE=\"submit\" VALUE=\"OK\">\r\n" ;
print "</FORM>\r\n"                     ;
print "</BODY></HTML>\r\n"                ;

det som slår meg er mangelen på abstraksjon, og måten du blir tvunget til å lese og skrive det samme igjen og igjen. men det er enkelt, og det fungerer, så det er lett å bare la det være slik. av og til har jeg gjort desperate forsøk på å få vekk de uvesentlige detaljene:

 

function make_link (url linkname)
{
 echo "<a href=\"$url\">$linkname</A>";

}

resultatet er patetisk; ikke bare er det mer å skrive, men andre som leser det får problemer med å forstå hva som menes:

 

echo "Come to my" . make_link("http://www.fantastic.com", "fantastic") . "homepage";

 

Som andre nevner har man jo i dag SASS, HAML og Zen Coding, men dette er mer som makroekspansjon å regne.

 

Det beste hadde vært en DOM-modell, gjerne objektorientert, hvor man kunne velge seg akkurat det abstraksjonsnivået som passet best til oppgaven. For en liten hjemmeside kunne man sysle direkte med div-objekter o.l., mens man for større nettsteder kunne justere parametre til et layoutobjekt som genererte slikt automatisk (mange CSS-løsninger baserer seg jo på en svært bestemt sammensetning av div-er). I prinsippet kunne man fortsette å kollapse trær og stable nivåer når siden vokste til, og dermed håndtere skalering oversiktlig og effektivt. :cool:

Endret av ....
Lenke til kommentar
  • 1 måned senere...
  • 4 uker senere...
ti-guru

ti-guru

Skrevet
Skrevet (endret)

Hei,

 

Har jobbet en stund med GWT og kom akkurat over Vaadin. Ser egentlig veldig ut som det trådstarter etterlyser; ett språk for webutvikling som er objektorientert med abstraksjon bort fra html/css/js osv. Er det noen her som har erfaringer med bruk av Vaadin? Hvordan håndterer rammeverket skalering (mhp statushåndtering av info på server)? Er det andre alternativer som er bedre egnet?

Endret av ti-guru
Lenke til kommentar
worseisworser

worseisworser

Skrevet
Skrevet (endret)

Kan minne om et par av prosjektene jeg surrer med dette. Sjekk eksemplene på bunnen av http://www.nostdal.org/

 

Noen kjappe punkter sånn på morgenen her;

 

  • MVC.
  • Støtte for deklarativ, reaktiv, dataflyt-orientert programmering; kjekt i UI-sammenheng.
  • Multi-core støtte v.h.a. STM (minnetransaksjoner), atoms, compare-and-swap (CAS) m.m..
  • Skalerbar "Comet"/reverse HTTP-løsning; testet med 20k klienter.
  • Sanntids utvikling og manipulering av det en ser i nettleseren (uten page-refresh om så måtte være) via en REPL og andre verktøy via et språk som kompileres direkte til maskinkode on-the-fly.
  • Lett å porte til andre Common Lisp implementasjoner selv om jeg ikke har fått gjort dette ennå.
  • Work-in-progress; det er en hel rekke ting jeg ikke er ferdig eller fornøyd med.

Endret av worseisworser
Lenke til kommentar
asicman

asicman

Skrevet
Skrevet

Imponerende!

 

Jeg har brukt et continuation basert rammeverk som heter Weblocks en del i det siste og har blitt ganske imponert av dette også. Det veldig enkelt å bruke eller lage UI komponenter som kalles Widgets. Her er forresten en liste over noen egenskaper i diverse rammeverk, inklusive Weblocks.

 

http://viridian-project.de/~sky/user-guide.stx.html#Weblocks.compared.to.other.frameworks

 

Jeg brukte Websessions/Webactions tidligere, men mange ting er utrolig mye enklere i Weblocks enn i Websessions. Desverre så er det ikke så mange som bruker Weblocks og dokumentasjonen er ofte mangefull.

Lenke til kommentar
worseisworser

worseisworser

Skrevet
Skrevet

Imponerende!

 

Jeg har brukt et continuation basert rammeverk som heter Weblocks en del i det siste og har blitt ganske imponert av dette også. Det veldig enkelt å bruke eller lage UI komponenter som kalles Widgets. Her er forresten en liste over noen egenskaper i diverse rammeverk, inklusive Weblocks.

 

Jeg kjenner til Webblocks, lpolzer, s11001001 og coffeemug (IRC lever fortsatt!) -- selv om jeg ikke har fulgt med på en stund; kanskje på tide å ta en titt igjen. :)

 

"Widgets", slik en tenker på dem i mer tradisjonell UI-sammenheng (Qt, Gtk+ o.l.), bruker jeg også. Ser Weblocks støtter persistence også; dette har jeg også fått på plass sånn helt enkelt ihvertfall: SW-DB -> Postmodern -> PostgreSQL.

 

Jeg droppet continuations; husker ikke helt grunnen, tror jeg, men siden jeg ikke bruker page-redirects og annet; tar ikke hensyn til at JavaScript er slått av f.eks., så jeg ikke helt poenget. Jeg er kanskje noe skeptisk til dette med continuations og debugging; det er mulig dette er tull da det kan være løst i cl-cont for alt jeg vet.

 

 

http://viridian-project.de/~sky/user-guide.stx.html#Weblocks.compared.to.other.frameworks

 

Jeg brukte Websessions/Webactions tidligere, men mange ting er utrolig mye enklere i Weblocks enn i Websessions. Desverre så er det ikke så mange som bruker Weblocks og dokumentasjonen er ofte mangefull.

 

Hm, ja. Jeg står stadig fast på deler av APIet jeg ikke er fornøyd med. Jeg synes f.eks. at jeg har tuffset til APIet for håndtering av events->callbacks ganske greit nå, og forsøk på å skrive dokumentasjon ment for, ihvertfall, slutt-bruker har vært bortkastet tid "hver gang".

 

Nei; jeg har lyst til å fikse en hel rekke ting; håper jeg får tid fremover. :)

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
Gå til emneliste

  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...