161–170 of 551 posts
The main feature that introduces the need of a build step is having a template engine in order to reuse blocks of code, like footer, header, menu, etc.. I think Dreamweaver MX introduced something like template files, and it would make a "build" step that would copy the files from template to actual html files. Then it started to get complex, with data sources and generating pages in the backend. (php, asp, cold fusi…
Earlier quoted context omitted.
I made an atomic CSS library that doesn't need a build step, if anyone wants one (spoiler, nobody does): https://casscss.github.io/cass/
Imho, bullet points on the border box seems weird to me ( https://ibb.co/d0sDsQ2 ).
Don't use React for web pages, don't use plain HTML for application interfaces. But don't pretend that web pages and application interfaces are the same thing just because they both use the browser, or because "the application runs on the web".
Earlier quoted context omitted.
Isn't it much easier to know you're going to use React (or Svelte or Vue or anything else) and just start there? Starting a build in HTML-first only to bolt on a JS framework after the fact seems like a lot of wasted effort.
It might be easier to staff for. But developing a React frontend takes way more time than just server rendering HTML and layering in JS for the vast majority of use cases.
In theory these principles are really good concepts from an education standpoint. Where I teach, we teach students vanilla javascript and HTML as much as possible before moving on to frameworks that make things easier. Some of these points I'm a bit confused on... is the point behind "Where possible, maintain the right-click-view-source affordance" supposed to be to make the learning barrier lower? While I understand…
Have you used HTMX? I am yet to find a reason for using frameworks like React instead of HTMX.
Personally, I don't care for web "apps", seeing the unique value of HTML rather as authoring format for web "docs". For mere apps where JavaScript is obligatory anyway, I think I'd actually prefer CSS-in-JS.
Earlier quoted context omitted.
Why? Why does it need to be good for big projects in order to be good practice? I’m genuinely asking. I never understood this argument that people bring. In my view, the web is 95% small to medium projects. Most technologies should be focused on that - simple solutions for simple projectS. Add complexity later.
Because in practice there is little value in making easier things easier. While 95% on the web are small projects, 95% of work is done on large projects. Many developers also dislike using many different frameworks, because that would require more learning. If you have to choose one technology it's better to use one where you can do everything. Not one where you can do 95% really fast, but 5% not at all. I personally…
This is fun in to theory and in simple examples, but show me a big project that applies this and how it made a difference. There are some bold objectives at the start that would be wonderful, but I’m a bit disappointed by the advice. I really don’t see how these would work in anything other than very basic scenarios, even less how they would achieve the objectives. I’m all for using the web platform to the max, and I…
I've created my first website in 1999 with plain HTML, CSS, vanilla JS, hosted on Geocities.
Since then I've been using PHP/WordPress/Yii/Laravel, Ruby/Rails/Sinatra/Jekyll, React/Typescript, ClojureScript to create both sites and apps.
With React / TSX components / CSS-in-TS / Effects / Context I'm home. Finally a fully fledged programming language for the web / front-end. A language made explicitly for the front-end, built om modern principles like functional, reactive programming.
Now I can do software development. Before that, with HTML, CSS, plain JS, PHP it was ... just hacking, nothing else. (Rails was good for full-stack, was not shining on the front-end)
I'll skip frameworks when the web stack will be ready for the apps, too. Now it's (perhaps) good enough for sites, I should admit.
HTML is a presentation layer, as such it's 99% the output of some other layer. HTML first therefore is the wrong mindset.
You can't have an HTML first CMS for example, that's a recipe for spaghetti disaster. You need to define clear, constrained models that then you can adapt for given media.
I feel almost weird arguing with this site, because in general I also prefer simple HTML where possible, and I can't stand overdesigned JS-generated framework monsters.
But going from one extreme to another is not smart. No simple rule is a substitute for "intelligence first", and intelligence has lots of subtle rules and relies on rich context to make the right decisions for that context.
Nice domain name though.