There's never been a better time to build websites
simeongriggs.dev
simeongriggs.dev
Yes, tailwind might make css a lot easier, and github copilot might make coding a lot faster... but is this really easier than in the early 90ies, when you could just type <html> into notepad and make a website that didn't require any CSS or images or JS or even more than just the most basic html tags?
When it comes to reading a blog or article or consuming any other form of textual information on the internet - I find myself increasingly enamored with "Reader View" in Firefox, which basically ditches all the crap, and displays the web-page in a default-style, as if it was just the most basic html - just like that we did write in 90ies.
Of course this doesn't hold true for any webApps that do more than just present textual information (and the occasional image) - but why do project like ViewPure exist? There seems to be at least some demand for getting rid of all the clutter.
Is tailwind really easier to work with something like - let's say - pico.css? Of course if you want to do super-elaborate layouts, then probably yes - but if you embraced a more minimalist approach?
Isn't Hacker News itself a really great example of a website that successfully uses only very basic html with very, very little styling and fancy extra features?
But it always loads super fast, and it just works.
We figured out how to display text on a web page decades ago. It's a shame more people aren't just doing it the direct way anymore.
(Applications are a different matter obviously)
But my argument never was about the layout or design of Hacker News being "better".
What I meant to argue was, that content is king, and that everything else should serve the actual content - not distract from it.
Thank you! So many sites have utterly garbage contrast, making content unreadable - it's so annoying.
I spam this excellent discussion of color and usability as often as I can: https://designsystem.digital.gov/design-tokens/color/overvie...
but getting stupid 20 something designers with perfect vision to pay attention is almost impossible :p
A good contrast is Reddit vs hn. Reddit’s current site is basically unusable and sluggish on modern hardware that can you could train ML models with.
(Yes I get that webdevs' personal sites are their playground)
Let's not treat HTML tables as being some super special ability.
If HN were implemented exactly the same but with flexbox or grid for layout, it would be objectively better with no drawbacks I can think of.
Quotes don't sidescroll to infinity for you?
I could go on and on...
It's okish, but it's no pinnacle for usability, that's for sure.
> no drawbacks
Would it be slower or use more CPU or memory to render?
With flexbox layout, probably (?), but likely imperceptibly (don't quote me on that, I haven't actually done the math to check if the benefits from decreased DOM elements would outweigh the increased cost of flexbox, maybe it would get faster just by virtue of shipping less HTML).
That being said, GP is being kind of extravagant, there is arguably nothing on HN that requires tables or flexbox. I always felt like inline spans and maybe a few floats/margin:autos for stuff like headers/menus would probably handle the majority of the layout.
This is part of my criticism of "HN picked the simple answer" takes; even if you go back over a decade and even if you take flexbox off the table, tables weren't really the simplest answer after CSS `margin:auto` was invented. This really isn't a website with columns of data, it almost doesn't need any layout tool at all.
I think the, "now flexbox exists so we can do it correctly" takes are also wrong in their own way; HN is a single-column reading experience with very simple menus, why bring flexbox into this? I always try to temper this claim because I haven't technically ever sat down and built a pixel-perfect replica using normal HTML, I don't technically know there's nothing that wouldn't require modern CSS. But I have poked around at different pages of the site and messed around with resolutions, and I've never seen a situation on the site that I felt required all of that extra HTML and complexity.
I almost wonder if the point of the embedded font tags and image spacers and crud is that site is trying to make it sort of render the same even with CSS turned off. But if so, that's bad practice and the site should stop doing that. Anyone who's turning off CSS is doing that for a reason and the site should just respect that and ship them the pure content.
Trying to understand how so many people are reaching the conclusion that HN works well on mobile. Maybe 25% of the time I try to upvote or downvote a comment on mobile, I fat-finger the wrong arrow. That shouldn't happen in a mobile interface.
I feel like just for the sheer number of comments I'm seeing saying that they don't know what the problem is, there must be something I'm missing. To me it's pretty straightforward, you have to zoom the screen in 20-40% to press any of the buttons or accurately target on any of the links, and when you do that you have to interrupt reading flow because the text doesn't wrap during that zoom.
When I turn off the mobile site and request the desktop version it's even worse, so I don't think it's a browser setting. I don't think I have particularly large hands, but the links on the top of the site are still only about 1/3 to 1/4 the size of my pointer finger.
What are you all seeing that I'm not? Is there a font-size setting you have checked? This is a pain to use without a precise pointer.
People complain about Reddit on mobile, and I totally agree, Reddit mobile is awful, but it's also a really small part of my life, I generally don't visit Reddit on a phone that often -- so it's easier for me to think about Reddit's mobile site(s) as being some kind of outlier?
My experience has been I read a lot of blogs on my phone, I do searches (that go through duckduckgo, which I don't really have a ton of complaints about as a mobile site), I look up quick pieces of information on the fly from random sites, I look at MDN documentation, trying to think what else...
I also spent a long time turning off Javascript entirely on my phone browser and I've only very recently started changing that practice (largely because of Gorhill deprecating uMatrix), which probably biases things even more, because a lot of the browsing I do on my phone works without Javascript, and that gets rid of a nontrivial number of annoying behaviors from more aggressive sites, and so I wonder if I'm just not giving the same amount of "credit" for HN not doing the Reddit bullcrap where it pops up a notification asking me to install an app, and that makes it easier to stare at the flaws.
If I was doing a lot of Reddit browsing on my phone, I would appreciate HN more on mobile, I will give people that HN is much better on mobile than Reddit.
Going to push back on this line specifically, HN has a number of issues. They're not dealbreakers, but they're also not particularly hard to fix with modern HTML. HN has generally kind of bad accessibility/semantics, it's pretty frustrating to use on mobile, and it degrades kind of poorly without Javascript (collapsing thread buttons still appear even though they don't work, also, collapsing thread buttons don't work without JS).
HN is (unironically) a great example of how kind of hacky you can make something and how little you can iterate on it while people still are mostly able to use it for its intended purpose. And (with the exception of maybe its blind accessibility problems) it should be held up as a great example of that.
But it's not a good example of "do things simply and they'll just work well." If anything, HN is a great example of why stuff like tables were abandoned. And the HTML isn't even that simple, this must have been a royal pain to build, everything everywhere is another embedded table. It's a weird dig at how bad some major websites have become that people don't see HN's HTML as bloated or convoluted.
Ever really dug into how HN threading works? Everything is a top-level comment, and it inserts transparent images to create the illusion of indentation. It's a wildly out-of-left-field solution that makes parsing out and styling threads way harder than it needs to be. Seriously, I've spent way too much time trying to figure out how to make CSS selectors for custom user-styling work on child comments/replies on a site that is supposed to be displaying a comment tree in the DOM tree. There's a one-to-one mapping there, you don't really need a complicated visual slight-of-hand to display this information; just put the comments in the tree.
Again, not to get mad at HN; but I think people use it as a positive example in the wrong situations. HN has bad HTML with obvious downsides that would be pretty easy to fix, but it turns out that creating an elegant website and filing off the rough edges is actually a really small part of running a community, and doesn't matter that much in the long run when compared to other things you could be doing to foster that community (like moderation/curation), and that is a very good lesson for tech people to learn from HN. But nobody should praise the HTML on this site, there are much better examples out there on the web of sites that use simple HTML to great effect.
----
> (Applications are a different matter obviously)
Much more minor push-back but I actually would love to see more applications embrace the interactive document model even when fully native and fully offline. Not all applications, but a bunch of them. Stuff like calculators, calendars, even bigger applications like database software/image viewers/file browsers, etc...
User-accessible stylesheets for applications, user-accessible scraping tools for applications, etc... I think there's a lot of potential for user computing hidden behind a willingness to say, "no, many applications are just text displayed in tree/table form when you think about it, and the app/document divide was always sort of nonsense."
Having worked on an implementation of comment indentation before, I think it's a technical design choice rather than wildly out of left field. From the backend perspective, it's more performant (and simpler from as far as code maintainability) to have a flat db table with a number representing indentation level, rather than have each comment point to its parent, and then have to recursively build the html.
When you're getting as much traffic as HN, such design tradeoffs can make a huge difference in site responsiveness.
result = reduce(comments, (result, comment) => {
return result + build_comment(comment);
}, '');
indent_level = 0;
result = reduce(comments, (result, comment) => {
missing_lvls = indent_level - comment.indent_level;
close_str = missing_lvls > 0 ? repeat_str('</ul>', missing_lvls) : '';
indent_level = comment.indent_level;
return result + close_str + build_comment(comment);
}, '');
I guess I haven't ever read through HN's clientside Javascript, maybe it's calculating how to minimize threads on the fly completely clientside by iterating over the DOM, and maybe that's why the buttons don't work with JS disabled. But.. oof, I wouldn't hold that up as an example of good, simple clientside code if that's the case.
----
But again, I'm not going to argue with your conclusion, I assume there's something I've missed, I assume you're right.
This is still a bad example to use for "see, simple HTML is better". What you're describing is a good example of why it makes sense to say, "see, convoluted table setups that are worse on the client are faster overall than clean, simple output."
Which is not a bad lesson to learn from HN. It's a great lesson, sometimes performance requires us to do hacky things. But it is a very different lesson from where this thread started. You still would never point at that and say, "this is a good example of what HTML should look like", you would say, "these are the kinds of messy sacrifices that might be necessary to maintain a performant backend."
Holy crud, I just opened the JS up and this is actually what it's doing. Heck me and my little 'not going to contradict you' statements, you might just be completely entirely right about what's going on I guess.
function kidvis (tr, hide) {
var n0 = ind(tr), n = ind(kid1(tr)), coll = false;
if (n > n0) {
while (tr = kid1(tr)) {
if (ind(tr) <= n0) {
It's also definitely not easier on the client, I've seen some comments on here argue that HN might use all this weird stuff to save client battery life, and I feel more confident now saying that's not the reason, because if someone is somehow, someway legitimately in some incredible situation where they're actually worried about the battery drain of a browser rendering a table vs a some extra CSS, then this is not the code you would want to run every single time you press a button on the page.
But yeah, the "we just base everything off of an indentation integer and comment order" theory does seem a lot more plausible to me now, because I'm having a somewhat difficult time thinking why else collapsing comments would work this way.
Pico.css is for zero customize website. Once the website requires customization, it does not work. Tailwind is easier.
I mean you still can, it's just that nobody's going to hire you to do that and nobody is going to be impressed by it. Even back in the 90s when it was that easy, it was all hobbyists. By the time the dot-com boom started taking off, it was complicated. CSS + JS, no responsive design (remember designing 3 different sites to deal with the 460x640, 600x800, and 1280x1024 resolutions? Frames and no frames? Different sites for each browser [or ones that only worked in one bc things were even less standard than now - 'this site only works in IE'?] etc.)
Now it's the tools adding the complexity, but back then it was hardware, browsers, etc.
Using media queries with breakpoints, and doing exactly what you describe, was the original “responsive design”. What you have in mind (I think) is what might be called “fluid design”—responsive design without media queries. You could always do this to some extent with such things as inline blocks, auto margins, and other ancient CSS technology (and an unstyled site also reflows responsively), but flex and grid allow more elaborate fluid designs.
There is also some advantage to making separate designs carefully crafted for a variety of screen shapes, that you give up with fluid design techniques.
I remember when media queries came out. It was so nice. Amazing. 10/10 for the time. You can do a lot with auto-margins and other ancient CSS, but there are definitely quite a lot of limits. (Sighs in someone who does a lot of email design and academic CMS design... let's party like it's 1999...)
> There is also some advantage to making separate designs carefully crafted for a variety of screen shapes, that you give up with fluid design techniques.
I agree strongly with this from a UX/UI point of view and as an educator.
But everyone reading this knows it, and it does serve as proof that you can build a successful website with extremely little design & features. Therefore it seemed a good choice to illustrate my point.
Nothing is stopping someone from doing that today, but that's no longer the only option, thus it seems accurate that it is easier today than ever before.
The thing is you can still do all of this. But we have since built tools and frameworks to let you still do this, while giving you superpowers. I think Svelte is the best example of this. You can create a dead simple site with it and have the result you are talking about, but the real power is now you can employ many of those advanced techniques that were reserved for large web apps in the same dead simple site.
> Is tailwind really easier to work with something like - let's say - pico.css? Of course if you want to do super-elaborate layouts, then probably yes - but if you embraced a more minimalist approach?
I've used tailwind quite a bit, it's killer feature is the fact that it's just intuitive. With most CSS frameworks, even minimal ones, I always refer back to the docs to see how they do a specific thing. With Tailwind you refer to the guide a few times but very quickly pick up how it does things. I think that's why it's so popular, I've typed out classes thinking "is this a thing", and almost every single time, it was.
I don't know. I just tried to use Netlify to upload a simple static Html/Javascript page I made. Now I'm trying to figure out CORS errors. Pretty sure that didn't use to be a thing. For better and worse.
CORS will eventually click for you and then it will always make sense. Until then, sorry you’re going through the muck.
(1) Tailwind uses utility classes that feel like syntactic sugar over full CSS, so I don't feel like I'm "using Tailwind for layouts" as much as "using useful CSS grid presets"
(2) Much like with margins and paddings, text sizes, and colors, Tailwind helps me "pare down" the number of different values available to me. Much like having preset "m-1", "m-2", etc. values helps me be more consistent, having preset grid columns and gap spacing helps me stay consistent and not go too crazy.
(3) Because I'm using something closer to CSS-wrapped-in-classes rather than a set of components built by someone else, and because tailwind gives both a naming convention and an easy mechanism for adding my own classes that fit right in to Tailwind's, if Tailwind doesn't give me the exact values I want for grid spacing, then I can modify theirs. If I need to add a couple new presets in addition to Tailwind's, then I can do so easily.
(4) Early on when CSS Grid was new, I got bit by some bad layout bugs that were very hard to find, and impossible to fix (they were browser bugs). So, while I'm sure the bugs I encountered have since been fixed, I'm a bit gun shy on grids. I occasionally use Grid when it makes sense (via Tailwind), but more often than not I find it easier, more flexible, and safer to just use nested flexbox cols and rows. For which I also use Tailwind, if the project is of suitable size.
To sum it all up better, I view Tailwind more as syntactic sugar over CSS that helps me build my own design system. So, I would totally use vanilla CSS for small projects that don't need a design system. But for anything more than that, I like Tailwind for the same reason I like using web frameworks on the back end: it helps me keep things structured and consistent and more maintainable, even if I could do it all on my own without the framework.
For (2) however I usually use CSS custom properties to reach for preset values, e.g. setting "column gap" to "var(--margin-inline-wide)", and "row-gap" to "var(--margin-block-short)" etc.
I would also point out that Tailwind only makes sense to me when I'm also breaking up each individual UI element like cards or buttons into reusable components, either using a reactive framework like React or Vue, or a server-side template system. I'm not sure the maintainability of Tailwind survives with more monolithic HTML pages.
Easier to remember and quicker to type. Centering content on a screen is class="place-content-center" which makes things easier.
.container {
grid-template:
"nav . header header header" auto
"nav . . . . " 1ex
"nav . main . aside " 1fr
". . . . . " 1em
"footer footer footer footer footer" auto
/ 40ch 1em 1fr 1ex 15ch
}
I absolutely loath frontend developments in companies with more than 5 engineers. In the past you may have found some spaghetti code and various abuses of jQuery but you could probably grasp the codebase in an afternoon. Nowadays every mid company codebase is a spaceship. For sure, you'll find a pseudo technical VP of engineering which enable whatever cool technology to be used and resume driven developers happy to pile on the latest Big Tech framework - which is likely to be an over-engineered, over complicated exercise in engineer retention and engineer roles marketing.
Then you have Pieter Levels pulling a mil per year with PHP and jQuery.
Might it be possible that those expectations, and those requirements for doing "more", are not coming from the actual users/visitors to the websites - but rather from the companies owning the websites?
Because I, as a visitor of HN, come here for the IT news and the nerd stuff. I happily put up with the layout - because the sites actually meets my expectations for content. At the same time, the best, most modern, snazziest website ever... why would I go there (more than once), if there's no content of interest to me?
And that - to my experience - holds true for almost ALL visitors. They come for the content, and they put up with the layout. And this table-based layout with spacer gifs right here, imho is a lot easier to put up with, than some desing-heavy website that's perfectly optimized for conversion, engagement and retention rates and whatnot.
I think the actual problem is, that when we talk about "expectations" and "requirements" - we talk about what the HOST/SELLER wants - not what is best for the visitor.
My first job out of college involved a Rails codebase littered with conditionally rendered jQuery snippets. It was a nightmare to figure out what code was even loaded on any given page. Give me a modern JS codebase over that any day.
I was in high school.
That was the best time to build websites.
(Though at least "flat" trends and terrible UX out of several major companies mean my shitty designs are back to looking about as good and working about as well as "pro" designers, so that's, kind of, an improvement over ~2005-2014)
The only way to debug was "alert("foo")" placed in strategic locations!
We also had to handle significantly varied browser differences.
You can do a 90s style site today and vastly benefit from modern tech.
Hacker News is an aesthetic that would be unacceptable to the majority of businesses in the world. The login page alone would cripple sales on any e-commerce site.
I see that the example websites from Tailwind look much better than those from Tachyons, though I'm not sure whether that's just a matter of taste.
So, in some ways, its never been more difficult to build a website. Thankfully FOSS lets us outsource a lot of the work.
Those old page hosting services also served to get non-technical users to dip their toes into writing HTML, setting them on a path of learning, whereas newer page hosting services are either skewed no-code (e.g SquareSpace) or technical (e.g. GitHub Pages and Netlify) with little in-between, which keeps non-technical users locked into the WYSIWYG tools to a greater extent.
If a webpage is meant for presenting textual content and is actually _improved_ by a reader view, that means the design has failed.
There actually are websites out there that don’t benefit much from that view HN being a prime example.
20 or so years ago you had microsocft frontpage - anyone could build a site with little learning. heck microsoft word could spit out the doc as html I dunno how long ago.
some 15 years ago or so, I ran into a 'junk hauler' I found via google, asked who did his site, he said he did. I was like wow you were #1 in google organic, that's amazing - he said he opened microsoft publisher, put in the text, added a picture of his truck and clicked publish.
A lot has changed since then of course - google demands responsive layouts to rank well, and most people use a phone to surf.. which for a while made frameworks the magic since css grid was not baked into word/publisher/ie...
anyhow as far as 'easy' the are many other easier tools to use than tailwinds to make a site, and have been for more than a decade.
Now that browsers can auto fit via flex and grid - tailwind and similar are the bloat, not the easy-button.
I suspect if you are wanting to create interactive things scratch is a gem.
I don't think I'd have been so cocky five or ten years ago. Bootstrap solved real problems with cross browser layouts, jQuery fixed serious holes in some browsers' standard libraries. But the things they did then are things I'd happily freehand now.
In short, it's easier because 99% of browsers in use aren't awful and flex and grid make the float mess of the mid-Naughties irrelevant.
Today is a very good time to build websites, because a good website is the only way to push back to Big Tech and it's practices. Your website can be build on techniques invented in a time where the dream of the internet was not yet shattered by Big Tech.
Of course you can choose to put your website on AWS and svck on the bolls of Jeff a little. But you don't have to! And that's what all kinds of young devs just miss.
Oh, and RSS is not dead. Not at all (thanks WordPress, for putting a feed on every instance). RSS is the only workable way to make the web social again.
What we need, IMO, is more experimental protocols to enrich the web, which maverick developers can use to good effect, the same way we did originally with RSS. More browsers forking Chromium or Servo to add support for these new features. Hell, maybe even something that doesn't resemble the Web at all. David didn't beat Goliath and nor did Heracles beat the Hydra by using 'the same old weapon but better'. The only thing that wins is a paradigm shift.
I don't like talking about tech and business in a sense of 'weapons', 'winning', 'smashing the competition', etc. Talking about it in this sense makes it a struggle, because one will look at tech from the pov of a stockholder, capitalist, or just a narcissist. The wording is very important, and the moment you make that wording your own, you can't see it in a different light anymore.
To be honest, it's only since recently that I myself take RSS seriously. Before, I developed a sh1tload of websites without even really knowing what RSS is capable of. Ignorant me.
Thanks for your reply!
I like this paragraph a lot, in my perception this is why most of cryptocurrency initiatives and recently hijacked and massacred `web3` concept are fruitless so far - too much focus on how to get rich quickly
Also, the weapons metaphor was mostly just responding in the frame of the original language about 'pushing back on big tech', 'shattered by big tech', etc. And I do agree with that framing: I think there is a tussle over the direction of the internet – tussle, battle, tug of war, whatever you want to call it – and I'm not sure it helps to avoid the martial metaphor out of distaste when you are in a battle.
With the right website software it's easy to have an RSS feed nowadays, so the only thing that's missing is website software that also works like an RSS reader. In the most basic sense you only have to read XML with your program.
So now there's your own feed and other people's feed, mixed up in a nice and honest timeline (however you program that). To me this sounds a lot like the first principles behind social media, but without the obscure algorithms to fvck your timeline and without the intruding ads (I have nothing against ads per se).
P.S. Sorry for ranting about the weapons metaphor. I triggered on it and felt the need to tell what I think about language.
Edit: I forgot to say that RSS feeds have been there all the time for a lot of websites based on Wordpress. That has big value, because it means there's no need for technical adoption. These are all websites with feeds up and running right now. I've been hating on Wordpress for other reasons, but this was a good move for the open web from them.
Your explanation is exactly what I was thinking of as the ideal social media, but I don't see that explained on their website. No mention of RSS. As long as the feeds from my software can work with their feeds (and the other way around) I'm good.
If you have a blog and/or RSS feed somewhere online, let me know. I'll add it to my 'to follow' list.
This is a fascinating idea. I often think that Twitter's success, unlike Facebook's or Google's, is fundamentally as a protocol - and one which shouldn't have been centralised under the control of one company. And incidentally it seems Jack Dorsey thinks the same way, since he's suggested the possibility of having one core protocol for tweets, on top of which people could build their own frontends, and users could choose from a marketplace of both (a) frontends and (b) algorithms for filtering and ordering what they see.
I do agree with you: what's missing from RSS is not the existence of the protocol, nor even necessarily the 'supply side' of websites providing it (like you say, largely courtesy of Wordpress), but the 'demand side' which really needs a well-designed interface to consume that kind of content. I absolutely agree with you that this feels like a huge area of potential.
And thinking on a more second-order level: I wonder if one thing that's preventing these innovations is a suitable, easy 'base' for people to build this software on. For example, take `create-react-app` for the web. Countless things have been made because people know that they have that simple base to start with. For building a web browser alternative, there's no equivalent for most people: they don't know where to start. If we had a simply bundled toolkit such that people only had to write some business logic, I wonder how much more would be done.
> P.S. Sorry for ranting about the weapons metaphor. I triggered on it and felt the need to tell what I think about language.
No prob at all! Susan Sontag wrote a really interesting essay 'AIDS And Its Metaphors' in the same vein, specifically about the use of war metaphors about AIDS and cancer: "fighting", "losing the battle", &c. (It's the culmination of a series of essays on the same topic, but this is the most thought-provoking of them, IMO.) You might enjoy it. I particularly liked:
> The metaphor implements the way particularly dreaded diseases are envisaged as an alien 'other', as enemies are in modern war; and the move from the demonisation of the illness to the attribution of fault to the patient is an inevitable one, no matter if patients are thought of as victims. Victims suggest innocence. And innocence, by the inexorable logic that governs all relational terms, suggests guilt.
Wikipedia has a great summary: https://en.wikipedia.org/wiki/AIDS_and_Its_Metaphors#Militar... https://en.wikipedia.org/wiki/AIDS_and_Its_Metaphors
I'm sure people have other bold ideas. I personally think there's a lot of room for something which builds on the 'progressive web app' paradigm: i.e. a web for websites which are more like apps, downloaded once and then exchanging data ad hoc with a backend server, with potentially much richer and more performant experiences. WebAssembly (WASM + WASI) would be a great foundation for something like that. But that's just one among countless compossible paths.
Alternatively, the modern browser has basically evolved into a virtual machine anyway. You seem to be suggesting that we could do exciting things with a more intentional version of that idea, and I don't disagree.
I think either direction would be interesting. Or both. The browser was an experiment in the first place, but people seem to have stopped experimenting and are just doing the equivalent of what building on an IBM mainframe would have been in those days. It's disappointing. (It's not unlike people who quote Martin Luther King today, not appreciating that the essence of his radicalism was the direction of travel towards justice, not the political compromises themselves which are now firmly established.)
I hope at least that the renewed interest in systems programming that's come with the Rust fandom might spur some actually innovative developments to replace the antiquated model we're all stuck using. But sadly the tech community seems to be split into two communities, one of which has no interest in innovating, and the other of which seems to be set on innovations so absurdly impractical (¡world wide web on the blockchain!) that they could never take off.
New protocols are DOA until we significantly nerf the incentives to "own" the user.
IOW it's not gonna happen until we outlaw anything that resembles spying on users. And maybe also ads generally.
This is all well and good, but then we need a serious alternative funding model for websites.
Right now, a lot of people with adblockers are benefiting from a situation fausse where they free-ride on the ad-click revenue generated by others. I think in some people's minds this leads to an impossible expectation that they can continue to enjoy freely provided services, provided at considerable expense to the service provider, without paying anything or even having the inconvenience of having to see some ads.
I'm all for abolishing ads, but it needs a serious proposal, not just "what we have right now, but no ads". I'd also be all for an online payment mechanism embedded into browsers through a new protocol - something like https://www.w3.org/TR/payment-request/ but designed with more of a view towards paywalls - but I'm under no illusion: most people's revealed preference is consistently for ads over paying anything, as many startups in that space have discovered.
Why?
Without competition from free-but-funded-with-$billions ad-supported services, most of the valuable stuff would probably be replaced by volunteer and non-profit efforts.
Others would survive by charging (more) money.
Some would be replaced by protocols (several social networks would be among those replaced). Clients & hosting may be paid, or not. It'd work out fine.
Most of the rest isn't valuable.
It wouldn't just be 'non profit', it would be 'considerable loss'. You can't provide a service like YouTube or Google without incurring enormous expense, even if you're only counting the infrastructure costs.
> It'd work out fine.
You have no idea whether it would work out fine. Neither do I. I'm intensely sceptical of anyone who issues hand-waving proclamations about how a dramatic change would affect an almost indescribably complex system.
You may have your own wishes and preferences, but it's not a good idea to let those invade the rational, evaluative part of your mind.
> Most of the rest isn't valuable.
Anything that's used by someone is valuable to someone. I don't like paella, but I don't propose to eradicate all paella restaurants for that reason. Again, this feels like a hand-wavey and not very wise answer to dismiss problems with your idea.
I'm not a bit worried we'd go without capable search engines, without ads. Very likely there'd be donation-supported ones that are at least as good, and maybe better for some purposes (IMO Google's utility peaked around '08).
The free side of Youtube is a UX problem to be solved by something like torrent clients (maybe plus some RSS). Or probably a dozen other ways. It's far from insurmountable, there's just no motivation to fix that now (because there's no demand for it). That's the story for most of the services that could be replaced by [two or three existing protocols] + [some not-exactly-rocket-science UX effort]. The commercial side of it is solved by... hosting videos. Yourself, or paying a service to do it for you (these services already exist, despite YouTube's dominance, all the way from simple video-hosting to full white-label video streaming services).
> Anything that's used by someone is valuable to someone. I don't like paella, but I don't propose to eradicate all paella restaurants for that reason. Again, this feels like a hand-wavey and not very wise answer to dismiss problems with your idea.
It's plain that a huge percentage of online content could be replaced with Snake Game on an old Nokia with ~0 loss of enjoyment for the consumer. A perfect replacement for them is a book of Sudoku puzzles. People look at the stuff but the value is extremely close to zero, in that nearly any other time-wasting activity is just as good. And that's after dismissing the ~75% of the Web that's spammy garbage of negative value (because it drowns out better material covering the same thing).
> You may have your own wishes and preferences, but it's not a good idea to let those invade the rational, evaluative part of your mind.
Beats accepting the wishes and preferences that created the bad situation that exists now, right? Why should that be privileged over what I'd prefer? Has zip to do with a lack of rationality on my part, though it's easier to dismiss ideas if one first paints them as irrational.
We can have useful, widely-used open protocols or we can have spying (ads may or may not also be on the table, but take away the spying and there goes much of the advantage of the huge tech companies, anyway). The two very clearly cannot co-exist. I'd prefer the former.
This isn't necessarily wrong. I personally use Gigablast, which is excellent and entirely independent (unlike many 'alternative' search engines it isn't backed by Google or, more often, Bing).
However, pace the problem of other minds, I am not the only person in the world, and many people enjoy and rely on Google. I think this conversation is continually falling into the trap of muddling up what you personally prefer vs what would most satisfy the majority of people, and thus achieve adoption.
It's not a good solution if most people consider it worse for their needs, irrespective of your own personal preferences, or your feelings about what other people should like.
> The free side of Youtube is a UX problem to be solved by something like torrent clients (maybe plus some RSS).
Come on. This is as near as possible to an objectively worse solution. Again, I think you're struggling to see beyond your own preferences and abilities, to how most people in the world interact with technology.
> It's plain that a huge percentage of online content could be replaced with Snake Game on an old Nokia with ~0 loss of enjoyment for the consumer.
I refer back to my previous sentence. [Also, both Snake and old Nokias are exactly as available today as they ever were, and I see no sign whatsoever of this happening, despite the clear advantages in price, battery, uptime, etc.]
> People look at the stuff but the value is extremely close to zero, in that nearly any other time-wasting activity is just as good.
I refer back to my penultimate sentence.
> Why should that be privileged over what I'd prefer?
I refer back to my antepenultimate sentence. The answer is: because you are one person in a world of seven billion, and your solution is not going to go anywhere if the mass of people don't like it.
---
Look, in summary, this is not a useful conversation if all you have to contribute is moralising about the worth of other people's preferences. I don't care if you think most people should spend their time knitting or listening to Brahms. I'm trying to come up with a solution that satisfies people, and, therefore, can actually compete.
[EDIT]
> if all you have to contribute is moralising about the worth of other people's preferences
Definitely a complete characterization of my views on this, and of these posts. You've looked carefully, considered thoughtfully, and discovered the entire thing. Very good.
As for alternative funding models - why not microtransactions? Attaching an explicit price tag onto website access (subscription model) or individual media/document objects (standard "pay for what you use" model) would have some other beneficial effects, such as reducing extraneous media consumption (mindlessly scrolling for hours suddenly starts costing you money, better to buy a book and get value out of it) - most advertisements are a mental cancer that we should try to get rid of anyway.
As for alternative funding models - which is definitely a much more interesting conversation - I actually considered starting a company in exactly that space. I have some experience in fintech ("very credentialised" according to my former Anglo-German lead investor, haha) and so I thought I could pull it off. I couldn't, and it didn't get past the MVP stage ... luckily. The trouble is that people aren't willing to pay even the $0.01 to access an article. There's something deep in people's brains which is averse to spending money, no matter how small the amount.
I believe - and this is more second-hand evidence from other founders rather than first-hand - that the approaches which typically see the most success are those where people 'top up' a certain amount and then spend it gradually. That doesn't set off the same psychological alarm that directly spending money does. However, that kind of approach would be much harder to implement - especially as something like a browser protocol - because it would require holding probably-vast sums of money in escrow[0], which is an extremely burdensome legal and regulatory position to be in.
Personally I think Brave - much as it's a stupid company started by a stupid clever man - might be onto the right big idea here (despite getting a million little things wrong, and alienating virtually all of its users and most of its non-users too). The core idea of buying attention tokens which are paid out to websites to which you pay attention is a brilliant one. However, it needs a lot more refining, since the crude version of that model is not particularly well-equipped to deal with the difference between e.g. a movie-streaming site, on the one hand, and a shorthand news site, or even a site like Twitter, on the other hand. I may well watch a movie for 180 minutes but get less value from it than I do a tweet. So attention != value, or at least the concept of 'attention' needs refining to be more than simply 'time I spend on a website', but there's a promising kernel there, I think.
[0] Compare it to Starbucks's gift card program. Starbucks is one of the largest commercial debtors in the world just by virtue of the vast number of Starbucks gift cards in people's drawers. These things add up quickly and bigly.
I agree with this. But what really spins my beanie is the amount of power a website gives a single person, small business or non-profit. It's really amazing.
One might not immediately make money with a website (although you sure can!), but the moment you are kicked of some platform, you have a safe haven to fall back on. A place where you can share the same textual or visual media with your visitors(/followers/friends/fans/connections). But instead of organizing a party and renting some space, you make it a house party, where you are the host.
The only moderators on your website are you, your webhosting provider, and the government (I call it GovMod).
Thanks for your reply!
And I get it completely. Over the course of years, Google and the likes probably have more phone numbers of my contacts than I have. Only three weeks ago I made a text file with every name and number in it, so I have a safe copy for myself.
You shouldn't have to worry about suddenly losing your list of contacts. Google should be required by law to provide your data to you in cases such as account termination.
Each time he scheduled a return appearance in that city, he'd send out an email letting people know the date and time of the show and a link to buy tickets.
Today, people build their followings on social networks that barely let you even post links to your own site (Instagram). Had Twitter/IG/FB existed back then, people would have no way to maintain independent contact lists.
Spam is a huge problem.
Not if you get banned from payment processors. Which is a thing that certainly happens
I don't know about the US, South America, Asia or Russia, but I guess people have good old bank accounts, have an internetbanking app installed on their smartphone, and sometimes have to pay money to a neighboring country? It might not be as easy as here, or just completely different, but I guess there are ways to skip payment processors, as the fee-stealing middle man that a lot of people take for granted.
Where are you hosting your websites?
Admittedly it's behind Cloudflare because DDOS skiddies, but I think the CF lock-in isn't much if you're not using workers or anything proprietary to them. Admittedly it does suck for people with really privacy-customized browsers or using Tor, but idk a better solution unfortunately.
I host some websites at Antagonist in The Netherlands. But I'm strongly considering moving, although they are by far the fastest and most reliable party I've seen.
Why? Because they - just like a lot of other European webhosts the last years - are now part of some vague sh1tshow called Group.one or something. I don't know what this organisation is up to, but I don't trust it for a second. I guess they are trying to become some European version of AWS or something. Data grabbers, probably.
Every sincere webhost that became part of their 'network' (they sell it like this, but it's just a merger/acquisition) uses stupid wording in their press releases, customers are not kept up to date about these important changes (only after the fact, of course) and they all of a sudden are now offering 'cloud storage' like it's Dropbox.
This was a bigger reply then I intended. But thanks for yours!
I won't be moving away from static website. It is perfect solution for a blog/CV type thing.
>you might think that minutes-long build processes are normal
If compiling your static site takes minutes there is something fundamentally wrong with your site in my opinion.
> I won't be moving away from static website. It is perfect solution for a blog/CV type thing.
Yeah, I'm keeping an eye on these new "MPA"/"transitional" frameworks, but the thought of taking a static marketing page, which costs fractions of a cent to serve and is easy to put on a CDN, to now requiring a backend server which costs magnitudes more, seems foolish.
90%+ of the Web is just static sites with JS sprinkled on top. That has always been the case and will stay that way for the foreseeable future, because it's the most simple, pragmatic and accessible solution.
There are some interesting properties of server rendered websites and it can be the best option in some scenarios, but in others it adds complexity and burden on the end user. To suggest that static was a "fun diversion" detracts from the value and I feel we'll be going full-circle once again after we've realized that "what works" isn't always server render HTML.
I'm embarrassed to say, having programmed for over a decade, and running Linux for half of that, I still have no idea how to setup my computer to serve a webpage (or even a file)
I probably need to `apt-get install apache` and then deal with some magic config files and incantations and hope I don't mess something up and expose my whole computer to the open web. Then there is the whole mess of NAT (wasn't IPv6 supposed to kill off NATs?).
I need to then figure out the endless (and impenetrable) configurations in my OpenWRT/LuCI router to open a port and have it forwarded to my computer. Or maybe that needs to be done "upstream" in my landlords internet cabinet..? I'd have no idea how to even figure that one out b/c my router doesn't make it obvious in any way.
Then I need to find some DDNS service and figure out how to get that to route traffic from a URL to my IP (and then it's somehow supposed to reconfigure when my IP dynamically changes? Is that some cron job I need to write?)
Hosting webpages from home is still complicated and no progress has been made. And if you do it wrong someone will hack you and steal all your files :) The incumbents are probably happy it's so painful and you still need to do technical gymnastics to punch through NATs and whatnot. This text further confirms it by just telling people to host int he cloud. And understandably.. you'd have to be a total nut to serve a file from your home instead of dropping it on Google Drive.
When I was studying this stuff in college I just figured tech is in an awkward teenage phase and this will all get worked out and streamlined - but I think it's not going anywhere This isn't the tech future of 80s scifi
I don't mean to be wholly negative, I'd actually appreciate if someone pointed me to a good step by step to set everything up. At the moment I'm a sellout :) and I just use Github Pages and git push HTML/CSS files there. Ideally it really should be just as easy to git pushing to your own home computer but till then I guess I'll do that..
That's what I did for the first few iterations of https://lunar.fyi and it really helped with giving people the right information fast while I could keep spending time on the real work (developing the Lunar app)
But if hosting from home is what matters the most, there is an easier way nowadays using Caddy (https://caddyserver.com) and ngrok (https://ngrok.com).
For example, I just hosted this website (https://af62-2a02-2f0e-d00f-e100-f513-b43-fbc1-cf5d.ngrok.io) using the following commands:
caddy file-server -listen 0.0.0.0:6001
ngrok http localhost:6001
.gq .tk .ml .cf. ga
I’m really glad to hear that from you!
I will need to read the docs a bit later b/c from the landing page it's all still confusing. This is probably a function of the tech "debt". It has example commands like
caddy file-server --domain example.com
- Do I need to stick this into my .profile? Or I need to configure a systemd service?
- What is it even serving out..? Is it just serving out everything in the immediate directory I'm in where I run the command?
- How is it "hooking into" example.com? How does the registrar know to point at my IP after I run this command? (or if that's done separately - say on the registrar website, why do you need to specify the URL locally at all?)
In any case, these are just immediate questions that come up. It's all stuff that probably makes sense if you know it already :)
And again.. i need to rtfm - so I'm not complaining or shooting the messenger here haha. Thanks for the info
When you run `caddy file-server` in a folder it just starts serving all the files in that folder. You can serve MP3 files if you want, or .txt files, it doesn’t have to be webpages. It just happens to serve them over the HTTP protocol because that’s what the browser speaks.
Keep in mind that caddy doesn’t allow a user to get out of the folder you ran the command in, and it also doesn’t allow the user to list the files in your folder if you don’t explicitly allow that using:
caddy file-server -browse
The domain option is not for pointing that domain to your IP address. That can only be done from your DNS provider (e.g. Cloudflare, or even Freenom which I pointed in the last comment)
What the domain option does is allow you to serve multiple websites on different domains from the same computer, and it also automatically generates SSL certificates for them so that you have encrypted `https://` support by default.
A few years ago, you would have had to buy SSL certificates from someone like Verisign, download those certificates, figure out where to put them securely and configure Apache or Nginx to use them for each domain. Caddy does all that automatically now.
Also keep in mind that if you run a file server like that: `caddy file-server -domain example.com`
… then caddy will only serve those files if you access them using that domain. If you try using your IP address directly, or any other domain instead of example.com, it won’t respond with your files.
In this way you could have multiple domains serving different files from the same computer.
Now this would be a real improvement, not some new framework of the week.
python3 -m http.server
The home networking / dynamic IP stuff will probably not go away until ipv6 becomes more commonplace, but honestly that is for the better. Ask any business whose upnp-enabled receipt printer started outputting antiwork propaganda the past few weeks how it is going.
https://github.com/anderspitman/awesome-tunneling
If you wanted to self-host a website from your home computer today I would recommend buying a domain from Cloudflare, and using Cloudflare Tunnel.
6 months from now I hope to be suggesting some variation of my open source alternative, https://boringproxy.io. It's not quite ready yet.
Say about 15 years ago or so, if you had a creative inspiration for a personal site, you could whip out a text editor and start building top-notch stuff very easily. About the most complicated thing you had to do to start building something was adding jQuery to a project.
Today you have to research a pile of unnecessarily complicated (for most personal projects) frontend frameworks, libraries, and build systems, figure out the compiling and development environments, figure out a complex mess of containers and virtualization, etc, etc, etc. This stuff sucks the joy out of building anything, even if the actual coding itself is far more structured and convenient.
By the way as genuinely nice as Tailwind can be, calling anything a solved problem is kind of arrogant. There will probably be other design approaches and ideas invented over time that are even better.
It's just that there's better tooling available for you to build it faster/featureful now.
Web standards still have a long way to go, but it's comical to claim that things have gotten harder.
You need the frontend frameworks, build processes and million NPM dependencies only when working inside of a developer team for an enterprise software of some sort.
Well yeah, but once you've learned the modern paradigms, you can get right back into hacking away in your text editor. I've been doing web development stuff for longer than 15 years or so, and it's no more difficult to start a project now than it was back then. I can run a single command to create a template nextjs project and be hacking away in no time at all. Yeah there's a learning curve initially, and for certain use cases you may not want or need these modern tools, but it's no different than when all that time ago I finally, after much foot-dragging and moaning, I finally learned CSS and transitioned away from "tables for everything" HTML I'd learned on Geocities, which seemed like the pinnacle of productivity at the time.
While the industry was largely distracted by various NPM packages, the foundation we are building sites on got really nice. And I believe in some situations there's value in trying to use this foundation directly, not via a plethora of abstractions. Browsers are great, DOM API is great (well, certainly provides some really nice utils we previously had to look for in external libraries like jquery). CSS is great. I will write "display: flex;" multiple times just because it feels nice to type that, compared to the dance we had to do a couple of decades ago to achieve same layouts.
Static sites are great. They are fast to build, and they build fast. They are really easy to deploy as well. And they also work really well on end user devices. No single line of JS required, but if you want to have some liveliness on the page which can't be easily achieved by CSS animations, very few lines of JS are actually required nowadays. And 0 NPM packages.
Modern JS web frameworks do solve problems some people actually have. But they're best suited for big corporate style webdev. For personal projects I prefer something more… artisanal? Dunno, it's like building a piece of furniture yourself instead of buying one from IKEA. Probably less practical, but feels nice. And may actually fit better in this one weird corner you have.
> Static was a fun diversion, but we're back to what works.
Static works really well for many use cases. And you are never going to beat the performance of static in a cache close to your user. I agree that there are many cases where server-rendered is the best option but static with a good sprinkling of JS and server-generated embeds definitely works.
> Tailwind CSS is the best thing to ever happen to CSS
This is obviously controversial. Maybe for non-static websites where every `<p>` in your site is generated from the same line of code it is trivial to add `class="m-4 text-gray-900"` when I may use the same component in multiple places that gets boring really fast.
> GitHub Copilot
Maybe if you weren't writing `m-2` on every p this wouldn't be as helpful /s
Maybe I haven't seen the light yet, but in most weakly-typed languages Copilot felt like a huge loaded footgun. It also generally worked on the simple cases that didn't require much work anyways.
---
I think it is clear that this person found an approach that works for them, but it seems like there is still a lot of from for improvement here.
I read this article and shudder in horror at, well, all of it. I like static sites (that wouldn't take minutes to build if they were written in a decent language). Adding lots and lots of JS dependencies and frameworks gives me the screaming ab-dabs - it's just adding complexity and dependency. I like writing code, not plumbing together bits of other people's code with bizarre config files. I object to CodePilot for all sorts of reasons, but fundamentally because I enjoy writing good code.
But I know experienced devs who have exactly the reverse opinions. Like OP, they see all this as going in the right direction and making their lives easier.
What you pay for when you hire a dev like me with 17 years of experience in the field is the ability to know which libraries are the best to use and which techniques are worth using in the process.
I am just getting into TypeScript programming, and I am really having fun. I learnt about the details of how Javascript works, and it is quite cool to have a static layer over a dynamic one. For learning JavaScript, I like "The Good Parts" and the "You don't know JS" series. It took me a while to learn how to create a datatype that can defend its invariants not only statically, but also at runtime, but that seems quite feasible as well, especially with decorators. It is interesting though that nobody seems to be particularly interested in doing that, there is not much direct information about this available.
In my honest opinion Typescript is a fad. You're still just coding JavaScript with an alternative syntax. Since you're borrowing dependencies from JS you need to know both and context switching between the two slows you down. From a CS perspective I get why TS syntax is better but from a functional perspective it's harder to find engineers that actually want to work with it because every TS project I've ever seen is really a mix of TS and JS.
And it is quite obvious to me that you need to know BOTH TypeScript and Javascript, of course, you cannot just learn TypeScript, because it is just a thin layer on top of Javascript without many runtime guarantees otherwise.
You seem to be conflating objective wrong/right with your own personal stance. Do you have an objective argument in favor of your assertion about the longevity of non-TS libs?
> And it is quite obvious to me that you need to know BOTH TypeScript and Javascript
That's a reasonable strategy on the assumption that TypeScript will be used, but the very fact of its being so is actually an argument in favor of the point made by gp which has been left unaddressed (RE context-switching).
There is no need to context-switch. Just accept Javascript as part of TypeScript, because it really is. The argument is clear: TypeScript drastically reduces the amount of errors you will be making when coding, and the amount of time you need to think about stuff that is really trivial.
The rule of thumb on how to do this is also simple: Keep your types simple, use them to make your life easier, not more complicated. If you cannot model something simply using types, don't try to do so, just use the dynamic typing escape hatch that Javascript provides.
I'm shocked that you believe this. Work at a moderate or higher sized tech company. The juniors, mid levels and seniors all make the same mistakes and slowly grow out of making them. If it were the case that everyone could stop making the same mistakes and choosing the wrong abstractions simply by reading a book then professional programmers would be good on day one and make none of those mistakes and college students who've read dozens of books would come in at the top of the rankings.
> I am just getting into TypeScript programming, and I am really having fun. I learnt about the details of how Javascript works, and it is quite cool to have a static layer over a dynamic one. For learning JavaScript, I like "The Good Parts" and the "You don't know JS" series. It took me a while to learn how to create a datatype that can defend its invariants not only statically, but also at runtime, but that seems quite feasible as well, especially with decorators. It is interesting though that nobody seems to be particularly interested in doing that, there is not much direct information about this available.
This is learning to code, it's not learning to engineer. Assuming you finish your book(s) you'll start on the path of making lots and lots of mistakes until you grow into someone with more experience who stops making them.
or at least fewer, and sometimes more complicated mistakes.
I've been doing this since literally IE 5.5 and I'm still learning new stuff all the time. The fact that you think you can learn all this in a few months is hilarious.
If I need to know a particular event, I look it up in the documentation. The stuff you cite is just APIs, I can look that up too. I've used APIs before, you know. Right now I am piping data from Swift to Apple Metal and back, and write GPU code to estimate measurements from the FaceID camera in realtime.
Real programmers are coming to the Web, babe.
That's not the flex I think you think it is ;) I've been coding for over 40 years now, professionally for over 25. The attitude you have is one I very much associate with younger devs with limited experience.
I don't like reinventing the wheel every time I build something
Sure, I also use libraries for things that are just tedious, hard to get right or just some standard feature that's always used the same way. But you can overdo it.
Debugging my own code is annoying but doable. Debugging other people's code is a lot more tedious. Troubleshooting a mess of 1000 transitive dependencies because one package had version 10.0.6 instead of 10.0.5 and that caused an avalanche of breakage makes me reconsider my life choices.
This is the crux of the difference, I think. I see open-source libraries as (mostly) mediocre code, usually massively bloated with features I don't need. Using them is like using an 18-wheeler to nip to the shops. I have found in my experience that it saves time in the long run to just write the minimal amount of code I need for the job, rather than dealing with the added complexity and dependency of adding a 3rd-party library.
The alternative is adding my own mediocre code, with all the maintenance costs that incurs.
-Carl Sagan
The problem with bizarre config files is that you repeatedly have to learn enough to make them work but then do not need to use that knowledge again until after you've long since forgotten and you have to start the learning process from scratch.
I started making websites in 93, and to me, websites are about communication and sharing. They exist to facilitate communication. The current system of crazy dependencies and frameworks just doesn't do this; it values speed and ease over every other aspect of communicating. Imagine if TV developed in a way where they sat and tested how much they could speed up the show and be understood and made that the standard so shows could be 'watched' more quickly: That experience would SUCK.
Or cars that can go from 0 to 100 in .5 seconds but have no seat belts, no horns, no airbags, no turn signals...
I've worked with Angular and React, and they have their place, but IMO 95% of websites just don't need them.
Honestly, a lot of times, I’m left wondering if this isn’t the case.
I've been testing copilot for about a month now, one thing I realized very quickly is it's not as useful as you might think it is. Copilot is great for writing repetitive code, so if you just wrote a function to select an item, copilot will correctly guess what the deselect function implementation should be.
Outside of that though I find that it gets in the way far more often that it helps, by far the most annoying part is that it interferes with intellisense sometimes, picking values from an enum in Typescript is now a PIA if you have Copilot enabled.
Using Copilot speeds you up, so why not take advantage of it?
It's copy-pasting from stackoverflow except a little faster.
I have my own framework - smaller and it fits my way to work. And yes I understand that this would be a other situation with a team (but then you have a guy without soul, moral and honor which is called "the sales guy" who sales everything).
From my limited experience, the main issue is that it's really hard to ensure frontend actually works as before, after upgrading frontend libraries/frameworks, outside of having really extensive end-to-end test suite.
This point is stated as if it's a widely accepted truth. Is that really the case?
I still labour under the misapprehension that one should aim to use as little javascript as possible.
Maybe you get used to it but hell it looks hard to parse visually.
Unless you follow very strict development guidelines, you do not really know anything unless you look at the computed styles in a debugging tool.
I think Tailwind does help wrangle some of that cognitive overhead with its naming system.
It most certainly is not a solved problem lol. UI still feels way fucking harder than it should, in all kinds of ways.
- utility classes
- theme system
Neither of which are unique to Tailwind (which is great in itself), yet the article paints it like it's the only thing out there solving for it.
Well, this is so 2005.
This is particularly important so that web scrapers and other automated tools that the Web relies on can work. Also accessibility tools.
>Remix is a seamless server and browser runtime that provides snappy page loads and instant transitions by leveraging distributed systems and native browser features instead of clunky static builds. Built on the Web Fetch API (instead of Node) it can run anywhere.
I found no mention of the blockchain here or anywhere else. Why are they touting their own horn so much if they are clearly not Web3 ready?
This article brings no hope that somethings has fundamentally changed in the community.
Back then all I needed was get a bit familiar with FrontPage and html scripting, some Photoshop to create/edit image elements, and I already had a functional website.
I knew if I wanted to "really" do it, I should probably learn proper html, but 15 years old me was already plenty proud of having a pretty good looking, and well working, website at all. It even had a visitor counter, and a guest book, all the Jazz that defined 90s websites, and that was enough for me.
Now, over 2 decades later, just the prospect of getting back into it seems so extremely more daunting and complex. We are now at Html5? At "Web 3.0"? I don't really know anymore, it's all just become so "vast" with so many options and so much complexity that I wouldn't even know where or how to start anymore.
Is it still viable to just learn plain html and do something with that? Have WYSIWYG editors matured so much that they can be used at least semi-professionally, or is that still "looked down upon"?
If you're working on your own and don't need a back-end, there are options for putting up a personal site. Webflow[0] and Squarespace[1] come to mind. They'd be taken seriously semi-professionally in non-tech spaces. Can't speak to tech ones.
There's a lot more you can do with static sites, it just depends on how much time you want to sink into it. I just made something basic. Maybe when I'm bored I'll try to build on it.
Are you trying to make a website, or a web application? That really is the biggest question. For a static website that's read-only (meaning no user login, or user-submitted data, no online store), the old ways work fine.
With modern CMSes, you can create ecommerce stores and other dynamic functionality, but it comes at the cost of flexibility. On Squarespace for example, you can only use the pre-build templates to create the site.
And even if you are building a website by hand where you have full visual control, you can you can add a lot of interactivity by embedding iframes for things like JotForm or a PayPal button.
In fact the best time was about 2005, when most current day's media sites started, because it was still possible to be found.
The tech you use does not matter. The web is backwards compatible
> The first time you see your website instantly update because you made an change in your CMS, it'll shatter your whole Static Site Generated world view.
Jesus, we 've had that thing since 1995. What happened?
If you stay in IT long enough you may see this cycle repeat 3 or 4 times
And?
Not to be glib, but you need exactly zero readers on your website to have a whale of a time making it. In terms of building a website, the tech is exactly what matters because that is where the fun is.
I fully agree with your last sentence though. It's ridiculous to think that only dynamic CMS' allow instant changes. A small static website reloads instantly. Even better, one doesn't even need the internet since you can see the updates localhost!
I thought the same thing. I have built several custom WordPress sites, and changing the PHP code and hitting F5 shows me the changes immediately. What world is this where a site needs to re-compile each time a change is made?
The real success story we should be celebrating is how awesome the specs are in modern web browsers. Vanilla JS, CSS, and even HTML itself have gotten incredibly good. Just having Flexbox and Grid working as native CSS layout engines is tremendous, and soon we'll have container queries (!!). The latest ES versions are lightyears ahead of the JavaScript of yesteryear. HTML now has superpowers when you consider what custom elements/web components are capable of. Developments at the level of HTTP itself, along with in-browser imports, are affording new opportunities to leverage the browser directly to handle dependency graphs rather than requiring everyone to bundle/transpile everything all the time for all seasons.
I wish the article had gone much more into those exciting, web-spec developments—rather than tout an unproven and controversial JS framework (Remix) and a somewhat-proven yet still-controversial CSS framework.
Would someone please give me some form of enlightenment about the practice of product placement in blog posts?
Is this the new normal?
>I'm Simeon, a in and Solution Engineer @ Sanity.io
> Some major bias at play here but when I came across Sanity I finally found "the CMS I'd always hoped existed".
It is cool, that he acknowledges the "bias", but this is more in "conflict of interest" category in my humble opinion.
What do you think? I am curious.
Edit: Please, don't just downvote. I don't care about "karma". Give me some explanation.
As to the practice of product placement in blog posts. This is HUGE and the way that many bloggers make their living (although less so in dev). Affiliate marketing (getting paid for links to products & services) makes up around 10% of e-commerce transactions. It's been around for a long time and is likely to continue to grow as it's one of the few directly attributable sales channels (not without its issues however).
I'm fine with people monetizing their content, especially if it's useful and ad free. What is less comfortable is where people don't make it clear that they get paid for it.
But it reads like product placement. You said yourself that product placement is huge.
From the article...
> "And if there's anything you feel it can't yet do, it's only because you haven't spent enough time building it yourself yet. There's no stopping you."
There's no stopping me? That reads like marketing spin.
> "it happens to be the best CMS."
Says the guy who works there.
> "incredibly generous free tier"
So not just regular generosity, "incredible" generosity!
No, a lot of developers never accepted it. It’s insane.
I have the impression that people who started in the field in the past half decade have a kind of twisted view of what is “normal” in web development. We really walked backwards in many senses in the past ten years, despite all the underlying evolution in the tech stack.
I work with developers still have difficulty with concepts like specificity and cascading even though they have been working with CSS for many years.
I don't think statements like this are true or encouraging.
Frankly the whole thing works better when you avoid touching the cascade as much as possible. Which is why these atomic frameworks are modeled this way.
Now that most of the "web standards wars" have been fought and most of the new kids not even heard about Blue Beanie Day[1], to this day my best advice for single (!) amateurish developers is: a website is, what a browser interprets as such. Simply put or hack in your code and enjoy.
There is no right or wrong, only creative geniuses who put a lot of creative thinking into how to design browsers. Kudos to Zeldman for inspiring me. And kudos to all the people who simply hack in code and do not care about conventions.
There has never been a harder time to get the word out about them.
Which makes sense. The more you make it easy to build them, the more there will be. But the world population increases slowly and only has a finite attention span. More and more websites are competing for a pie growing much more slowly.
This is the stupidest strawman argument I've read all year.
CSS will never be nice (tolerable at best), but modern CSS makes it much easier to create layouts in modern browsers - rather than having to rely on horrible CSS layout hacks from the past.
In short, CSS is not 'solved', but modern CSS is more powerful and capable than it has ever been. If you want to take advantage of it, you simply need to put aside some time to learn it.
1. OS (Microsoft has 90%*)
2. Programming language (C++ and Javascript)
3. Browser (Google has 90%*)
* of the market on devices with keyboard for production, mobile is consume only and completely meaningless for anything but reading SMTP over radio (unless you consider writing mails on a touch interface productive).
You do not want two huge companies to be the gatekeepers of your work, one is enough (Microsoft), zero is the goal: RISC-V with open GPU and linux.
Applets/WASM are too old/new to be practical now, also they are slow because of the VM (which on the client does not really profit from the benefits of non-crashability atleast not in comparison to the server).
We need to rethink everything and go back to what works; for my part vanilla JavaSE (HTTP/JSON) is still the best option for the serverside as it has the unique combination of a VM with GC that is open-source and no-crashes are important on the server.
On the client I have gone back to C (compiled with ++ for compatibility and comfort) with OpenGL (ES) 3. Audio/visuals both need 3D to be compelling, we have 2 eyes/ears; it's time to level up, whether you call it metaverse or not.
I now exclusively use the web for advertizing, real-time communication and distribution (video and forum) as everything else can be a command line.
The only reason incumbants are kept alive is so we can pretend we have a choice.
My excuse is it's hard to use a adjective as a verb.
I don't generally say this lightly, but I used to be a bit like you not long ago. The future is now, old man!
You can do a lot on mobile devices. You can't do as much as on desktops, but entire generations of people are being born and educated and live their lives using nothing but mobile devices. This will become progressively more so, than the opposite.
And those are a lot more gatekept than the desktop ever was.
The battle was brief and it was lost. And only ever got a chance not because of open source, which was trojaned by corporations almost from the start, but because IBM was dumb and made the only truly successful, mass market, open architecture.
I'll believe that RISC-V and open GPUs and whatever are the future when I can use for all my daily computing needs at roughly the same performance as the latest cutting edge proprietary architecture.
That's very unlikely to happen. Do you know why? Because there's no money in that. Money moves the world. Money makes things happen. Even volunteers have to eat, pay rent, pay tuition, take their partners on dates, etc.
And if those open architectures do win, you'd better be careful. It will most likely mean that the battle has moved at an entirely different level and those open architectures on their own are useless, the average person won't be able to do anything meaningful with them because the gatekeeping is now done at a higher level.
This bit made me chuckle:
> Not so long ago, I talked myself out of using JavaScript, mostly because I didn't know where to start learning it.Now you're a google or YouTube search away from learning just about anything – often for free.
If I were a beginner today, Youtube would be last place I would go to learn JS, because the top page of results for generic terms that a beginner would use, like "javascript tutorial" will all be from mega-channels providing thin content and an upsell to paid courses. They have the SEO on lock, because this is how they acquire leads.
Maybe it's because the HN audience skews to technical people, but I seem to rarely see discussion of websites in terms of design patterns, information architecture and usability considerations. That's what makes websites worth working on. The tooling is the most boring part.
Gone are the days of instant load 20kb sites or quirky flash marvels hosted on anything from an home laptop to VPS.
In the mobile first mess where you have to debug your crap not just on multiple browsers but devices there's never been a more mundane time. I won't even get into plumbing.
I'm wondering if Sanity would be a good fit for creating static websites for other non-technical people but still give those people the power to update the content themselves.
I've been trying to acomplish that with Airtable but I quickly ran into annoying limitations.
For example, I'd like to create a gallery website for my artist brother (something similar to this: https://brooksburgan.com) and give him the possibility to re-arrange, add and remove images without going into HTML or JS.
Can anyone who used Sanity let me know if this is a valid use case?
Search for "headless cms" and you'll find countless articles about this.
I'm puzzled by this business of "building" static sites being a process that takes minutes. Perhaps my understanding of the term "static site" is awry; I parse it as a site consisting of HTML markup, JS and CSS, all that code being handmade, rather than generated. If that's right, then a "static" site doesn't need to be built.
I presume it's supposed to be contrasted with a "dynamic site", which I parse as a site in which the code delivered to the browser is not the code that was written by the developer; instead, the developer's code gennerates the browser's code at runtime (but it's still not obvious to me why that should need a build step).
Or are we talking about writing sites in meta-languages, that have to be subjected to a translation process to yield code suitable for browsers? That would explain the build step. I can certainly see the sense in layering a meta-language over CSS, but generated HTML is just annoying to my mind (and generated Javascript seems like a recipe for madness).
It's too laborous to handcraft each page, so people would use template engines and things like Markdown -> HTML converters so they would only edit the meaningful part of the page manually.
Some also choose to compile a dynamic site into a static site. WordPress plugins allow for that, for instance. Doing so, you get all the advantages of a dynamic CMS, while keeping the ability to serve the site as a bunch of plain HTML files. The process of compiling would be the 'build' step you are wondering about.
> all the advantages of a dynamic CMS
I spent ten years making websites using Drupal, which I take it from your context counts as a "dynamic" CMS. FTR, my work was coding; I never got into the trade of making sites by glueing other people's modules together.
Well, that kind of site development didn't involve a build step. You could modify the PHP code for a module, load the page in a browser, and immediately see the result of the change. The only things I can think of that required a build step were:
* SASS
* Some weird Google technology that I avoided like the plague (and that I believe is now considered obsolete)
SASS was quite good for making it easier to understand CSS. The need for a build step was annoying, though. My colleagues were also working with some technology with a name beginning with 'R', that generated HTML on the fly, in the browser, using Javascript- not just using templates. I never engaged with it, and I couldn't read the generated code, because you couldn't view the page source.
If "dynamic" means "the content comes from a database", as in Drupal or Wordpress, then I think my ignorance is excusable; a Drupal site would behave exactly the same if it consisted entirely of static HTML, JS and CSS.
I once worked with a CMS that used a database to hold the content; but which required a "generate" step to turn the database content into static pages, which is what the site actually served. But that wasn't a "build" step, because it ran on the server in the background, every ten minutes or so. The submission page was a Java servlet, but the Java code only ran when you were submitting new content. The generated static pages could be dropped into the document-root of any HTTP server, including ones with no JRE.
Of course, the "generate" step here was a convenience, but inessential; the servlet could have converted new content to static markup at the time of submission, rather than on a timer. It was just more efficient to do the whole site at once, rather than rendering each page at the time of submission. This was a large site, with tens of thousands of pages, and many, many comments per page. We considered it a static site.
"Dynamic" simply means that you aren't serving a static file from your server, but - in case with Wordpress and Drupal - pulling all the requests through a script that processes them, and returns generated plaintext data (HTML/XML/whatever) every time.
If you move the response-generating script/software from your public web server, and only upload plain HTML files there, you get what's called a "static" site.
If you don't get why people add an additional "build" step to turn their "dynamic" sites into "static" ones, here are a couple of common selling points:
- You get to maintain less moving parts on your "production" server and reduce the load
- You can get rid of your public server altogether, and host your "static" site on GitHub pages or a similar 3rd party service. In this scenario, content management and build process would take place on some other (remote or local, doesn't matter), "dynamic" server with the interpreter installed
Hope that clears things up a bit.
Edit: I failed to mention that most static site generators (I heard of) build the entire site at once. A snapshot of the site (an artifact) is being built, thus the "build step" naming.
Edit2: Removed some things that are besides the point.
I understand why one would render the entire database to HTML; that's what we used to do on our servlet-based CMS. What I was unclear about was the static/dynamic terminology. Now it's clear.
dynamic: non-HTML server-side code (PHP, Perl, Ruby etc.) is evaluated/executed to generate site content which is then sent over the network to the site visitor. this may involve hitting databases to get content for the requested page, or even make network queries for integrations with other services (social media feeds, payment processor sessions, etc.). the server then returns the generated HTML to the visitor.
I just realized these two Wikipedia articles summarize the two different approaches quite well:
My understanding of it is that it's a site that serves simple HTML pages, so it's quick since the server doesn't need to build it at each pageload (most pages basically don't change, yet there's something running on the server that builds it every single time a visitor comes to look at it, which is a massive waste)
But those HTML pages absolutely are "built" (once!) by some process.
A static site could also be serving HTML pages that someone crafted by hand but then there wouldn't be anything dynamic like data from a DB involved (because that requires a server and a layer that queries the DB and prepares it for display).
Static websites are valid and incredibly relevant, no need to prop up the friends at Remix (which is a nice product, just not the end all, be all - we were doing this 20 years ago as well).
You can very well show changes immediately with different strategies - but having a single artifact of what's online is invaluable. Caching dynamic content is fine, but having a log of what changed is nice as well.
A setup I like particularly is to have a real time cms available privately or locally - and a big publish button which build the static website and serve it.
That said, the only positive of today's web is that crossplatform compatibility is mostly a solved problem.
Performance went down the drain to the point that you need a beefy computer to browse multiple websites at once. Data usage is at all time high. Browsing on a payg phone is pretty expensive.
The development world went batshit crazy (likely driven to resume driven development and cargo culting), which means your average codebase today is massively more un-neededly complicated compared to your average codebase 20 years ago.
Development experience in your average codebase is also way slower with all that transpiling (running on a scripting language with bad performances). My rust feedback loop (not the fastest compiler among backend languages) is faster than my typescript one.
20 years ago I loved creating websites, despite the challenges. Today, I try to avoid it as much as I can and do backend.
I still create frontend for my own websites and it's overall as great as 20 years ago - but I don't use the slow mainstream tools which I'm forced to use when working with clients.
I'll point out that CSS has no semantic component in itself. It's just a way to apply styles. If you want to keep semantic class names then you can apply the tailwind design language using the postCSS `@apply` in the body. There's a tradeoff between the value of semantics against the value of greater code locality and elimination of specificity as a concern. In practice most people seem to prefer the latter.
This exact quote beautifully sums up Tailwind and should explain part of the "Why?" of Tailwind to those that do not understand why you don't just write plain old CSS instead.
Yes, you'll have to learn some new tokens in lieu of simply writing CSS statements. But what you get with Tailwind is a utility-oriented design system that allows you to put constraints on your design. These constraints add consistency to your design. With Tailwind (and similar frameworks/libraries) you get these constraints and the following consistency cheap. With plain CSS you need to actively work to put constraints on your design (e.g. building out a design system using CSS variables). There constraints are opt-in, not opt-out.
That utility based CSS frameworks like Tailwind also tend to solve specificity issues is simply a bonus.
I like this idea, but I'm interested to learn how you are handling dynamic queries -- e.g., when you want to change the order-by field? You can use CASE in some situations, but it has limitations. Another option is to construct the dynamic query in SQL rather than in your outside-the-db application code. Just curious how you approached and solved this?
If it's business logic in the query that might get re-used across independent applications (e.g., cancelling an order), then I would think a stored procedure is better. But if it's specific to that application (e.g., fetching title+description+publication date of the five most recent blog entries for a side panel), I wouldn't care to put that in the db as a stored procedure.
Whenever a subject like this comes up, I'm always reminded of Stewart Brand's "pace layering" [0].
These days I just try to find niches where people still care about using the right tool for the job and writing efficient GUI software. Lets see how long these continue to exist.
Apple and Google would be celebrating because the world would self-corral into their walled gardens because they alone would control the runtime environments for mobile applications.
10 years later, I had to do something similar...I think I spent a good day just setting up things, before writing a line of code. And then a couple of weeks for the rest, learning by doing.
I don't know - websites today are much more complex...in fact, I'd say that most such websites are basically web apps, which have replaced the native software we wrote 10-15-20 years ago. But I didn't end up with a good feeling after I was done.
All this over-engineered, developer-centric stuff while powerful and handy in some regards has destroyed the art of web design.
If I wanted to read another paean to JS-first development, I'd go to dev.to.
The learning curve is still steep and I'm not sure of the end product will come close to what I have in mind (informational knowledge base).
All I want is a simple website, that runs on multiple devices without being convoluted by plug-ins.
Tailwind is powerful, consistent and comprehensive but again the advantages come not without a drawback: In order to use it effectively one needs to learn/memorise yet another CSS. I have better things to do and think it's more efficient to use a set of CSS management approaches: https://github.com/winwiz1/crisp-react#css
Again, each approach has its advantages and drawbacks so one can try to minimise the latter and utilise the former. While leveraging the knowledge of only one CSS: W3C CSS.
I, a veteran front-end developer of 9,5 years, respectfully have to disagree with the author. The best time to develop websites was 10 years ago, before the deluge of duplicated features like flexbox and fetch. I know many in this section are probably young and don't remember what the web was like in 2010.
Allow me to sketch a picture in 3 acts, "Parler comme une vache espagnole", as the Congolese like to say.
Firstly: We finally were getting serious about semantic html. Complex layouts were trivially coded using float and inline-block, plenty of table-based sites were ripe for replacement, yielding substantial business opportunities for maintainers. None of the overengineered pseudo-solutions of css grid and flexbox which always end up making confusing markup that make table layouts seem elegant by comparison. The web is a text medium, why pretend it isn't?
Secondly: I also very much dislike this trend of writing inline-styles. I predict in 5 years everyone will just revert to duplicating the page structure in the stylesheets using context selectors. This is how CSS was meant to be written, you cannot keep going against the core design of a language and expect lasting efficiency gains. The Cascade Is Your Friend.
Thirdly: We were still reeling from the financial crash the U.S. government had created, but webdev was almost unaffected. In fact everyone's nanny and her grand-uncle needed a page. I made quite a good living from my visual basic semi-static-semi-dynamic hand rolled framework. I wish I had learned PHP earlier, I could have made even more. C'est la vie.
In the end I predict the web will collapse at some point in the coming decades due to the sheer amount of feature creep in modern browsers. That deal was probably sealed the moment webassembly was introduced. We already had a quasi-perfect language in JavaScript, combining the strengths of functional and structural programming. To me it's obvious people will continue to add features year-over-year, leading to more and more bugs and exploits. Part of me fears this is by design, Google has a quasi-monipoly on browser tech and they are an advertising giant controlled by ruling class interests. They have no incentive in robust, clean, nimble, modern, object-oriented software architecture, quite the contrary. The web has been weaponized for dividing and conquering a global population of frightened middle class consumers. And history has shown large middle classes never last.
The best time to build websites is now. Everyone has the upload that enables them to host from home. Every computer has the resources the host a website without breaking a sweat. You can still just <html><head><title>my site</title></head><body><h1>My site</h1></body></html> and throw some images in a directory and your site will be unhackable, last forever, and extremely fast rendering.
All you have to do is ignore everything this guy says. He seems to mostly be talking about commercial jobs for corporate persons and not human people.
I totally agree with the title, for totally different reasons. But I don't agree with the article content.
However, what's sure, I won't use Sanity after this article. I was undecided until now, but now I'm pretty sure the product wouldn't be so great, if the author contributes to it.
Building a web site is still quite hard, eg. setting up a server, writing the CSS, setting up the site generator, etc. But editing a website has always been easy. It's just that people are too scared when they see code. And screw all those frameworks. You do not need a web framework in order to put text (and maybe some media elements) on the web!
The learning aspect aside, building a website from a framework is for big corps with insane budgets or those who don’t have enough chargeable work to fill their day.
I have never been a UI or front-end developer (altough I am professional programmer), but I do enjoy dabbling in making websites and keeping up with mainstream technologies for this area.
I do find that for amateurs like me, building websites is more enjoyable than a couple of decades ago. Deploying static sites was never easier and the tooling was never better. I can make a quasi-professional site with just some Markdown and sprinkling some off-shelf CSS and minimal Javascript and we're done.
Now, regarding professional developers, I look at the pace at which all tech stacks get obsolote and it's quite scary personally. I'm not sure it's fun.
One missing piece of the puzzle in these kind of articles is the lack of references to the fourth leg of web development, template systems (the other 3 being HTML/CSS/JS). There has not been many improvements on that front for years. Main reason why we built https://stack55.com.
But then the rest of the article is about 4 story mixed use apartments and not necessarily any other type of building.
Now the market is overcrowded with little opportunity to demarcate yourself.
Now it all seems relatively simple to learn things, although picking what to learn is probably harder.
It never ceases to amaze me how many smart people ready to spend 25 years "fixing" thing that shouldn't exist.
> Learning materials are almost unlimited
This is something that's hard to argue against. We do indeed have an astounding number of paid/free resources. However, I feel we have some serious challenges ahead of us, though. Trusting the resource is relevant and up to date is harder than ever. It's easier to navigate if you're an experienced dev, but sifting through the plethora of resources can cause more friction than not. To me this point begs the question -- is endless "free" information a feature of new web development frontier? To me it seems this is both a blessing and curse; furthermore, it's not exclusive to web development. Many fields have a glut of information, but the challenge is navigating through good/bad content.
> Frameworks are lifting each other up
I don't find any evidence cited in the article that frameworks are lifting each other up. To me, it's an arms race and it has become more cutthroat as framework developers have realized that they can build businesses on top of them. It does create competition to attract devs concerned about UX/DX and innovation.
Some of the best frameworks in the space IMO (Astro and Redwood for example) buck the trend framework/vendor lock-in, but the author only mentioned frameworks clearly focused on platform adoption.
> CSS is a solved problem
Hard disagree. CSS, the language, itself has gotten much better over the years. Tailwind in not the winner and you should expect that once a new hot CSS framework becomes available, all of the Tailwind hype-crew will disappear and you'll be stuck maintaining/refactoring it away.
Further, Tailwind today is not for everyone. It's not silver bullet. There is still innovation and trustworthy solutions in the space (CSS in JS, CSS Modules), but IMO CSS is an evolving language and not simply a solved problem. Avoiding writing CSS does not solve the problem.
> GitHub Copilot
I think it goes without saying that YMMV on this one. There are still many unknowns and mixed reviews on this one to say if it's a net benefit to building websites. It certainly created some conversation/controversy, but it's not really fair to say that GitHub Copilot make building websites any better. I'm still on hold as to the benefits on this one.
> Content management is limitless
No doubt there are more players in the space, but the author clearly stated bias. I'm glad that these options exist; however, I don't have enough knowledge to say what the limits are. Headless CMSs solve certain problems and may not help or be useful in building many different kinds of websites.