Ich plane mich mal wieder mit Web Programmierung zu beschäftigen. Bisher war mein Plan eigentlich Play 2/Java zu verwenden (ist aber schon ein paar Jahre her). Nun habe ich aber gelesen, daß in der Zwischenzeit Contaier (Docker?) wohl sehr beliebt sind, da die, wenn sie einmal fertig sind, sich leicht bei unterschiedlichen Anbietern hosten lassen. Container sollen ja auch resourcenschonender als ein virtualles Linux + Java Installation sein. Auch würde ich lieber C# als Java verwenden, was ohne Container wohl eher selten als Hosting Platform unter Linux angeboten wird. In einem Container wäre es dann ja wohl egal ob ich Java oder C# verwende. Hat jemand einen Tip welche Route man heute einschlagen sollte? Wichtig wäre mir, daß ich später leicht den Hoster wechseln kann, ohne etwas an der Webseite ändern zu müssen oder gar das Framework/Sprache wechseln zu müssen.
:
Bearbeitet durch User
Was Du in einem Docker Image „versteckst“ ist grundsätzlich egal. Aber die Binaries müssen schon auf der Plattform laufen. Es wäre mir neu, dass C# Binaries unter Linux lauffähig sind. Ich persönlich würde LUA wählen für kleineres. Für grösseres, was auch Skalierbar sein muss Java. (Natürlich nur wenn die Hosting Plattform Linux ist)
:
Bearbeitet durch User
Ich finde die Richtung, in die sich der Web-Kram entwickelt momentan ziemlich furchtbar. Es werden mit immer mehr absurd komplexen Frameworks immer schlechtere Websites erzeugt. Dabei kann man heutzutage mit sehr wenig Kram unglaublich viel erreichen. Was heute mit 10 Zeilen HTML und CSS geht, war vor 10 Jahren noch tagelanges Gebastel mit JavaScript und Flash. Also mein Tipp: mal den umgekehrten Ansatz wählen und versuchen, eine Webseite unter Verwendung von möglichst wenig Krempel zu bauen. Man ist dann auch überrascht, dass die in wenigen ms geladen und gerendert wird, nicht wie der übliche Murks ...
:
Bearbeitet durch User
Ich kann mich nur Sven B. anschließen. Außerden bei Oracle Java beachten: https://www.heise.de/developer/meldung/Oracle-Ende-fuer-oeffentliche-Updates-von-Java-8-ab-Februar-2019-4035059.html
Sven B. schrieb: > Es werden mit immer mehr absurd komplexen Frameworks immer schlechtere > Websites erzeugt Selten so einen treffenden Satz gelesen. Und ich frage mich, was Docker "leightweight virtual machine" mit WebProgrammierung zu tun haben soll. Web ist zunächstmal HTML, und wenn man dann unbedingt braucht Skripte (braucht eine WebSeite selten, nur interaktive) und wenn es dann nicht ohne geht auch HTML5 (z.B. selbstprogrammierte WYSUWYG Editfelder) aber das macht ja kaum jemand, 1:1Mio oder so. 99.9% vom Web-Scheiss braucht niemand. Neueste Errungenschaft: druckbar ist es auch nicht mehr. Speicherbar ja schon lange nicht mehr.
Static site generators sind ziemlich im Kommen. Ergibt natürlich keinen Sinn für eine Seite wie dieses Forum hier, aber für viele andere schon. Dann muß man auch nicht mehr täglich seine Webseite mit Sicherheitsupdates für PHP, WordPress, Theme und drölfzig Plugins versorgen, wobei jedes Update auch was kaputtmachen kann, und logischerweise ist die Webseite dann verdammt schnell.
Wenn es Dir darum geht, daß die Webseite überall laufen soll, verzichte auf jede Art Framework. Orientiere Dich an den Möglichkeiten, die Dir HTML/CSS, PHP und MySQL bieten, jeweils die neuesten Versionen von PHP und MySQL verwenden. In Zukunft könnte auch MariaDB aktuell werden, das ist eine freie Abspaltung von MySQL, da letzteres immer mehr kommerzialisiert wird. Für clientseitige Programme, versuch bei JavaScript zu bleiben. Flash wäre auch noch eine Möglichkeit, mögen manche Benutzer aber nicht. Für dynamische Inhalte bieten sich z.B. Ajax-Techniken an. Weitere Späße kommen noch hinzu, wenn die Seite für alle Benutzer passen soll. Dann brauchst Du noch eine mobile Version für Handys und Tablets, sowie eine barrierefreie Variante für Blinde.
Ben B. schrieb: > Flash wäre auch noch eine Möglichkeit Nein, wäre es nicht. Wir haben 2019, Flash ist abgekündigt, und viele Browser unterstützen es gar nicht mehr.
René H. schrieb: > Es wäre mir neu, > dass C# Binaries unter Linux lauffähig sind. Also .NET Core 3 is unter Linux lauffähig und soll auch mit ASP.NET funktionieren. MaWin schrieb: > Und ich frage mich, was Docker "leightweight virtual machine" mit > WebProgrammierung zu tun haben soll. Na ja, eine Webseite zu Hause auf seinem eigenen Rechner zu Programieren ist nicht das Problem. Das Problem ist, daß das, was man zu Hause programmiert hat nachher auch auf einem angemieteten Hoster läuft. Und hier ist man dann doch wieder an die Vorgaben der Hoster gebunden. Mit Docker, denke ich, könnte man ohne Rücksicht auf vorkonfigurierte Hoster Angebot die Plattform/Framework/Programmiersprache wählen, die einem am besten gefällt und hat nachher gute Karten, daß man auch einen Hoster findet, auf dem man die Webseite dann auch im Internet laufen lassen kann. Oder nach welchen Kriterien wählt ihr Framework und Sprache aus?
Ben B. schrieb: > > Für clientseitige Programme, versuch bei JavaScript zu bleiben. Flash > wäre auch noch eine Möglichkeit, mögen manche Benutzer aber nicht. Flash?? Es gibt doch bald keine Browser mehr die das Plugin noch ausführen.
Ben B. schrieb: > Weitere Späße kommen noch hinzu, wenn die Seite für alle Benutzer > passen soll. Dann brauchst Du noch eine mobile Version für Handys und > Tablets, sowie eine barrierefreie Variante für Blinde. Achso, und das ist auch Blödsinn. Wir haben 2019, und responsive design bedeutet eine Seite für alles. Das macht man mit semantischem Markup in HTML5, CSS und etwas Aria-Markup.
LOL! Na denn viel Spaß, vor allem mit der barrierefreien Seite. Gut, Flash ist vielleicht etwas alt, aber es gibt noch viele Seiten, die damit laufen. Dann streiche Flash, mußt halt bei HTML/CSS/JS bleiben, aber auch damit bekommt man viele grafische Effekte zustande wenn man sowas braucht (ich brauche es nicht).
Also Docker container "sollen" portabel sein, sie bringen ja auch ihr eignes Linux mit.. dass sie ressourcenschonender sind wage ich zu bezweifeln.. wer sich mal die Load einer virtual box anschaut die "alleine" eine webanwendung ausführt und dasselbe dann in einen Dockercontainer innerhald derselben virtual box wird feststellen, dass das auch nur zusätzliche Last und steigende Zugriffszeit sein kann.. wenn zum Docker dann noch n Zookeeper dazukommt und ein Kafka und .... weiss der Himmel was Du noch alles 'brauchst' dann hat man zwar schnell was wunderbar skalierbares das sich unfassbar leicht auf 200 redundante Server verteilen lässt... was aber einen einzelnen Server schnell bei nur minimalem Besucheraufkommen in die Knie zwingen kann (je nach Hardware) weil alle interne Kommunikation durch die Netzwerkkarte will Für Durchschnittskinkerlitzchen rate ich also eher davon ab. Will man indes eine Weltweite Userschar binnen weniger "klicks" mit ausreichend Zugriffsgeschwindigkeit und vermeindlich grossen Datenmengen versorgen machen solche Container Sinn.. aber wirklich nur dann meiner Meinung nach. MMO games social message platformen etc immer im Container.. webseiten mit 'einfachen' Funktionen niemals meiner Meinung nach
Ben B. schrieb: > LOL! Na denn viel Spaß, vor allem mit der barrierefreien Seite. Das ist überhaupt kein Problem, wenn das von vornherein mit bedacht wird. Habe ich auch schon gemacht. Die allermeisten Tips von WCAG 2.1 sind übrigens auch für nicht-behinderte Benutzer wertvoll. Wer hat sich nicht schon über kontrastarme kleine Schrift in grau-auf-grau geärgert? Und die separate Mobilversion war vor 10 Jahren mal en vogue, heute nicht mehr. U.a., weil Google 1) nur noch die Mobilversion indiziert, falls es eine getrennte gibt. 2) Google Webseiten im Ranking abstraft, die mobil / Desktop unterschiedliche Inhalte bieten. 3) 65% aller Zugriffe heute ohnehin mobil stattfinden. Dazu kommt natürlich noch, daß 4) die Pflege von zwei Versionen unnützer Aufwand ist.
Nop schrieb: > Wir haben 2019, und responsive design bedeutet eine Seite für alles Man könnte aucb sagen, eine Seite für Niemand. Plain HTML wäre eine Seite für alle. Ben B. schrieb: > Flash wäre auch noch eine Möglichkeit Flash ist tot, als der erste WebSpinner auf die giergetriebene Idee kam, damit nervende Werbung zu verpacken. Daraufhin wird es keinen mehr gegeben haben, der Flash noch installierte.
MaWin schrieb: > Plain HTML wäre eine Seite für alle. CSS ist erfunden und kann heute eine ganze Menge. Es ist kein Problem, mit media queries (auf em/rem, nicht auf px) das Layout der vorhandenen Fenstergröße anzupassen.
sid schrieb: > Also Docker container "sollen" portabel sein, > sie bringen ja auch ihr eignes Linux mit.. Naje, docker ist auch nur unter Linux wirklich brauchbar. > dass sie ressourcenschonender sind wage ich zu bezweifeln.. > wer sich mal die Load einer virtual box anschaut die > "alleine" eine webanwendung ausführt Container sind keine VMs. Es findet keine emulation statt. In so einem Docker Container laufen normalerweise auch nur ein zwei Prozesse, wie wenn man sowas direkt ausführen würde. Einziger unterschied zum direkten ausführen der Programme ist, dass die Prozesse andere Namspaces und Cgroups als die anderen Prozesse des Systems zugewiesen bekommen, und deshalb andere Resourcen sehen und verwenden können. Deshalb braucht das auch keine zusätzliche Rechenleistung, denn auch normale Systemprozesse sind teil von diversen Namespacen, etc. Ich bin zwar kein Fan von docker. Container und Namespaces find ich aber super. Hab schon alle meine linux libvirt KVM VMs durch libvirt LXC Containern (nicht zu verwechseln mit LXC/LXD containern) ersetzt, braucht nun viel weniger RAM und läuft auch schneller. Selbst in einigen meiner Makefiles nutze ich mittlerweile Namespaces, um zeug zu tun wie Root und andere Benutzer zu simulieren, kein sudo mehr nötig. Und Dinge wie VLC packe ich mit unshare in nen namespace ohne Netzwerkzugriff, etc.
> Flash ist tot, als der erste WebSpinner auf die giergetriebene > Idee kam, damit nervende Werbung zu verpacken. Halte ich für Quatsch, dann wäre GIF noch viel früher gestorben.
Sven B. schrieb: > Es werden mit immer mehr absurd komplexen Frameworks > immer schlechtere Websites erzeugt. Etwas unpraktisch ist auch die edge/safari situation. Die ganzen ES6 geschichten laufen super unter Firefox und Chrome, aber Edge kann einige konstrukte immernochnicht, und wenn man wirklich mal JS braucht, muss man doch wieder ES5 style programieren, oder einige ES6 Syntax vermeiden, oder babel nehmen (und zieht sich damit ~500 npm Pavkete rein...). und von Safari will ich garnicht erst anfangen, das Ding ist mitlerweile schlimmer als der IE, sag ich euch. Selbst einige riviale reine HTML/CSS Konstrukte bekommt es nicht auf richtig dargestellt.
Firefox kannst Du auch so langsam abhaken. Ein Tab Forum, ein Tab Youtube, ein Tab Arbeit... schwupps 1..2GB RAM weg. Nimmt man noch andere aufgebauschte Seiten wie Facebock oder ebay dazu, nächste 2..3GB belegt. Okay, mag man argumentieren, daß heutige Maschinen soviel RAM locker übrig haben sollten, aber benutzerfreundlich ist was anderes. Richtig schlimm wird es, wenn man sich Livestreams anschaut. Dann baut Firefox irgendwelchen Mist und spätestens wenn er 32GB Datenschrott im Speicher angesammelt hat, ruckelt der Stream natürlich nur so vor sich hin. Außerdem - man gibt sich ja so viel Mühe, der seriöseste und unabhängigste Browser sein zu wollen - blendet dann aber auf neuen Tabs unten irgendwelche "coolen Sprüche" ein, die man auch als Eigenwerbung interpretieren könnte... super, genau das will der Benutzer sicherlich von einem seriösen Browser haben. Alles Bullshit. Der IE macht das nicht und Chrome macht das auch nicht.
:
Bearbeitet durch User
DPA schrieb: > Container sind keine VMs. Es findet keine emulation statt. In so einem > Docker Container laufen normalerweise auch nur ein zwei Prozesse, wie > wenn man sowas direkt ausführen würde. das hab ich nicht behauptet.. ich sagte-oder wollte zu verstehen geben- dass es leichter ist auf dem heimischen PC mal eben dutzende virtuelle server zu installieren, als sich bei Amazon eine handvoll zum testen zu leihen. Und innerhalb des Container ist (je nach konfiguration) schon ne ganze Menge los.. von virtuellen Netzwerkadaptern, bis hin zum kompletten kernel kann da nahezu alles drin sein. Wieviel wann und wo genau lässt sich IMHO am einfachsten mit einer VM ausprobieren.. Denn während ich WYSIWYG ungefähr so gut leiden kann wie Schweissfüsse, find ich zwei htop screenshots leichter auf einen Blick zu vergleichen als mich durch logs zu blättern ;) Und naja da kann man eben mal verschiedene distros nebeneinander auch mal parallel und kreuzverlinkt und wenn's mal klemmt ist man per Schenkeldruck bereit zum Neustart; und man kann Lasten simulieren wie man möchte ohne dass der Provider was von DDoS faselt und einen aussperrt ;) deswegen die Virtualbox.. prima zum testen ohne auf Dritte angewiesen zu sein :D [und der obligatorische PenTest ist auch leichter wenn man sich auf sich selber verlassen muss ;)] naja persönliche Präferenz vielleicht. ich bin auch son AntiCloud typ :D Aaaber und da muss ich Dir mindestens zum Teil widersprechen DPA schrieb: > Deshalb braucht das > auch keine zusätzliche Rechenleistung, denn auch normale Systemprozesse > sind teil von diversen Namespacen, etc. Denn verglichen mit einem lokalen server der ohne container auf sagen wir ubuntu rennt kostet der docker server der den container hosted auf demselben ubuntu system eben DOCH mehr Ressourcen (manchmal bis zu 10% nur für Container und Netzwerk verwaltung) läd man noch n zookeeper ein und möchte über Kafka quatschen kommen nochmal 5-6% drauf (Netzwerk auslastung steigt am stärksten, und proportional etwas an der CPU Last) Und das merkt man schon recht schnell bei komplexeren Webanwendungen (bei etwa 120-150 queries pro minute) Klar, wenn nix im Container passiert, ist nix von zusätzlicher Last spürbar, wenn aber richtig was los ist hat er eben doch Auswirkungen (nicht alle davon sind immer Willkommen ;))
HTML soll sich noch recht gut hosten lassen... Muss es denn immer die neusten Hipes sein?! Gruss Chregu
MaWin schrieb: > Daraufhin wird es keinen mehr > gegeben haben, der Flash noch installierte. Leider muss ich es auf einem Rechner lauffähig erhalten, meine Frau spielt Farmerama. ;-(((( flashneindanke
Es ist ja alles ganz schön, was ihr da so schreibt, aber: Das ein Container mehr Resourcen braucht, als wenn man den Webserver direkt unter Linux ausführt ist irrelevant. Wenn man sich bei einem Hoster Webspace mietet, wird man nie einen ganzen Rechner für sich alleine haben. Oder es wird teuer. Der Overhead ist also nicht zu vermeiden. Es gibt nur den Vergleich Container vs VM. Und den sollten Container eigentlich gewinnen. Es ging mir mit einer Frage auch weniger darum wie man eine Webseite programmiert. Was mich eigentlich interessiert ist wo der Trend hostingtechnisch hingeht. Es gibt Hoster die sich auf PHP, RubyOnRails, ... spezialisiert haben. Dort kann man nichts anderes machen, als das, was der Provider bereitstellt. Ansonsten bleiben VM und Container. Hier ist man nicht an PHP, Ruby oder Python gebunden und kann sein eigenens Ding machen. Da ich serverseitig C# bevorzugen würde (Jave wäre 2. Wahl, alles andere nur ungern) scheinen VMs oder Container die einzige Wahl zu sein. Vor viiieeelllenn Jahren hatte ich mal einen Hoster. Dort ging nur Perl. Das war allerdings 2000. Ist also schon lange her. Wie und wo würdet ihr C# oder JAVA basierte Frameworks hosten? Hohe Ansprüche an die Nutzerzahl habe ich im Augenblick nicht. Kosten wären interessanter. Aber ich würde gern frei sein in der Wahl der Tools, Sprachen, Frameworks, Datenbanken.
:
Bearbeitet durch User
Ich hoste meine Sites/APIs, wenn nicht auf Azure, hier: https://www.smarterasp.net/hosting_plans deployment geht direkt aus dem Visual Studio raus. Cheers, Roger
Ganz ehrlich frag wo anders..hier wird Flash und Einsatz ohne Frameworks vorgeschlagen.. das zeugt nicht gerade von Expertise, wenn's tatsächlich was ernsthaftes werden soll
Fruit schrieb: > Ganz ehrlich frag wo anders..hier wird (...) Einsatz ohne > Frameworks > vorgeschlagen.. das zeugt nicht gerade von Expertise Eben, das sind ja auch Aussagen von Leuten, die die Seite benutzen sollen. Selbst wenn die Megabytes an Traffic niemanden stören, ich hasse Eingabefelder, die erst funktionieren wenn die Seite komplett geladen ist oder wo man zweimal Enter drücken muss. Oder wo "responsive" bedeutet, dass es nur mit der richtigen Fenstergröße gut funktioniert - das letzte Jahrtausend lässt grüßen </kotz>
Be B. schrieb: > Da ich serverseitig C# bevorzugen würde (Jave wäre 2. Wahl, alles andere > nur ungern) scheinen VMs oder Container die einzige Wahl zu sein. Wer C# auf einen Server packt, der hat es nicht besser verdient, wenn die Seite gehackt wird.
Nop schrieb: > CSS ist erfunden Eine Menge ist erfunden, aber nicht jeder Browser kann es, und selten wurde durch die Erfindungen die Datenmenge geringer. Besonders beliebt sind überbordende megabytegrosse Universal-CCS die richtig Spass machen wenn im mobilfunktechnischen Hinterwald Deutschland mal wieder eine eigentlich primitive Seite "100 Worte Text" nur mit GPRS übertragen werden soll. Aber die beklagenwerte Realität deutscher Internetabdeckung interessiert ja den WebEntwickler nicht der auf derselben Maschine den Server laufen lässt auf dem er testet.
Ich bin aktuell ein großer Fan von React - damit kannst du "App-Feeling" erzeugen auf dem Smartphone.
Ben B. schrieb: > Halte ich für Quatsch, dann wäre GIF noch viel früher gestorben GIF Animationen schaltet auch jeder ab, der das erste Mal nervig zappelnde Werbung damit sah. Glücklichererise rutschen GIF aber nicht über die lesbare Seite oder schrecken auf wenn man mit der Maus drüberfährt. Mit HTML5 geht das natürlich auch alles wieder. Aber ein Browser ohne AdBlock ist noch immer praktisch unerträglich (gerade gestern zufällig die GMX Loginpage ohne Adblock gesehen. Um die selbst schon werbeverseuchte Seite oben und links und rechts drumrum nochmal Werbung. Die sind alle nicht ganz dicht.
Fruit schrieb: > Ganz ehrlich frag wo anders..hier wird Flash und Einsatz ohne > Frameworks > vorgeschlagen.. das zeugt nicht gerade von Expertise, wenn's tatsächlich > was ernsthaftes werden soll Klar! Denn "ernsthaft" bedeutet in erster Linie ja mal, dass man ganz viele Megabytes JS-Frameworks draufwirft, auch wenn die Webseite nur 3 Bilder und 7 Zeilen Text anzeigen soll. Denn so machen das alle anderen ernsthaften Leute ja auch!
Be B. schrieb: > Es ging mir mit einer Frage auch weniger darum wie man eine Webseite > programmiert. Was mich eigentlich interessiert ist wo der Trend > hostingtechnisch hingeht. Der Trend geht definitiv in Richtung Mikroservices in Containern. Mikroservice heißt dabei: Im Container steckt eine Anwendungsfunktion mit Ihrem kompletten Stack. Die Technologie ist dabei keine Top-Level Entscheidung mehr weil die Container voneinander unabhängig sein können und dementsprechend auch unterschiedliche Technologien verwenden können. Als "modern" würde ich derzeit hauptsächlich Python und Go sehen, im Enterprise Umfeld nach vie vor Java. LAMP ist aber noch sehr weit verbreitet. Wenn es um CMS geht würde ich heute auf Static Site Generatoren und Flat-CMS wie Grav setzen.
> Firefox kannst Du auch so langsam abhaken. Ein Tab Forum, ein Tab
Youtube, ein Tab Arbeit... schwupps 1..2GB RAM weg. Nimmt man noch
andere aufgebauschte Seiten wie Facebock oder ebay dazu, nächste 2..3GB
..
Die eine Maschine lasse ich jeweils nur hibernaten, laeuft also quasi
durch. Ich habe da etwas 250 Tabs offen, weil die Webseiten je an einer
Stelle stehen. Und das Ganze zieht dann vielleicht 24 GByte, permanent.
:
Bearbeitet durch User
Wozu braucht man 250 Tabs? Und wie will man da eine Übersicht behalten? Das klingt nach einer extrem chaotischen und ineffizienten Arbeitsweise.
Nun, ich kann bei firefox mit %xyz (das % macht's) den passenden Tab hervorholen.
Leider das falsche Forum. Aber mein Tip: https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor Läuft als WebAssembly nativ, kann in C# programmiert werden (frontend wie backend), keine Zeile javascript notwendig!. Nachteil: bleeding edge technology. Trotzdem setze ich gerade drauf und macht ziemlich Bock. Das Ganze natürlich skalierbar über Docker... LG jonas
>Der Trend geht definitiv in Richtung Mikroservices in Containern. >Mikroservice heißt dabei: Im Container steckt eine Anwendungsfunktion >mit Ihrem kompletten Stack. Die Technologie ist dabei keine Top-Level >Entscheidung mehr weil die Container voneinander unabhängig sein können >und dementsprechend auch unterschiedliche Technologien verwenden können. erst monolithische monster, dann dezentral als microservice, dann wieder die monster und ach was wird wohl als nächstes kommen?
Hört sich gut an schrieb: > Läuft als WebAssembly nativ, kann in C# programmiert werden (frontend > wie backend), keine Zeile javascript notwendig!. Nachteil: bleeding edge > technology. > > Trotzdem setze ich gerade drauf und macht ziemlich Bock. Das Ganze > natürlich skalierbar über Docker... Die Buzzword-Dichte hat jetzt fast 40% erreicht. Und welches Raumschiff-Cockpit kommt dabei später heraus? Ich bestreite gar nicht, dass all diese Technologien ihre Anwendungsbereiche haben. Nur werden für die meisten Webseiten viel zu viele davon eingesetzt ...
>Die Buzzword-Dichte hat jetzt fast 40% erreicht. Und welches >Raumschiff-Cockpit kommt dabei später heraus? Fühl dich halt nicht gleich abgehängt nur weil die Autos jetzt fliegen. Wer kein Javascript mag (ich), aber gerne Fullstack Entwicklung macht, mit C# lange arbeitet - für den könnte Blazor durchaus interressant sein
Ich fühle mich nicht abgehängt, ich fühle mich als ob der Bereich Web-Entwicklung krass in die falsche Richtung läuft und das nicht bemerkt. Es werden immer komplexere Stacks verwendet, um immer benutzerunfreundlichere, größere, langsamere und rundherum schlechtere Webseiten zu erstellen. Warum?
Die Qualität der Entwickler sinkt bei immer kürzeren Release-Zyklen bei immer krasseren Anforderungen. Welche Web-Technologien kennst du denn, ich meine nicht nur die Namen?
Ich mache selbst seit langer Zeit keine Webentwicklung mehr, bzw. nur noch kleinere Dinge -- die letzte Webseite, die ich gebaut habe, besteht aus einem 10-Zeilen-Shellskript mit sed-Befehlen das ein paar HTML-Dateien zusammenklebt, und 40 Zeilen JS das Bilder in einer klickbaren Galerie anzeigen kann. Früher habe ich mit PHP/MySQL gearbeitet, und einen Haufen HTML/CSS/JS (damals nocht mit JQuery) geschrieben. Das war jetzt natürlich auch nicht die Erleuchtung in Sachen Technologie-Stack. Aber es kommt halt auch sehr darauf an, was man eigentlich machen will. Dabei fällt mir vor allem auf, dass ein Haufen Dinge, die ich mir damals umständlich mit JS hinfrickeln musste, heute von selbst gehen oder mit einem kleinen CSS-Snippet lösbar sind. Insbesondere muss nicht jede Webseite eine vollumfängliche "Web-Anwendung" sein mit Client-Side HTML-Generator und blablabla. Brauchen einfach >95% der Seiten nicht -- und benutzen es trotzdem.
:
Bearbeitet durch User
Da hat sich aber schon was getan die letzten Jahre. Aber so Auswüchse wie wordpress etc. zeigen klar das noch Luft nach oben ist. Ich suche halt noch die Technologie die transparent von clientseitig über serverseitig bis spa alles abdeckt. blazor geht da schon in die richtige richtung meiner meinung nach und ich kann viel alten selbstentwickelten Code direkt benutzen. Ist ganz nice. ich mach nu feiereabend -> schönes weekend.
Hört sich gut an schrieb: > Fühl dich halt nicht gleich abgehängt Ja, nicht nur ich. Ich kenne eigentlich niemanden, der beim Web das Wort 'funktioniert' verwendet. Nur grösserer und kleinerer Krampf und Trickkistengriffe um doch noch irgendwie die gewünschten Informationen herauszuholen. Die meisten haben 2-3 Browser auf ihren Endgeräten, um die paar (viele haben sich massiv eingeschränkt welche Seiten sie überhaupt noch besuchen, und bei den meisten werden es ständig weniger wenn noch ein Anbieter eine Bezahlschranke hochzieht, schliesslich hag man sich früher auch nicht 50 Tageszeitungen bezahlt und liefern lassen) WebSites besuchen zu können. Und verzichten auf Geräte wie 'Drucker' weil sie sowieso nicht mehr druckbar sind. Der Scheiss aus der Scrum Entwicklung wird halt immer schlechter. Ja, 7 von 10 Bekannten nutzen noch Win7, 8 von 10 haben Smartphones für die der Hersteller kein Update mehr liefert. Die Leute habrn nämlich keinen BOCK alle 2 Jahre alles neu kaufen zu sollen, wie es die Nerds tun die die Scheiss Webseiten erstellen.
Aktuell habe ich im FF 11 Tabs offen, lt. Taskmanager 2 GB Speicher veraast. Ich denke, Frameworks braucht man nicht. Es geht einfach nicht ohne sattelfeste Kenntnisse in HTML/CSS, dazu eine Prise JavaScript. Je weniger Code dest besser werden die Ladezeiten.
Hört sich gut an schrieb: > Ich suche > halt noch die Technologie die transparent von clientseitig über > serverseitig bis spa alles abdeckt. blazor geht da schon in die richtige > richtung meiner meinung nach und ich kann viel alten selbstentwickelten > Code direkt benutzen. Ich verstehe halt nicht so recht wozu das immer gut sein soll. Server- und Clientseite machen doch ohnehin völlig unterschiedliche Dinge. Hier Code wiederzuverwenden beschränkt sich ohnehin auf wenige Spezialgebiete (z.B. Formular-Validierung), die man auch anders abstrahieren kann. Was ist dann der Punkt? Dass man keine zwei verschiedenen Sprachen braucht?
Be B. schrieb: > Ich plane mich mal wieder mit Web Programmierung zu beschäftigen. > Bisher war mein Plan eigentlich Play 2/Java zu verwenden (ist aber schon > ein paar Jahre her). > > Nun habe ich aber gelesen, daß in der Zwischenzeit Contaier (Docker?) > wohl sehr beliebt sind, da die, wenn sie einmal fertig sind, sich leicht > bei unterschiedlichen Anbietern hosten lassen. Container sollen ja auch > resourcenschonender als ein virtualles Linux + Java Installation sein. > > Auch würde ich lieber C# als Java verwenden, was ohne Container wohl > eher selten als Hosting Platform unter Linux angeboten wird. In einem > Container wäre es dann ja wohl egal ob ich Java oder C# verwende. > > Hat jemand einen Tip welche Route man heute einschlagen sollte? Wichtig > wäre mir, daß ich später leicht den Hoster wechseln kann, ohne etwas an > der Webseite ändern zu müssen oder gar das Framework/Sprache wechseln zu > müssen. Wie wär's damit: https://getgrav.org/ ...Rolf
Christoph S. schrieb: > Ich bin aktuell ein großer Fan von React Ich hab letztes Jahr ein bisschen mit vue.js rumgespielt (gleiches Prinzip wie React). Extrem geil eigentlich, die Idee, das Konzept, die Möglichkeiten, die Leichtigkeit mit der man da Sachen machen kann an denen man sich sonst nen Wolf programmiert hätte. Aber was mich extremst wurmt ist daß man um es zu benutzen sich das halbe node-js Universum reinziehen muss und in dem Jahr in dem ich an der Seite rumgebastelt habe gab es mehrere updates in dem ganzen node-Gestrüpp bei denen mir der Buildvorgang kaputtgegangen ist und ich wieder stundenlang rumgoogeln musste wie ich den vollkommen undurchsichtigen Scherbenhaufen jetzt konfigurieren muss daß es wieder rennt, das erzeugt kein gutes Gefühl, man verliert völlig die Kontrolle über alles. Wenn man solche fortschrittlichen Frameworks wie Vue oder React nutzen könnte ohne sich auf dem Entwicklungsrechner den ganzen absurden Node-Rotz reinziehen zu müssen wär das ne feine Sache. Ansonsten macht das nämlich auf Dauer keinen Spaß.
:
Bearbeitet durch User
Fruit schrieb: > Ganz ehrlich frag wo anders..hier wird Flash Das war tatsächlich Quatsch. > und Einsatz ohne Frameworks vorgeschlagen.. Du weißt doch nichtmal, wozu Frameworks überhaupt gut sind. Abgesehen davon sind statische Seitengeneratoren schwer im Kommen, sowohl wegen Sicherheit als auch Performance. Stichwort JAM-Stack, sagt Dir natürlich auch nichts. Und obendrein kann man natürlich auch Vue mit statischen Seiten einsetzen. Aber laß Dir halt von "Profis" viel Geld für eine Webseite aus der Tasche ziehen, die lediglich ein Template für das rottige WordPress ist. Weil's voll ernsthaft ist und so.
Horst schrieb: > Wer C# auf einen Server packt, der hat es nicht besser verdient, wenn > die Seite gehackt wird. Wieso, sind Java/PHP/Ruby Frameworks sicherer?
Ja, sicher. Zumindest php selbst. Man sollte schon schauen, ob man nicht zuviel Schrott verwendet, nur weil's glänzig ist.
Schon interessant, welch Diskussion man mit einer einfachen Frage auslösen kann ;-) Hat vielleicht noch jemand einen Vorschlag, wie man ein Bezahlsystem in eine Website integriert?
Wenn du ein statisches Angebot von Artikeln hast, reicht eine primitive Internetseite mit Links zu einem Dienstleister der die Bezahlabwicklung / MWSt Abführung regelt. Willst zu mehr als nur PayPal, bietet sich z.B. dieser an: https://www.mycommerce.de/ Beim mittleren Preismodel verlangt der Dienstleister rund 9% aber dafür hat man keine Probleme mit den verschiedenen MWSt Sätzen der Kunden aus verschiedenen Ländern.
Der guenstigere Ansatz ist die Bezahlabwicklung in php gemaess den Anforderungen des Finanzdienstleisters zu integrieren.
> Hat vielleicht noch jemand einen Vorschlag, > wie man ein Bezahlsystem in eine Website integriert? Einfach jeden freundlichen Benutzer möglichst benutzerunfreundlich dazu zwingen, sich erstmal drei (bei erkannten Adblock-Rebellen mindestens fünf) Werbevideos mit Ton und in voller Länge anzuschauen, bevor er irgendwas auf der Seite sehen darf. Möglichst aber erstmal nicht das, was er sehen wollte - das steigert die Verweildauer, vor allem weil bis dahin sein 5GB-Highspeed-Volumen aufgebraucht ist. Wenn er dazu noch 20 pauschale Hinweise auf Cookies und Datenschutz wegklicken oder diesen zustimmen muß, ist das Interneterlebnis auf Deiner Seite durch nichts zu übertreffen und die Werbeeinnahmen finanzieren Dir locker Dein Schloss am See. SCNR
:
Bearbeitet durch User
Vergiss nicht die "Notifications"! Möglichst mit den zwei Buttons "Zulassen" und "Allow"! Gruss Chregu
Joachim D. schrieb: > Aktuell habe ich im FF 11 Tabs offen, lt. Taskmanager 2 GB > Speicher veraast. > > Ich denke, Frameworks braucht man nicht. Es geht einfach nicht > ohne sattelfeste Kenntnisse in HTML/CSS, dazu eine Prise JavaScript. > > Je weniger Code dest besser werden die Ladezeiten. Nunja, also ich habe hier 16 Seiten in Chrome offen, davon einmal Youtube und einige WordPress Instanzen. Der zieht gerade mal ~600MB.
Name H. schrieb: > Ich habe da etwas 250 Tabs offen, Ich nicht, aber ich werde manchmal zur Hilfe gerufen, weil der Computer nicht mehr reagiert wenn man Firefox startet. Es stellt sich dann heraus, daß Firefox versucht hunderte Seiten zu öffnen, wohl weil irgendein Werbskript mal irre lief oder man immer wieder auf ein vermeintlich nicht funktionierendes aber langsam reagierendes Element klickte, und das Programm nachdem der Speicher restlos voll war abstürzte, und dann ist FireFox SO DÄMLICH, DAS BEI JEDEM START ERNEUT zu öffnen. Da stehen dann die Normalanwender hilflos davor.
Ich verstehe die Frage nicht wirklich ... Wenn die Webseite extrem individuell sein muss, kommt man um HTML5, JS und CSS nicht herum. Soll sie einfach nur funktionieren, nimmt man ein CMS, z.B. Joomla, Drupal, Wordpress ... Wo ist das Problem?
Sheeva P. schrieb: > DPA schrieb: > Naje, docker ist auch nur unter Linux wirklich brauchbar. > > Das ist nicht richtig. Selbst da nicht wirklich brauchbar :^)
Bestes Konzept? EINFACH + Inhalt vor Firlefanz. Punkt.
Jemand schrieb: > Sheeva P. schrieb: >> DPA schrieb: >> Naje, docker ist auch nur unter Linux wirklich brauchbar. >> >> Das ist nicht richtig. > > Selbst da nicht wirklich brauchbar :^) Docker ist auch für andere Sachen brauchbar und nützlich. Zum Beispiel ist mir vor ein oder zwei Jahren mal ein build-script untergekommen welches Docker verwendete um eine nicht triviale Umgebung mit qemu, binfmt-misc, arm-gcc und tools und allerlei anderen sehr speziellen Abhängigkeiten hochzuziehen und im nächsten Schritt dann dann innerhalb dieser Umgebung das ganze Kernelpaket für ein Board mit ner Rockchip-ARM-CPU zu bauen. Das ganze ging vollautomatisch und fehlerfrei und ohne vorher stundenlang zu versuchen 2 Dutzend Pakete mit hochspeziellem und möglicherweise konfliktbehaftetem Cross-Tool-Firlefanz auf meinem Arbeitsrechner zu installieren und zu hinterlassen. Das fand ich sehr beeindruckend und auch inspirierend, diese Art von Docker-Nutzung kann einiges an Arbeit und Nerven sparen und ermöglicht es mit ein paar Zeilen Script eine bis aufs letzte Bit genau definierte Build-Umgebung schriftlich zu definieren, zu verteilen, zu archivieren um komplexe Softwareprojekte wiederholbar überall bauen zu können. Derjenige der das dann nutzen will muss nur Docker und Bash installiert haben als einzige Abhängigkeiten und kann dann damit alles bauen ohne auch nur eine einzige Konfiguration an seinem System zu verändern. Ich hab mir das letztes Jahr dann selbst zunutze gemacht um den bitbake-Build eines kompletten bootfähigen Linux-Image mitsamt meiner eigenen Anwendung für ein Toradex-Modul zu wrappen, jetzt muss man nur noch auf einem beliebigen Linux-Rechner das Repository auschecken, das Build-Script starten, ein paar Stunden warten und es fällt die fertige bootfähige .img-Datei raus, bitidentisch wiederholbar und vollkommen idiotensicher.
Einerseits ja, andererseits nimmt starke Nutzung dieser Container-Variante halt auch den Leidensdruck weg, das Deployment von dem Kram so zu fixen dass es halt relativ einfach auch tut. Unter Windows ist es z.B. der ultimative Schmerz einen C++-Compiler zu erhalten, mit dem man gegen 3 verbreitete Libs linken kann. Unter Linux ist das viel einfacher, weil eben nicht alles in einem großen Blob-Installer ist.
Bernd K. schrieb: > Docker ist auch für andere Sachen brauchbar und nützlich. Du hast Docker genauso benutzt wie es für deinen Anwendungsfall vorgesehen war ;) Unglaublich, verwendet man ein Tool für den vorgesehen Zweck tut es meistens auch das was man will :-)
Be B. schrieb: > Ich plane mich mal wieder mit Web Programmierung zu beschäftigen. > Bisher war mein Plan eigentlich Play 2/Java zu verwenden (ist aber schon > ein paar Jahre her). > > Nun habe ich aber gelesen, daß in der Zwischenzeit Contaier (Docker?) > wohl sehr beliebt sind, da die, wenn sie einmal fertig sind, sich leicht > bei unterschiedlichen Anbietern hosten lassen. Container sollen ja auch > resourcenschonender als ein virtualles Linux + Java Installation sein. Das ist absolut korrekt. Einen Docker-Container kannst Du bei etlichen Hostern, aber auch bei vielen darauf spezialisierten Anbietern (zB Google GCP, Amazon AWS, Microsoft Azure) und in etlichen Umgebungen (zB Kubernetes oder Apache Mesos) betreiben, aber auch auf jedem Linux-Rootserver, jedem handelsüblichen Linux, Windows, oder MacOS (bei den letzten beiden jedoch in einer transparenten Linux-VM, von der Du normalerweise nichts siehst). Container sind auch wesentlich ressourcenschonender als VMs, weil sie den Kernel und die Dienste des Hosts verwenden, anstatt jeweils einen eigenen Kernel nebst Kernelthreads, Initprozeß und Systemdiensten zu starten. > Auch würde ich lieber C# als Java verwenden, was ohne Container wohl > eher selten als Hosting Platform unter Linux angeboten wird. In einem > Container wäre es dann ja wohl egal ob ich Java oder C# verwende. Bei Webentwicklern sind Skriptsprachen sehr beliebt, das senkt den Aufwand für die Entwicklung ganz erheblich. Moderne Skriptsprachen wie Python und Ruby liefern mit Django, Flask und Ruby on Rails äußerst leistungsfähige Web-Frameworks. > Hat jemand einen Tip welche Route man heute einschlagen sollte? Wichtig > wäre mir, daß ich später leicht den Hoster wechseln kann, ohne etwas an > der Webseite ändern zu müssen oder gar das Framework/Sprache wechseln zu > müssen. Nun, letztendlich spiegeln solche Empfehlungen natürlich immer auch die Vorlieben und Abneigungen des Empfehlenden wider, weswegen dieser Thread leider stellenweise in eine "Ich hab' den Größten"-"Debatte" abgleitet. Deswegen möchte ich mich zurückhalten und nur meine Lösung für solche Aufgaben vorstellen. Meine Lösung basiert auf der aktuell (aus guten Gründen) beliebtesten und verbreitetsten Skriptsprache Python und nutzt das Microwebframework Flask sowie einen Apache-Webserver. Allerdings will ich natürlich auch darauf hinweisen, daß dies nur einer unter vielen Wegen ist, die nach Rom führen. Die Struktur der Webapp sieht wie folgt aus: docker-webapp ├── Dockerfile └── files ├── apache │ ├── apache2.conf │ └── example.com.conf └── web ├── requirements.txt ├── templates │ ├── _base_.html │ └── index.html ├── web.py └── web.wsgi Das Dockerfile ist die Datei, die das Erstellen eines Docker-Image steuert. Die Dateien im Ordner files/apache/ enthalten die Konfigurationsdateien für den Apache-Webserver. Die Datei files/web/web.py ist die eigentliche Webapplikation, hier werden die URLs (im Beispiel: '/') auf Funktionen (hier: index()) gemappt; dabei lädt render_template() das angegebene Template aus dem Unterverzeichnis templates/ (also: files(web/templates/) und setzt die hier übergebenen Variablen ein. Im Beispiel sind das statische Werte. Die Datei files/web/web.wsgi ist der Loader für mod_wsgi, die Datei files/web/requirements.txt enthält eine Liste von Python-Modulen, die für den Betrieb der Applikation benötigt werden. Bei den Templates gibt es eine kleine Besonderheit, sie nutzen ein Feature der Template-Engine, das deren Entwickler als Vererbung bezeichnen. Hier gibt es ein Basis-Template in files/web/templates/, das den HTML-Rahmen für alle Seiten der Applikation definiert und benannte Blöcke auszeichnet, die von den Kind-Templates (hier: files/web/templates/index.html) dann mit Inhalten überschrieben werden. Dadurch erhalten alle Seiten der Webpage ein konsistentes Aussehen und eine durchgängige Struktur. Um aus dem Beispiel ein lauffähiges Docker-Image mit dem Namen example_com zu erzeugen, nutze ich im Wurzelverzeichnis docker-webapp/ folgenden Befehl: $ docker build --tag example_com . Um aus diesem Image einen laufenden Container namens example_com_1 zu erzeugen und dessen internen Port 80 auf den externen Port 5556 zu mappen, verwende ich den Befehl $ docker create --name example_com_1 --publish 5556:80 example_com und um den Container dann zu starten $ docker start example_com_1 Selbstverständlich ist das nur ein ganz einfaches Beispiel. Auf meinem alten Q9650 bedient dieser Container laut dem Benchmark-Programm ab(1) 10.000 Requests bei einer Concurrency von 15 in 5,081 Sekunden, davon werden 99% der Requests in 24 ms beantwortet und der längste Request benötigt 56 ms. Für eine private Seite ist das sicher ausreichend.
Jemand schrieb: > Sheeva P. schrieb: >> DPA schrieb: >> Naje, docker ist auch nur unter Linux wirklich brauchbar. >> >> Das ist nicht richtig. > > Selbst da nicht wirklich brauchbar :^) Wenn man ein bisschen Ahnung hat, ist das eine tolle Sache. Schade, daß es bei Dir nicht funktioniert.
Sheeva P. schrieb: > Jemand schrieb: > Sheeva P. schrieb: > DPA schrieb: > Naje, docker ist auch nur unter Linux wirklich brauchbar. > > Das ist nicht richtig. > > Selbst da nicht wirklich brauchbar :^) > > Wenn man ein bisschen Ahnung hat, ist das eine tolle Sache. Schade, daß > es bei Dir nicht funktioniert. Wenn ich beim ersten Versuch irgendwelche bekloppten Fehler bekomme, die am Ende auf die Nichtunterstützung von cgroup v2 zurückzuführen ist, fliegt das Ding halt wieder vom Rechner und macht Platz für eine funktionierende Lösung (LXD/LXC). Sich gleich am Anfang durch Bugtracker wühlen zu müssen ist schwach.
Jemand schrieb: > Wenn ich beim ersten Versuch irgendwelche bekloppten Fehler bekomme, die > am Ende auf die Nichtunterstützung von cgroup v2 zurückzuführen ist, > fliegt das Ding halt wieder vom Rechner und macht Platz für eine > funktionierende Lösung (LXD/LXC). Sich gleich am Anfang durch Bugtracker > wühlen zu müssen ist schwach. Jo. Auf meinem Rechner musste ich die letzten 2 Male wo ich Docker verwenden wollte auch zwei völlig bescheuerte Dinge tun, damit das läuft (einmal musste man irgendeinen Kernel-Command-Line-Parameter ändern im Bootloader, und einmal musste ich das MTU von meinem WLAN-Interface auf 600 ändern (sic!)). Natürlich war beides mit 1h+ Wühlen in irgendwelchen Mailing-List-Archiven verbunden, um das rauszufinden. Docker wirkt definitiv wie Software, die in ihrer Komplexität ertrinkt.
:
Bearbeitet durch User
Zum totlachen die ganzen Docker-Hasser. Hier und auch anderswo. Frei nach dem Motto: "Ich weiß nicht wofür es gut ist, ich brauchs nicht also muss es Scheiße sein. Sonst ist mein Weltbild ja im Arsch."
Jemand schrieb: > Wenn ich beim ersten Versuch irgendwelche bekloppten Fehler bekomme, die > am Ende auf die Nichtunterstützung von cgroup v2 zurückzuführen ist, Wenn Du einen Kernel von vor 2015 benutzt, ist es nicht die Fehlermeldung, die bekloppt ist. Und sogar unser Azubi hat es mit seinen gewaltigen zwei Wochen Linux-Erfahrung hinbekommen, Docker nach der Installationsanleitung aus der Dokumentation von docker.io zu installieren.
Sven B. schrieb: > Jo. Auf meinem Rechner musste ich die letzten 2 Male wo ich Docker > verwenden wollte auch zwei völlig bescheuerte Dinge tun, damit das läuft > (einmal musste man irgendeinen Kernel-Command-Line-Parameter ändern im > Bootloader, und einmal musste ich das MTU von meinem WLAN-Interface auf > 600 ändern (sic!)). Natürlich war beides mit 1h+ Wühlen in irgendwelchen > Mailing-List-Archiven verbunden, um das rauszufinden. Sehr seltsam, so etwas habe ich noch nie gehört. Hättest Du vielleicht einen Link für mich und könntest mir womöglich sagen, welchen Kernelparameter Du konfigurieren mußtest? > Docker wirkt definitiv wie Software, die in ihrer Komplexität ertrinkt. Ach, in ihrer Frühphase vor drei, vier Jahren hatte Docker noch ein paar kleinere Kinderkrankheiten. Die sind mittlerweile größtenteils aussortiert. Mir fehlen an ein paar Stellen noch Funktionen (etwa docker cp für Volumes) und bisher ist das Usermapping noch nicht wirklich komfortabel, aber das tut dem Gesamtpaket nun wirklich keinen Abbruch.
Uff, das ist ungefähr 2 Jahre her, das weiß ich nicht mehr. Ich glaube es hatte irgendwas mit den cgroups zu tun. Kann sein dass es um die v1/v2-Unterscheidung ging oder so, die damals noch nicht Standard war. Drei Jahre alt war mein Kernel aber keinesfalls, der war ziemlich aktuell. > "Ich weiß nicht wofür es gut ist, ich brauchs nicht also > muss es Scheiße sein. Sonst ist mein Weltbild ja im Arsch." Ich habe Docker schon an mehreren Stellen eingesetzt und es ist für manche Dinge auch durchaus keine schlechte Technologie. Ich kritisiere eher, dass es von manchen inflationär für jeden Mist benutzt wird. Den Vorwurf kehre ich mal um: du bist ein Fanboy, der keine Kritik an seiner Lieblings-Software abkann ;)
Sheeva P. schrieb: > Wenn Du einen Kernel von vor 2015 benutzt, ist es nicht die > Fehlermeldung, die bekloppt ist. Nicht mein Kernel sondern Docker unterstützt cgroup v2 nicht. Immerhin scheinen sie den Knall gehört zu haben und kümmern sich endlich darum, jetzt wo Fedora den Wechsel macht.
Eine Webseite muss schnell sein, darf keinen Ballast besitzen und vom der Größe her minimal sein. Alles inklusive. HTML pur ist das Stichwort! Leider erfüllen 99,99 % aller Webseiten diese Kriterien nicht. Vermeide Datenmuell und unnötige Datentransfers. Und schon hast du die beste Webseite aller Webseiten entwickelt.
Notstallgier schrieb: > Bestes Konzept? > > EINFACH + Inhalt vor Firlefanz. Pah, das ist total OUT und UNCOOL.
Ach was, ist immer wieder lustig wieviele Webseiten sich mit einem Steinchen auf der F5-Taste DOSen oder zum Crashen bringen lassen...
Sven B. schrieb: > Uff, das ist ungefähr 2 Jahre her, das weiß ich nicht mehr. Ich glaube > es hatte irgendwas mit den cgroups zu tun. Kann sein dass es um die > v1/v2-Unterscheidung ging oder so, die damals noch nicht Standard war. > Drei Jahre alt war mein Kernel aber keinesfalls, der war ziemlich > aktuell. Naja, schade, das hätte ich wirklich zu gerne genauer gewußt. Aber wenn das zwei Jahre her ist, dürfte der heutige Nutzwert ohnehin nahe Null sein. Ganz besonders wundert mich jedoch, daß Du die MTU Deines WLAN-Interface bearbeiten mußtest. Wie das? Docker fummelt nicht im Netzwerkstack Deines OS herum, sondern arbeitet nur mit Controlgroups, Namespaces, dem Routing und dem Paketfilter des Hostkernels... warum sollte das die MTU anpassen wollen? Erschwerend kommt da hinzu, daß die Netzwerkstacks von Linux und nahezu allen anderen modernen Betriebssystemen eine Technik beherrschen, welche sich Path Maximum Transmission Unit Discovery (Path MTU Discovery oder PMTUD) nennt. Dabei wird über ein ICMP-Paket mit IIRC Typ 3 Code 4 signalisiert, daß die MTU überschritten wurde und das Don't Fragment Bit (DF) im Header gesetzt ist. Wenn Dein Betriebssystem solche Pakete nicht korrekt verarbeitet, oder Dein Firewall / Paketfilter sie filtert, dann sind entweder Dein Betriebssystem, Dein Firewall oder Dein Paketfilter entweder kaputt oder falsch konfiguriert... Das kann natürlich auch an Docker liegen, klar, erscheint mir aber unwahrscheinlich... > Ich habe Docker schon an mehreren Stellen eingesetzt und es ist für > manche Dinge auch durchaus keine schlechte Technologie. Ich kritisiere > eher, dass es von manchen inflationär für jeden Mist benutzt wird. Hättest Du vielleicht ein Beispiel? > Den Vorwurf kehre ich mal um: du bist ein Fanboy, der keine Kritik an > seiner Lieblings-Software abkann ;) ;-) Mit fundierter Sachkritik kann ich hervorragend leben, und wenn Du genau darauf achtest, äußere ich ja selbst welche. Aber Dein vorheriger Beitrag las sich leider sehr ähnlich wie viele der üblichen "ich habe einen Fehler gehabt, also ist die Software doof"-Tiraden, und das ist sie, objektiv betrachtet, nicht. Im Gegenteil löst sie viele Probleme, wegen derer wir früher fiese Verrenkungen machen mußten, sehr elegant und effizient. Um nur ein Beispiel aus meiner persönlichen Praxis zu nennen: früher habe ich unsere Software mit Ansible-Playbooks von insgesamt 704 Zeilen gebaut und ausgerollt, heute habe ich dafür ein Dockerfile, ein Ansible-Playbook und eine docker-compose.yml mit zusammen 55 Zeilen. Dabei haben wir die Möglichkeiten, die Docker für unseren Workflow bietet, noch nicht einmal ausgenutzt, denn aktuell baue ich die Software und die Docker-Images noch selbst. Künftig sollen die Entwickler die Images bauen, diese durchlaufen dann unsere QA, werden im Erfolgsfall in eine zentrale Registry gepusht, und dadurch reduziert sich mein Aufwand auf höchstens 25 Zeilen. Und auch sonst hilft mir Docker bei vielem: wenn ich auf meinem Kubuntu 18.04 LTS einmal einen flammneuen Compiler, eins meiner Pythonskripte mit der neuesten Python-Version testen, oder Google Chrome nutzen will: Kein Problem, mein System bleibt unberührt und stabil. Eine Software gegen ein aktuelles Oracle-, MSSQL- oder DB2-RDBMS testen? Kein Thema: Composedatei schreiben, laufen lassen, fertig. Ja, ich mag das Zeug, weil es mir die Arbeit vereinfacht, langwierige und fehleranfällige Aufgaben wegautomatisiert, und ich mich nicht mehr manuell um verschiedene Startskripte, Unitfiles, Paketierungen, Paketrepositories, und den ganzen repetitiven Boilerplate-Quatsch kümmern muß. Ja, nenn' mich meinethalben einen Fänboi, aber... ich finde das super. ;-)
Jemand schrieb: > Nicht mein Kernel sondern Docker unterstützt cgroup v2 nicht. Immerhin > scheinen sie den Knall gehört zu haben und kümmern sich endlich darum, > jetzt wo Fedora den Wechsel macht. Leider ist cgroups v2 bisher noch nicht in der Lage, cgroups v1 zu ersetzen, darüber hinaus können beide Versionen parallel genutzt werden -- siehe dazu auch [1]. Bitte entschuldige, aber was war Dein Problem? [1] http://man7.org/linux/man-pages/man7/cgroups.7.html
:
Bearbeitet durch User
Oioioi schrieb: > Eine Webseite muss schnell sein, darf keinen Ballast besitzen und vom > der Größe her minimal sein. Alles inklusive. HTML pur ist das Stichwort! > Leider erfüllen 99,99 % aller Webseiten diese Kriterien nicht. Vermeide > Datenmuell und unnötige Datentransfers. > > Und schon hast du die beste Webseite aller Webseiten entwickelt. Daß viele Websites heutzutage §$%&!/%$&-langsam sind, liegt häufig an den Websites selbst, das ist richtig. Dutzende bis hunderte Artefakte mit CSS, JavaScript etc., drölfundneunzigtausend Bilder, klar, das kostet. Aber auf der anderen Seite läßt sich so viel Rechenlast von der Server- auf die Clientseite übertragen, was manche modernen Seiten tatsächlich zu einer Art "Distributed Computing" macht. Viele Webseiten benötigen aber dynamische Komponenten, sei es für Logins für Benutzer oder für benutzergenerierte Inhalte wie Kommentare. Sowas kann man mit HTML-Generatoren nicht wirklich abbilden. Man braucht dann einen mehr oder weniger dynamischen Datenspeicher. Jedoch sehe ich sehr oft auch noch ein anderes Problem: viele Webentwickler kennen als dynamischen Datenspeicher nicht mehr als relationale Datenbanken (RDBMS) wie MySQL oder PostgreSQL. Diese bieten aber verschiedene Features, die für die überwiegende Mehrzahl der Webseiteninhalte überflüssig sind und dadurch im Endeffekt einen hohen Verbrauch an Ressourcen und eine schlechte Performance verursachen. Moderne Datenspeichersysteme wie Elasticsearch, MongoDB, CouchDB oder gar In-Memory-Datenbanken wie Redis oder Aerospike haben diese Probleme nicht -- und bieten meistens beeindruckende Features, die sich mit klassischen Datenbanken nicht oder nur sehr schlecht abbilden lassen. Und sie sind unfaßbar schnell, weil sie weder relationale noch Transaktionssicherheit bieten... und obendrein lassen sich solche Systeme üblicherweise leicht horizontal über Sharding und Replikation skalieren. Meine Webapplikationen nutzen relationale Datenbanksysteme wie PostgreSQL mittlerweile nur noch für relationale Daten wie Benutzer, die ja meistens mit einer Gruppe und / oder bestimmten Privilegien versehen sein müssen. Für alles, das keine relationale noch transaktionale Sicherheit benötigt, benutze ich mittlerweile Elasticsearch als Speichermedium, und Redis für Echtzeitdaten, Message Queues, ... Damit lassen sich auch sehr schnelle dynamische Webseiten darstellen, die "normale" Benutzer nicht von statisch generierten unterscheiden können. Denn am Ende befindet sich der Flaschenhals ja meistens entweder beim Netzwerk, beim RDBMS oder auf der Benutzerseite... YMMV. ;-)
Wie wäre es mit einer schlichten Homepage? Mein Internetauftritt ist ganz schlicht gehalten (keine Cookies, keine Werbung, keine übertrieben Inhalte, keine Verbindung zu externen Servern, keine Datenbanken, kein Blinker-Glitzer-Glimmer). Meine Frameworks habe ich anfertigen lassen. Dafür muss ich zwar neue Seiten manuell einbinden, aber ich baue extrem selten neue Seiten ein.
René H. schrieb: > Mein Internetauftritt ist ganz schlicht gehalten [...] Und deswegen muß jede andere Website "schlicht gehalten" sein? Sorry, Deine Einlassung ist so... die Frage war, "wie kann ich in einem Formel1-Rennen mitfahren" und Du sagst "zum Einkaufen reicht mir ein Einkaufswagen". Und die bisherigen Beiträge hast Du wahlweise nicht gelesen oder nicht verstanden.
Weiter oben schrieb jemand "EINFACH + Inhalt vor Firlefanz".
René H. schrieb: > Weiter oben schrieb jemand "EINFACH + Inhalt vor Firlefanz". Daß auch andere Menschen idiotische Dinge schreiben, macht Deine nicht intelligenter. Ich rede nicht von Firlefanz, sonder über Dynamik.
Sheeva P. schrieb: > Ganz besonders wundert mich jedoch, daß Du die MTU Deines WLAN-Interface > bearbeiten mußtest. Wie das? Docker fummelt nicht im Netzwerkstack > Deines OS herum, sondern arbeitet nur mit Controlgroups, Namespaces, dem > Routing und dem Paketfilter des Hostkernels... warum sollte das die MTU > anpassen wollen? Weiß ich nicht. Ich habe das auch überhaupt nicht erwartet. Es war aber definitiv das Problem, und ich bin auch definitiv nicht der einzige, wenn man googelt findet man (jetzt, damals war das schwer zu finden) hunderte Reports, z.B. https://github.com/moby/moby/issues/22585 Kann auch gut sein dass Docker hier nicht Schuld ist, sondern nur irgendetwas merkwürdiges tut, was sonst keiner macht. Die Tatsache, dass du so verblüfft davon bist (bin ich auch), dass das überhaupt ein Problem sein kann, illustriert aber gut meinen Punkt. > Hättest Du vielleicht ein Beispiel? Ich habe zum Beispiel mal einen CentOS 6-Container gebaut, in dem unsere Anwendung und all ihre Abhängigkeiten kompiliert wurden, um die dann in ein tar-Archiv zu packen, gegen eine alte glibc (von CentOS 6 eben) gelinkt. Das hat eigentlich gut funktioniert, obwohl das Build-Setup ziemlich komplex ist. Vor allem klappt das auch 2 Jahre später noch ohne allzuviel Schmerz. > Ja, nenn' mich meinethalben einen Fänboi, aber... ich finde das super. ;-) Das war ja nicht an dich gerichtet, ich hatte den unsachlichen Beitrag des anonymen Posters zitiert ;) Gegen den Einsatz von Containern an sich habe ich wie gesagt überhaupt nichts. Sie können sicherlich gewinnbringende Technologie sein. Mein Ziel in diesem Thread war aber von Anfang an, den TO vor unnötiger Komplexität zu warnen. Der TO hat offensichtlich wenig Überblick über das Thema, hat gelesen dass Docker-Images hip sind, und überlegt jetzt, ob er das deshalb für seine unspezifische Webseite verwenden sollte. Ohne ein klares Problem zu haben, was er damit lösen möchte. Das ist m.E. kein sinnvolles Vorgehen, weil es einfach nur zusätzliche Komplexität einführt, die im Zweifel schwer zu debuggen ist. Um dazu noch ein anderes Beispiel aus meinem Alltag zu nennen: hier kompiliere ich auch gerade öfters Dinge in einem Docker-Container. Dabei habe ich das Problem, dass unter hoher Last I/O-stalls auftreten, also weder der Container noch das Host-System schaffen es für 3 Sekunden auch nur ein stat auf irgendeine Datei zu machen. Kompiliert man auf dem Host-System, passiert das bei gleicher Last nicht. Ich habe hier wieder keine Ahnung, wie ich herausfinden soll, was das Problem ist.
Hab nicht alles gelesen... Aber wurde Blazor schon genannt? Html und c# Code in einer Seite... Läuft unter Linux, Mac und Windows... Unter https://blazor.net gibt's ein Beispiel das alles enthält was man braucht... Ausserdem gibt's ein tutorial.
Braucht man sich im europäischen Raum, mit europäischen Server eh gerade keine Gedanken darüber machen - gibt nun eh keine IPv4 Adressen mehr. ? Darüber mal abgesehen: die meiste Datennutzung im Web kommt durch Mediastreaming (Video, Audio) da machen die paar WordPress Seiten den Speck auch nicht weg. Übrigens kann man sich seine Templates auch da extrem Schlank halten. Sodas auch dort kaum Latenz und *bling*bling* ist.
Sven B. schrieb: > Gegen den Einsatz von Containern an sich habe ich wie gesagt überhaupt > nichts. Sie können sicherlich gewinnbringende Technologie sein. Mein > Ziel in diesem Thread war aber von Anfang an, den TO vor unnötiger > Komplexität zu warnen. Der TO hat offensichtlich wenig Überblick über > das Thema, hat gelesen dass Docker-Images hip sind, und überlegt jetzt, > ob er das deshalb für seine unspezifische Webseite verwenden sollte. > Ohne ein klares Problem zu haben, was er damit lösen möchte. Das ist > m.E. kein sinnvolles Vorgehen, weil es einfach nur zusätzliche > Komplexität einführt, die im Zweifel schwer zu debuggen ist. Naja, der TO erwähnt in seinem Eingangspost gleich zweimal, daß er die Seite möglichst technologie-unabhängig halten, und sich nicht an einen spezifischen Anbieter binden wolle. Ich nehme auch an, daß die Website etwas Dynamisches machen soll -- zumindest deutet die Frage nach einer bestimmten Programmiersprache IMHO darauf hin, denn für eine statische Seite hätte statisches HTML natürlich völlig gereicht. Für genau solche Szenarien ist Docker ziemlich gut geeignet, es läuft überall und erfüllt damit den Punkt Plattform- und Anbieterunabhängigkeit besser als alle anderen mir bekannten Möglichkeiten. Nebenbei bemerkt verstehe ich natürlich, daß Du den Fragenden vor einer Komplexität warnen möchtest. Aber einem Entwickler ist sicher klar, daß diese Container-Sache zwar eine gewisse Lernhürde ist -- Wer sollte das besser wissen als ein Entwickler? ;-) -- , und wir beide wissen, daß das vor allem für diesen einfachen Anwendungsfall nun auch nicht so überaus kompliziert ist, daß ein Entwickler das nicht schnell lernen kann. > Um dazu noch ein anderes Beispiel aus meinem Alltag zu nennen: hier > kompiliere ich auch gerade öfters Dinge in einem Docker-Container. Dabei > habe ich das Problem, dass unter hoher Last I/O-stalls auftreten, also > weder der Container noch das Host-System schaffen es für 3 Sekunden auch > nur ein stat auf irgendeine Datei zu machen. Kompiliert man auf dem > Host-System, passiert das bei gleicher Last nicht. Ich habe hier wieder > keine Ahnung, wie ich herausfinden soll, was das Problem ist. Und es findet sich überhaupt keine Hinweise in den Syslogs, im Kernellog, ...? Seltsam... Wie häufig treten diese Stalls denn auf? Treten sie immer an derselben Stelle der Kompilation, an unterschiedlichen, jedoch nahe beieinander liegenden Stellen, oder an gänzlich unterschiedlichen Stellen auf? Das Paket sysstat enthält einige Programme, die man mal mitlaufen lassen kann, Dockerd läßt sich ebenfalls in einen Debug-Mode schalten, und im Zweifel geben strace und ltrace vielleicht Hinweise darauf, ob und bei welchen System- und Libraryfunktionen diese Stalls auftreten...
Be B. schrieb: > Es ging mir mit einer Frage auch weniger darum wie man eine Webseite > programmiert. Was mich eigentlich interessiert ist wo der Trend > hostingtechnisch hingeht. > Es gibt Hoster die sich auf PHP, RubyOnRails, ... spezialisiert haben. > Dort kann man nichts anderes machen, als das, was der Provider > bereitstellt. Ansonsten bleiben VM und Container. Hier ist man nicht an > PHP, Ruby oder Python gebunden und kann sein eigenens Ding machen. > Da ich serverseitig C# bevorzugen würde (Jave wäre 2. Wahl, alles andere > nur ungern) scheinen VMs oder Container die einzige Wahl zu sein. Die Frage ist ganz einfach zu beantworten. Willst du für Sicherheitslücken in deiner VM oder deinem Container gerade stehen, also haften? Wenn nein, dann nimm einen reinen managed Webspaceanbieter und nutze das, was dir der Hoster anbietet. Javascript + HTML + CSS + Webassembly geht bezüglich der Hoster überall, schließlich läuft das auf dem Client. Brauchst du serverseitige Skripte und eventuell noch ein Datenbankmanagementsystem, dann ist PHP immer noch das, was überall problemlos von den Hostern managed unterstützt wird. Ob du jetzt Java oder C# benötigst würde ich davon abhängig machen, wie komplex deine Webseite wird und welche Besucherzahl du erwartest. Für eine private Homepage würde ich mir erst gar nicht die Mühe machen das ganze in Java oder C# zu realisieren, denn da nimmt man lieber das, wo der Hoster am billigsten ist. Also PHP. PHP Version 7 ist ja schon lange nicht mehr so grausig, wie das bspw. noch zu Zeiten von Version 3 oder 4 der Fall war. Alternativ dazu kann man auch Python verwenden, aber dann ist die Anzahl der Hoster, die das offiziell unterstützen, man sich also nicht selbst um die Pythonlaufzeitumgebung kümmern muss, deutlich kleiner. > Wie und wo würdet ihr C# oder JAVA basierte Frameworks hosten? Hohe > Ansprüche an die Nutzerzahl habe ich im Augenblick nicht. Kosten wären > interessanter. Aber ich würde gern frei sein in der Wahl der Tools, > Sprachen, Frameworks, Datenbanken. Für Geld kriegst du prinzipiell alles, auch Server bei denen sich der Hoster um die C# oder Java Laufzeitumgebungen kümmert und das nicht du machen musst.
MaWin schrieb: > Ja, 7 von 10 Bekannten nutzen noch Win7, 8 von 10 haben Smartphones für > die der Hersteller kein Update mehr liefert. Die Leute habrn nämlich > keinen BOCK alle 2 Jahre alles neu kaufen zu sollen, wie es die Nerds > tun die die Scheiss Webseiten erstellen. Solche Webseiten werden nicht von Nerds erstellt, sondern von Künstlern, die das mit dem Baukasten zusammenklicken. Die haben nämlich keinen Plan über den Ressourcenbedarf, die Nerds haben den schon. Bei den Nerds kostet das vielen auch zu viel Geld, deren Stundenlohn will niemand bezahlen und mit den Baukasten geht es schneller und Künstler sind günstig zu haben. Die klicken dann was mithilfe der Frameworks schnell zusammen und fertig ist die Bloatpage.
Be B. schrieb: > Horst schrieb: >> Wer C# auf einen Server packt, der hat es nicht besser verdient, wenn >> die Seite gehackt wird. > > Wieso, sind Java/PHP/Ruby Frameworks sicherer? Das sind sie nicht, aber für PHP findet man wenigstens genug günstige Hoster die sich um die Wartung der PHP Laufzeitumgebung selber kümmern. Man kann sich damit auf seinen eigenen PHP Code konzentrieren und wenn man da keine Fehler gemacht hat, muss man praktisch nichts machen. Nimmt man stattdessen C#, dann muss man entweder den Hoster teuer dafür bezahlen, dass der eine Laufzeitumgebung für C# zur Verfügung stellt und die Wartungsarbeiten für einen übernimmt, oder man muss das alles selber machen und haftet dann auch dafür, wenn man die Software nicht aktuell hält.
Ist zwar schon ein bischen her, aber nachdem ich nun alle Posts gelesen habe hier noch mal, worum es eigenlich geht. Eine statische Webseite (Visitenkarte) entfällt, da folgendes benötigt wird: 1) Nutzerregistrierung/E-Mail an User 2) Bezahlsystem 3) Challenge/Response System (Lizenzhandling), damit eine automatische Autorisierung von Software beim Käufer ermöglicht wird. Es geht also letztlich darum eigene Software zu verkaufen + Lizenzhandling. Und dazu braucht man halt eine Webpräsenz, die schon das ein oder andere Extra bieten muß. Da ich mich nicht mit zig verschiedenen Webframeworks auseinandersetzen will, suche ich nach DEM richtigen System für mich. Mir ist klar, daß es kein richtig oder falsch gibt. C# wäre halt meine bevorzuge Sprache, wenn ich die Wahl habe. Statische Typisierung (https://de.wikipedia.org/wiki/Statische_Typisierung) sollte eigenlich ein Muß sein. Auch ist die Performance bei Compilersprachen besser. Docker ist halt verlockent, da man sich damit eben (hoffentlich) nicht an einen Provider und dessen Infratruktur binden muß. Ansonsten gilt: Sich in etwas neues Einzuarbeiten muß nicht schlecht sein, wenn man dabei auch was neues Lernen kann. Das Preisargument für den Server ist natürlich auch so eine Sache. P.S.: Videos und Werbung sind wohl her was für Webseiten, die sich über Clicks finanzieren wollen. Das ist hier aber nicht geplant.
:
Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.