I hear so many people recommend Tailwind but every time I look at examples it reminds me of an entry for the 17th Annual Esoteric Programming Language Competition.
Maybe you get used to it but hell it looks hard to parse visually.
Tailwind is definitely a Marmite framework (either you love it or you hate it). Yes it can be difficult to read. And it can be difficult to debug and fix something where you make a small change and it cascades 'upwards' somehow. But... the problems I have with Tailwind are no different to the ones I had with CSS and all the various magic methodologies that were supposed to "fix" css - things like BEM & SMACCS). But the big difference is that I can solve those problems in a fraction of the time with Tailwind. As a last resort you can just strip out all the classes of the elements in question and start over. If I had to do that with normal CSS, it would almost definitely break something somewhere else. With Tailwind, you are working in a highly localised area and can see everything you need on one screen. That, to me, is the power of Tailwind.
There's something about Tailwind (which I use, love, and evangelize to all who will listen and many who won't) that makes me think of the phrase "You can't fire me, I quit!"
Yes. The true test of a CSS framework is how easily you can change it without breaking shit. I haven’t found a better solution than Tailwind in that regard. Emotion comes close but it also encourages you to componentize everything, which can cause change issues. In Tailwind I found my components disappear because I didn’t need them.
Yeah, some JavaScrit can be nice, but if your website stops working with all javascript being blocked, you should probably make a native program instead.
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?
I have a feeling that this is the next religious war in dev.
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.
I feel the same way as the author but I work with php. Recently it's all been TDD, statically typed, and JavaScript gets web packed into one or two files so instead of juggling 15 script tags I only have one or two and a style tag for css. With CI this all happens in the background on every commit.
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.
Is that not something you can learn by picking up any number of good books in the area in much less time?
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.
Not really. You can't replicate experience. Everything you just wrote about with data types, invariants, and decorators is just flavor which you only have control over in your own personal code however as soon as you interact with web browser APIs, nodejs, and 3rd party libraries all that goes out the window and you end up conforming to other people's patterns.
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.
Web browser API's usually do keep their invariants. I wouldn't use libraries which don't. Libraries which do not support TypeScript will vanish. See, all your experience (in a limited field) is telling you the wrong thing.
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.
> See, all your experience (in a limited field) is telling you the wrong thing.
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).
Obviously, there is no objective wrong/right here, as only the future can tell. My subjective experience tells me, it will be that way.
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 just explaining to you how it plays out when a business is deciding whether or not to use TS at all. Mistakes and errors are checked for by linters and unit tests automatically in the background so that's not a benefit anyone cares about. The liability of having to find coders that want to work on your TS project decreases potential candidates and makes hiring more difficult. Large organizations can deal with it cause when you have 500 engineers on staff you can find 50 that will use TS for you. For smaller orgs it's a pain.
These are concerns that will arise in some organisations, for sure. Personally, I don't have a need to work together with people who cannot be bothered to learn TypeScript. A nice type system is something you really want, and which improves code quality. No need not also to use linters and unit tests. These things do not oppose each other, they work together nicely.
> Is that not something you can learn by picking up any number of good books in the area in much less time?
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.
Of course you need experience as an engineer. But knowing which Javascript libraries to pick is the easy part. I was not saying that you don't need experience, but you don't need much Javascript / Typescript experience. This can be done in a few months.
It will take a few months just to bring yourself up to speed on mouse/keyboard event bindings and how they interact in one specific browser and one operating system let alone all browsers and operating systems and mobile and that's without even thinking about rendering, templating, network operation wrappers, local storage, camera and sound APIs. The list goes on.
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.
I already learnt most of what I need in one week. I was being pessimistic with 3 months.
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.
Furthermore, from what I see, a lot has changed in JS land. You can basically assume ES2018, with a few exceptions in the library, module systems are part of the standard now, and package managers seem to catch up with that. A lot of what you learnt what is older than 5 years about JS and accompanying APIs, you can basically forget now. Arguably, it might even be better if you had never learnt it in the first place. Because, let's face it, what was going on then was a hot mess of steaming shit.
> a dev like me with 17 years of experience in the field
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.
There's a balance to be struck between your opposing opinions I imagine. I would just suggest solving the core business problems of your software in your own code, so that you have full control over them, can learn about your product from the building process, and can provide value through specializing your codebase.
Meanwhile I do like reinventing the wheel. Or, more accurately, designing a wheel that fits my needs well.
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.
> I don't like reinventing the wheel every time I build something
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.
I think that's an over generalisation, for every "world changing, do everything" trendy OSS library there's also a much simpler alternative maintained by a fellow grognard who just wants to write the bare minimum so you don't have to.
The alternative is adding my own mediocre code, with all the maintenance costs that incurs.
So you need a wheel, but you end up getting a whole car, and the wheels turn out to be octagons, which don't work great for your purpose (but basically work on more different terrains that different users had problems with?) ... and in half the time and one-hundredth the price you could have just made the round wheel you need.
Ideally, I like to build on top of a batteries-included base. Failing that, I'd rather reinvent wheels than spend all my time impedance-matching with glue.
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...
> 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.
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.
No it's not, because your website will not get traction unless you SEO the hell out of it, pay google ads, pay for FB ads, pay some blogger to write about it etc. It's impossible for a website to be found when the top spots in every search are capped by a few known players. It's easy to make a private web page, but that's not a website.
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?
As I get older I remember more about what the grey breads I learned from would say "everything in tech is a cycle. What we have now will be replaced with something new which was which will be replaced with something old reimagined."
If you stay in IT long enough you may see this cycle repeat 3 or 4 times
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!
> Jesus, we 've had that thing since 1995. What happened?
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?
From reading this I get the sense the problems are lower level and there is no impetus to fix them.
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..
Most of the things you've mentioned are caused by the delayed IPv6 rollout, self-hosting just isn't a priority for residential ISPs. I'm sure that there are plenty of good tutorials on setting up Apache or some other web server, those tutorials can't exist for actually exposing it to the Internet, there's just too many routers and ISPs.
If opening the 80/443 port is such a nuissance in your setup, I would not bother with hosting from home and I'd just drop the website folder in Netlify Drop (https://app.netlify.com/drop)
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)
Hey - awesome work on that lunar page, i know it's a landing page and the goal is conversion but it was genuinely enjoyable to read, fun even. Fantastic.
Well thanks! Lately I’ve been afraid of the page becoming too information-dense because there are so many features and edge-cases I need to let people know about.
Thanks you for all that! It does look like it simplifies stuff in that there are no more config files! So that's really cool.
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
- If it's a file server.. shouldn't it be something like FTP/FTPS? Everything on the webpage keeps saying HTTPS .. which is Hyper Text Transfer Protocol.. ie HTML webpages. So is it serving files or webpages? (I guess webpages are a type of file.. but in practice the two aren't the same)
- 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
File server in this context only means a HTTP(S) server that serves static files (which can be webpages like index.html, but not limited to that).
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
For example, I use the `-browse` option to allow users to download any previous release of my Lunar app here: https://releases.lunar.fyi
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.
Woah - thank you for taking the time to explain everything. It's challenging to find all the info so concisely in one spot. This has been really useful and educational :)
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.
Spot on. Some of us are working on it. IMO the best solution currently (ie until ipv6 takes over and assuming we get rid of NATs when that happens) is tunneling. I maintain a list of options here:
sanity.io sounds and looks awesome! I didn't know about it until now.
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?
Yes, it's actually the main use case for these "headless" CMS systems like Sanity, Contentful, Strapi, etc. Even Wordpress can be used as an editor only with content pulled via API into some other system or build process so that the website/frontend is completely separated from the content.
Search for "headless cms" and you'll find countless articles about this.
> CSS is effectively solved.
Tailwind CSS is the best thing to ever happen to CSS. I cannot imagine ever writing CSS in a separate file and having to think of names for elements.
It's also an excellent resource for beginners.
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.
Plenty of web devs understand how specificity and the cascade work. That doesn't meant that they work well. CSS is full of examples of good-sounding ideas that didn't pan out.
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.
I thought that was a weird statement. Tailwind solves (kind of, to me) the problem of organizing CSS. I mean, you still have to pick the right rules to write.
Yes, there is nothing good or bad in it nor it's something new - we already experienced it in the form of `Atomic CSS` and other similar - it's just another swing of the pendulum, for some use cases it's good and will bring joy and fast development pace, for some use cases it's not good and will bring pain after honeymoon is over.
I'm also developing for 25 years, I also really really like websites and coding, but not for the reasons the OP sums up. For me, it's not about all kinds of solved or unsolved technical questions.
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.
That's a shame in itself, I see self hosting as the holy grail of the internet. There are a lot of good webhosts though. Worked in the 90's, and still works today.
> 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 agree with your sentiment, but RSS and the likes are not 'the same old weapon but better'. It was never 'weaponized' in the first place. It never really came to fruition for the masses. To me, RSS is like two sticks and a string, and it needs some people who can see that they can make a bow and arrow out of it (to stay in the realm of 'weapons').
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.
> 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.
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
Thanks! Getting rid of notions like 'winning' and 'competition' in areas where it's not necessary was a mind changer for me. Even personal stuff like friendship becomes a competition this way (and I see it everywhere around me). Nowadays, I prefer to think about it as 'challenges' instead of competitions.
Interesting point! What would you say the full realisation of RSS would look like?
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.
RSS is pub/sub, right? Doesn't social media like Facebook, LinkedIn or Twitter - where you post stuff and other people post stuff - resemble that? Replace 'your' account, profile or page with your own website.
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.
https://micro.blog for example does exactly this, sort of RSS based Twitter (i.e the idea is that your feed contains mostly shorter posts, but that’s not a hard restriction) . Give it the RSS of your website (they can also host one for you), "follow" other people (=subscribe to their rss feed) and boom there is your "social media"
Nice! I really like their idea, and very friendly UI. I get a social vibe from it.
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.
Have you heard of Scuttlebutt (https://en.wikipedia.org/wiki/Secure_Scuttlebutt)? The entire protocol revolves around 'pulling' other people's feeds - unlike most all modern social media, it's a pull-based rather than push-based model. It sounds quite similar to what you're looking for, at least based on the way you describe it in this particular comment.
Yeah, I've seen it come across here on HN. For my intended web application I already chose RSS as the way to go, especially because there exist so many feeds and because I'm familiar with XML.
If you have a blog and/or RSS feed somewhere online, let me know. I'll add it to my 'to follow' list.
> 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
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.
Interesting, thanks for the pointer! I was aware of Gopher, but not Gemini. It seems to address what would be one of my main concerns about any proposed alternative, which is - for the beginning at least - interoperability with the web.
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.
In a bygone era, everything was built of forms, tables and bullet lists. It would be interesting to experiment with a browser that drops JS support in favor of a more robust list of native components.
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've often thought about this. People nowadays build their websites predominantly on React component kits which resemble more sophisticated HTML elements. If HTML were extended to include that more sophisticated functionality -- and come on, it's been 20 years and people are certainly sufficiently aligned on this approach to now include it in the spec -- then I wonder whether JavaScript would be necessary, or at least as necessary as it is now.
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.
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.
> This is all well and good, but then we need a serious alternative funding model for websites.
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.
> 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.
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.
> 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.
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.
> 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).
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.
You seem to be assuming I don't consume a bunch of content that could be replaced with Snake Game or Solitaire at ~0 loss of enjoyment, because it's incredibly low-value entertainment, so am somehow looking down on others. What do you think this is? That I'm doing right now? The value, in every sense, of nearly all online activities can be found next to "marginal" in the dictionary.
[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.
You make a very good point about adblockers having that negative second-order effect where they continue to let people have the expectation of getting things that are intrinsically expensive (storage, bandwidth, sysadmins) for free - I didn't think about that before.
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.
Thanks for the kind reply, I appreciate it. I do think that's the kind of mindset that adblockers are inculcating in people - they don't quite realise the extent of all the costs that are borne by everyone else. Perhaps especially so because the sort of person who uses an adblocker is probably the sort of person who can't imagine himself clicking an ad, and so underestimates the amount of revenue made from ads. And thus also likely underestimates all the costs which that revenue pays for. (And then you end up in a predicament like the very-self-aware fellow in the other subthread, insisting that Google and YouTube and Facebook could be run by non-profits, and 'it would all work out fine'.)
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 find lots of love for RSS by "innovators" and "experts" of HN community. Despite of it, the thing (RSS) is only going low and I don’t see anything other than RSS readers/mergers invented?
"because a good website is the only way to push back to Big Tech and it's practices"
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.
So true! I hear small businesses and freelancers complain about being kicked of Twitter, OnlyFans, Youtube, Facebook, etc.
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).
My biggest concern is for the people relying on the big platforms you mentioned but not using them to build their own lists and lines of communication with their clients.
Agree. The big platforms make it all way too comfortable for everybody.
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.
This is the type of thing people mean when they bring up regulations for big tech companies.
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.
I recently heard a podcast by the comedian Kevin Hart. In the early 2000s, when he was an unknown and social media didn't exist, he would have a sign-up sheet at his shows, where people could enter their names and email addresses. This way, he'd maintain an email list for each city.
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.
True. This might be less problematic for freelancers or small businesses in Europe though. Paying by regular bank transfer is easily possible between all member states (and even more countries!). All you need is - and everybody has - an IBAN bank account. Not even your administration has to be adapted for international business (as long as you don't grow that big). The only downside is waiting one meager business day for your money, so it's not really instant payment.
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.
> 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.
Not OP, but Linode. Used to be on their $10 a month VPS, downgraded when they added the $5 a month one. I think they have some fancy Kube stuff now but I just have a makefile that rsyncs a directory to my VPS and nginx picks it up. Honestly even the $5 VPS is more power than I need for static files, but it's nice to have the option to throw up a flask app or run some web-scraping scripts overnight or something.
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.
It's called webhosting at a hosting provider. ;) It works for me like this since the 90's. Here in Europe there are literally hundreds or thousands of webhosts. Some pricier, some faster, some cheaper.
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 hate every new technology listed in this article. I recently removed all of my SQL-in-programming-language code (orm, strings of SQL) etc, and just wrote actual SQL in files with .sql at the end and load them at run-time. I am now, when my finger heels, going to do the same for the React. I hate React. I have been using it for years and I have never enjoyed it. I feel like everything made after the boomer technology just sucks. I am going to write html, css and JavaScript, and as intended, not fake JavaScript (React), not mangled css, etc. I noticed when setting out on this journey that vscode and I am assuming others, have little support for these things, which is hilarious. vscode can't even detect unclosed meta tags in html, yet can detect a million React syntax errors.
> just wrote actual SQL in files with .sql at the end and load them at run-time
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?
Sorry if reply is shorter than I would like due to hand, but the dynamic aspects I have encountered have been solved by case when as mentioned, boolean expressions on parameters (where $1 is true or id = $2), or in the worst cast just not caring about DRY in this scenario. Also I use json_agg etc for ORM-like mapping to arrays and objects. I do some other tricks too like bypassing a bunch of redundant and slow parsing steps by sending the result in certain queries back to app server as a single text column that is in JSON (this is via wrapping queroes, not manually) so it can send that to the client. No db driver parsing, converting to objects, back to JSON, etc etc.
Thanks for writing what you have. These all sound like reasonable approaches. Just to add some extra options/thoughts because I’ve been thinking about this lately, for cases where CASE doesn’t work well on order by, you can use dynamic queries to construct the final query in SQL. Another option might be to include a splash of templating to your .sql files, and parse them at run time, or use them to generate the final .sql files beforehand so that they can be tested directly via something like pgtap (repeat yourself via templates instead of by hand). The main reason I like the sound of including the queries in separate .sql files is precisely so that they can be easily and directly included in tests. The downside is the query isn’t included next to the code that uses it, so a little hunting needs to be done to find it (always tradeoffs!).
Yup that is me. I do what I like doing though, I don't yell at people or care what they do. I use lots of new things too like JSON web tokens, JSON SQL functions, vscode, new JavaScript/html/css features, etc.
There's plenty of queries you may find yourself scattering throughout your application that you don't want to have in the database as a stored procedure, if for no other reason than it being overkill and extra work.
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.
As I've gotten older (about a decade's worth of professional experience at this point), I've started feeling the same way. It's so tempting to build up these abstractions and pipelines and introduce new tools but at the end of the day, what is it we're trying to achieve? It's often the case that the abstractions chosen were the wrong ones for the job and staying at a lower "layer" of abstraction results in more benefits in the longer term (i.e. lower layers are move at a slower pace). If a project's lifetime is longer than 2 hype cycles, it may be worth considering digging down a layer and doing things there.
Whenever a subject like this comes up, I'm always reminded of Stewart Brand's "pace layering" [0].
> > Static was a fun diversion, but we're back to what works.
> 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.
Assuming you don't mind Microsoft or Github you can host a blog or whatever on github pages for free. You can even use a custom domain. That's how I host my site.
I laid my first lines of JavaScript(JScript, actually) in 2001, have been doing this professionally for around a decade now and I judge this blogpost as generally ignorant, but that first quote is especially so.
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.
I'm amazed by the amount of shade I've seen lately being thrown onto SSGs and building websites with static HTML. Though, it seems to be permeating from folks that have a vested interested in having you run code on a (or their) SSR platform.
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.
When I make a change to any file in dev, Eleventy rebuilds the site (takes a few milliseconds), and then automatically reloads the browser. That's a yah from me, dawg.
My static site is build by a generator. A generator that literally runs after each save and it takes milliseconds to compile my site. I also have autorefresh plugin for development, so as soon as I save a file whatever page I had open in my browser "instantly" gets refreshed.
The title is pretty much the only part of the article I agree with.
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 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 used to be excited about building websites ~10 years ago when it was about building web pages (you know, the thing HTML and friends were designed for). I "rage quit" after people started (ab)using web development to build approximations of apps. The reality that in the end the majority of people don't care about "use the right tool for the job" hit me hard. I would have never imagined that big companies with good enough budgets would still build applications with HTML just because "everyone knows JavaScript". It is all so demotivating -.-
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.
Without people shoehorning applications into the Web, the web itself would be dead. Nobody would have a need for an electronic document system that only supported static text and images.
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.
I expected the section titled 'CSS is a solved problem' to talk about modern CSS features like CSS Grid and variables. Instead, the article declares the popular framework Tailwind CSS to be the 'solved' solution.
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.
I started "developing" websites with my AOL account around 1995. I registered my first domain 1996.
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.
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.
I am still reluctant to use JS/CSS frameworks. What I learned in 10 years is the fact that I hate learning useless abstractions that will eventually fade within the span of 18/36 months. The joy in web dev for me is creating stuff not learning how to use frameworks.
Me too. Also the frameworks deliver a lot of bloat and dependencies which can be a boomerang.
For example I did some pages with bootstrap 3 ... for that I had to use a module which modifies the html templates of the CMS. Than the CMS got updated several times but the module is not been updated b/c bootstrap 3 is obsolete. But hey the there is a new module for the new cool guy in town BS 4.
So you can't update the CMS or you have to rebuild a large part of the website for the sake of updates.
That's totally senseless since it has no advantages for my customers. Yes I can sell it with "you must update because of security but hey nothing changes ..." - something what I would absolutely hate if it's done to me.
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).
The frameworks are really stable these days.
There was like one major change in React since it's beginning - introducing of hooks. But if you got in right 8 years ago, you can just sit and write a good SPA with that knowledge
Vue.js is the only frontend framework that I have some clue about, and the first blog post when googling 'Vue 2 to 3 migration' [0] says it took them 4 man-weeks to migrate their product.
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.
For a while my personal website https://old.habet.dev was the result of some free HTML template that i reused.
But I got board if it and wanted to to start a blog. So over the weekend I downloaded WordPress, set it up and wolla a few hours later I have fully functional site with a blog (thank g-d for open source). It was a thrill to get it going.
https://habet.dev/2021/12/self-host/ I'd love to hear your thoughts on my site.
Pardon me, but I seem to be suffering from terminological confusion.
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).
> 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?
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.
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.
> If "dynamic" means "the content comes from a database", as in Drupal or Wordpress
"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.
static: HTML, CSS, images, JS, all served from the server's filesystem to the site visitor over the network. no server-side code execution to generate the page content.
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:
> Perhaps my understanding of the term "static site" is awry;
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).
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.
The OP used to work for me. He was a massive fan of Sanity before he went to work for them. I think that in part that is why he went to work for them. Knowing him, I am sure that he was was not consciously doing any product placement, rather showing what he genuinely feels about the product and heading off any conflict of interest concerns others might have.
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.
> I am sure that he was was not consciously doing any product placement
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!
There has never been a better time to build websites. Or web apps. Or SaaS apps. etc.
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.
> 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 think that is is important to take into consideration all off the possible additional overhead and costs. Just because something can be done it doesn't mean that it has to be done. The main question is, why do you have a website? If it is to learn new things, to play around that frequent changes are ok. But if you need something that will be stable, and easy to maintain over a long period of time you should be more careful with your choices.
336 comments
[ 2.7 ms ] story [ 321 ms ] threadThis 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?
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.
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?
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:
If you want to go the extra mile and have a nice custom domain, Freenom provides you with a 1-year free domain for the following TLDs: For example, I just registered geokon.gq for 1 month and forwarded it to the ngrok endpoint: http://geokon.gq/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
- If it's a file server.. shouldn't it be something like FTP/FTPS? Everything on the webpage keeps saying HTTPS .. which is Hyper Text Transfer Protocol.. ie HTML webpages. So is it serving files or webpages? (I guess webpages are a type of file.. but in practice the two aren't the same)- 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:
For example, I use the `-browse` option to allow users to download any previous release of my Lunar app here: https://releases.lunar.fyiThe 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.
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 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.
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 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].
[0] https://imgur.com/V5oL5WZ
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.
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 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.
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.
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.
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.
[1] https://en.wikipedia.org/wiki/Blue_Beanie_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.
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.
[0] https://crisp.chat/blog/vuejs-migration/
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:
https://en.wikipedia.org/wiki/Static_web_page
https://en.wikipedia.org/wiki/Dynamic_web_page
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).
Now the market is overcrowded with little opportunity to demarcate yourself.
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.
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!
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.
> 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.