[coredev]

Varför arbetar jag med gammal beprövad teknik:
* Nya tekniker inom webben tenderar att inte kunna köras i alla webbläsare
* Nya tekniker skapar nya problem
* Ramverk tenderar att snabba upp så länge man håller sig till ramarna, måste man gå utanför ramarna blir livet ett helvete
* Ramverk tenderar att slöa ner din svarstid
* etc...

Jag menar verkligen inte att allt nytt är kass, men jag menar att det finns problem som man måste ta på allvar. Tänk kritiskt så hittar du de riktiga pärlorna (jQuery är ett exempel).

[linusoleander]

Ursprungligen postat av coredev

[...]Nya tekniker inom webben tenderar att inte kunna köras i alla webbläsare[...]

Nästan alla tekniker som jag nyss nämnde fungerar i alla webbläsare.
jQuery Mobile och Raphael.js är jag dock lite osäker på.

Ursprungligen postat av coredev

[...]Nya tekniker skapar nya problem[...]

För att du behöver lära dig något nytt, eller på vilket sätt tänkte du?

Ursprungligen postat av coredev

[...]Ramverk tenderar att snabba upp så länge man håller sig till ramarna, måste man gå utanför ramarna blir livet ett helvete[...]

Har du något exempel på de där?
Har själv inte varit med om de nämligen.

Ursprungligen postat av coredev

[...]Ramverk tenderar att slöa ner din svarstid[...]

Med bra cache-tekniker så känns det inte riktigt som att det här är ett särskilt stort problem.

Tar det tid att rendera siten, spara renderingen till cachen.
Tar det tid att läsa från databasen, spara informationen till cachen.

Det är i alla fall så jag har löst de med bara ett par rader kod.

Sedan så känns det lite som att flaskhalsen hos majoriteten av webbutvecklarna idag sitter någon helt annan stans. Okomprimerade JS- och CSS-filer är något som jag ser dagligen, för att bara nämna några fel.

[coredev]

Nja.. alltså jag dissade inte dina teknologier, de verkar mycket vettiga och jag använder själv en del av dem. Personligen tycker jag att Compass verkar riktigt spännande. Jag pratade mer i generella ordalag.


>> Ramverk tenderar att snabba upp så länge man håller sig
>> till ramarna, måste man gå utanför ramarna blir livet ett
>> helvete.

> Har du något exempel på de där? Har själv inte varit med
> om de nämligen.

Delar av Spring för Java, Hela ASP.NET för att ta ett par ruggiga exempel.


> Sedan så känns det lite som att flaskhalsen hos majoriteten
> av webbutvecklarna idag sitter någon helt annan stans.
> Okomprimerade JS- och CSS-filer är något som jag ser dagligen,
> för att bara nämna några fel.

Jag håller med om att den delen är otroligt eftersatt, ihop med cache-kontroll av statiskt material samt att man inte gzip:ar HTTP-responsen. MEN jag tror tyvärr att slöa ramverk är ett riktigt stort problem på webben idag. Ett problem i stort är att kunskapen om optimeringar är dålig bland utvecklare idag, min gissning är att det till stor del är konsultvärldens fel. Både för att för många rookies anlitas, men även för att kraven ligger på att producera så många sprint tasks som möjligt på så kort tid som möjligt.

Vill återigen gärna poängtera igen att de teknologier du visar upp i din lista inte har något att göra med denna diskussionen. :-)

[MRDJ]

Ursprungligen postat av coredev

Nja.. alltså jag dissade inte dina teknologier, de verkar mycket vettiga och jag använder själv en del av dem. Personligen tycker jag att Compass verkar riktigt spännande. Jag pratade mer i generella ordalag.


>> Ramverk tenderar att snabba upp så länge man håller sig
>> till ramarna, måste man gå utanför ramarna blir livet ett
>> helvete.

> Har du något exempel på de där? Har själv inte varit med
> om de nämligen.

Delar av Spring för Java, Hela ASP.NET för att ta ett par ruggiga exempel.


> Sedan så känns det lite som att flaskhalsen hos majoriteten
> av webbutvecklarna idag sitter någon helt annan stans.
> Okomprimerade JS- och CSS-filer är något som jag ser dagligen,
> för att bara nämna några fel.

Jag håller med om att den delen är otroligt eftersatt, ihop med cache-kontroll av statiskt material samt att man inte gzip:ar HTTP-responsen. MEN jag tror tyvärr att slöa ramverk är ett riktigt stort problem på webben idag. Ett problem i stort är att kunskapen om optimeringar är dålig bland utvecklare idag, min gissning är att det till stor del är konsultvärldens fel. Både för att för många rookies anlitas, men även för att kraven ligger på att producera så många sprint tasks som möjligt på så kort tid som möjligt.

Vill återigen gärna poängtera igen att de teknologier du visar upp i din lista inte har något att göra med denna diskussionen. :-)

jag håller helt med dig..
jag tror att många börjar kolla på optimering först när kunden skriker..
Det är väldigt viktigt med optimering bland annat eftersom Google rankar delvis på hur snabb sidan är..

Själv håller mig till Drupal där det redan finns fullt stöd till cache, gzip, merge css och JS osv.. funkar väldigt bra prestandamässigt.

[linusoleander]

Får ta och väcka den här tråden igen.

Ursprungligen postat av tartareandesire

Du har ytterligare problem när det gäller ramverk förutom att de oftast är onödiga bromsklossar.[...]

På vilket sätt skulle ett ramverk bromsa utvecklingen?

Ursprungligen postat av tartareandesire

[...]Om du ska hitta andra utvecklare som ska arbeta med ditt projekt så måste du hitta just de som kan de ramverk du använder dig av vilket bara krånglar till saker och ting.[...]

Alla ramverk jag sitter i är väldokumenterade, testade och utvecklas av ett jätte-community. Vilket är inversen till koden Svensson sitter med.

Om någon ska sätta sig in i en kodbas som jag byggt så hänvisar jag bara till de redan satta rekommendationerna och den befintliga dokumentationen.

Hur gör du?

Ursprungligen postat av tartareandesire

[...]Minifiering, optimering av olika slag (cache, memcache, sphinx etc.), effektiva template-system (vet inte om du räknar in dessa i ramverk?) för att separarera kod osv. är betydligt bättre tekniker att arbeta med om man ska skriva resurssnål och effektiv kod för stora, moderna webbtjänster.[...]

Nu är jag inte helt 100 på vad du menar, men sitter du i ett modernt ramverk i dag, te.x Rails så består kodbasen av en massa byggklossar. De enda Rails-teamet har gjort (kortfattat) är att skriva all boilerplate-code för dig.

Själv förespråkar iden med att implementera kärnan i projekt, inte vill jag jobba med layouten, skriva SQL-kod eller utfinna hjulet på nytt.

Ursprungligen postat av tartareandesire

[...]För de allra flesta webbplatser så spelar det idag heller ingen som helst roll om de komprimerar sin css och js eller inte.[...]

Det är även det här som skiljer "agnarna från vetet".

Det ska, enligt min mening, inte ta någon extra tid att göra något så trivialt som att komprimera sina CSS- och JavaScript-filer. Precis på samma sätt som att det inte ska ta någon extra tid att skriva valideras CSS-, JavaScript- och HTML-kod.

Ursprungligen postat av Luncode

[...]Det känns onödigt tungt och en stor del av meningen med det verkar vara att bygga en massa autogenererad klientkod.[...]

Du får gärna skriva booilerplate-koden manuellt om du vill.
Man bör, om möjligt dock lämna över skitgöran till en dator.

Jag tror att det enklaste sättet för dig att se skillnaden mellan Rails och exempelvis Sinatra är att bygga en enklare applikation.

Jag har svårt att se hur man skulle klara av att hålla en större applikation tillräckligt torr i Sinatra. Visst det går, men ack så jobbigt.

Ursprungligen postat av coredev

[...]Nya tekniker inom webben tenderar att inte kunna köras i alla webbläsare[...]

Fel. CoffeeScript, HAML, SASS, för att bara nämna några genererar plattformsoberoende, validerad kod efter alla konstens regler.

Koden som i slutändan körs i produktion är alltså mer körbar än koden som du själv skrivit.

Ursprungligen postat av coredev

[...]Nya tekniker skapar nya problem[...]

Resonerar du så om allt nytt du måste lära sig?

Ursprungligen postat av coredev

[...]Ramverk tenderar att snabba upp så länge man håller sig till ramarna, måste man gå utanför ramarna blir livet ett helvete[...]

För .NET kanske, men långt i från när det kommer till Rails eller Django.
Du kan ju även fråga dig om det verkligen är rätt att "gå utanför ramarna". I många fall så är begreppet ekvivalent med fulhack.

Men visst, vill du skriva fulkod om du känner för de. Jag gjorde de själv i ung ålder.

Ursprungligen postat av coredev

[...]Ramverk tenderar att slöa ner din svarstid[...]

Det är billigt att skala en servrar, det är dyrt att ta betala för utveckling.

[tartareandesire]

Ursprungligen postat av linusoleander

Får ta och väcka den här tråden igen.

På vilket sätt skulle ett ramverk bromsa utvecklingen?

Det beror helt på vad det är för typ av företag och verksamhet. Jag håller absolut med dig om att det finns fördelar med ramverk också men det passar inte alla och innebär en reell begränsning när man ska ta in nytt folk vilket förmodligen spelar en större roll för små företag med små resurser. Är du en välkänd och attraktiv arbetsgivare så innebär det inte några direkta svårigheter men det är en helt annan situation för okända småföretagare.

Ursprungligen postat av linusoleander

Alla ramverk jag sitter i är väldokumenterade, testade och utvecklas av ett jätte-community. Vilket är inversen till koden Svensson sitter med.

Om någon ska sätta sig in i en kodbas som jag byggt så hänvisar jag bara till de redan satta rekommendationerna och den befintliga dokumentationen.

Hur gör du?

Då är allt precis som det ska vara men jag skulle nog tyvärr vilja säga att en övervägande majoritet av alla projekt saknar en vettig dokumentation. Ramverk med en inbyggd standardisering och dokumentationsfunktionalitet är helt klart användbara. Återigen är det nog så att de flesta mindre verksamheter inte anser sig ha tid till detta eller att de inte tror att det kommer till användning. De flesta inser snart att det är precis tvärtom. Det är ofta bra att på ett tidigt stadium bestämma sig för en standard som ska gälla inom ens verksamhet.

Återigen så har du emellertid ett problem i en liten verksamhet med få utvecklingstimmar där du snabbt vill kunna ta in personer för att fixa småsaker.

Ursprungligen postat av linusoleander

Nu är jag inte helt 100 på vad du menar, men sitter du i ett modernt ramverk i dag, te.x Rails så består kodbasen av en massa byggklossar. De enda Rails-teamet har gjort (kortfattat) är att skriva all boilerplate-code för dig.

Zend är också trevligt att arbeta med, likaså jQuery. Det finns som sagt både fördelar och nackdelar med ramverk och det passar inte alltid.

En kompetent person skriver lättillgänglig kod oavsett om ett ramverk används eller inte. Dokumentationen är oerhört mycket viktigare än huruvida man använder ett ramverk eller inte. Saknas sådan blir det krångligt så snart någon annan person är inblandad.

Ursprungligen postat av linusoleander

Det är billigt att skala en servrar, det är dyrt att ta betala för utveckling.

Återigen varierar det från ett projekt till ett annat. Man får också tänka på det hela ur ett miljöperspektiv. Materiella resurser och energi bör begränsas så långt det är möjligt. Det ligger på allas ansvar. Det finns som sagt var aldrig en lösning som passar i alla situationer.

Ditt inlägg blev lite av en enda lång hyllning till Rails Det finns ju ett gäng andra ramverk som är betydligt mer välanvända.

Riskerar alltid att bli en PC vs Mac-diskussion i sådana här frågor. Ramverk kan vara bra. Att koda utan ramverk kan vara bra. Tycker vi lämnar den diskussionen nu och återgår till huvudtemat

jQuery Mobile är ett väldigt användbart nytt ramverk av betydligt större vikt än exempelvis Rails även om det givetvis inte fyller samma funktion.