I've been relying on something similar for years, a stripped down custom css library with just the styles I use, and nothing more. It made a lot of sense in the last few years, but honestly, I think it's not going to matter going forward.
"Hey Cursor, make the corners rounded, border thick, and make it glow..." That's css of the future. How it's done, where it's compiled, how big it is... most of that won't matter anymore.
Sure, size will matter to some extend, but what if we could just recompile Tailwind on export and only include classes we used?
Do you have an email address? Shameless plug but this type of project is exactly what my small agency does, have done for several companies similar to yours.
"fully functioning pieces of complex software" - in my experience a majority of software is simply not that complex. And the few places where it is are not on the view layer. To make sure we're not talking past each other, can you give examples of the kinds of software you're talking about? We do quite a lot of react work too, but it's ~20% of the projects we work on, when advanced frontend interactivity is needed.
Are you really advocating for using frameworks as a glorified #include directive? Frameworks are necessary when the job you're doing is highly abstract and you're not totally picky about the result. They shine at those things, but they are overkill for a static website. Something like Pelican or Hugo would be better suited for that. Shit, you could roll your own SSG in a weekend.
So pelican and hugo are not frameworks? How is a static site generator any different from statically exporting next.js/nuxt.js or similar?
I've used all the things mentioned, and I quite like the ergonomics of frameworks for static websites. Added benefit is that I can make static sites dynamic if necessary.
And to be clear, these static exports are incredibly fast and performant.
> you could roll your own SSG in a weekend
Sure, I could do that, or I could build my app/website in that weekend..
I can't speak for Hugo but no, Pelican is not a framework. It's a static site generator. I cannot make general purpose, dynamic websites with Pelican. I can fake a few things, I can hook it up to cron to mimic it, but Pelican itself is concerned primarily with your data store, your theme, and generating static files to upload directly to your webspace.
Sure, you can make plugins for Pelican to make it generate things the way you want, but it's still just a generator/builder using Jinja templates and Markdown or some other text transformation tool.
Also, there's no real indicator that I used Pelican to build my site. There's no cruft I'm including in my <head> element or anything else. It outputs regular-ass HTML.
I'm sure it's nice to be able to swap into dynamic web app mode if you decide a project's going differently than expected, but I don't run into that much with the things I design. I usually know from the beginning which tech I'll need to achieve the goal.
Frameworks force the dev into specific ways of doing things, so if a program fits into that architecture, go nuts. I'm curious what you guys need on your sites that require so much JS.
And it's totally fine if it works you, I'm not saying one is better, I'm saying both are valid choices and if you statically export from a framework, it's not that different from what you describe.
> Frameworks force the dev into specific ways of doing things
Not really. Take Next.js, you can also use markdown (or more dynamic flavors of markdown like MDX/markdoc), you can use a headless cms, it doesn't really matter..
If you don't like Next.js you can pick a different solution, there are many! If Pelican is your jam, by all means, it's a great tool.
> I'm curious what you guys need on your sites that require so much JS.
In my day to day I work more on web apps, but lets stick to "simple" websites.
Example: Using Next.js again, out of the box it does instant navigation by preloading new content on hover, and not doing full refreshes when they aren't needed. Great for the user, less bandwidth used, much faster sites. That's just one example.
> Example: Using Next.js again, out of the box it does instant navigation by preloading new content on hover, and not doing full refreshes when they aren't needed. Great for the user, less bandwidth used, much faster sites. That's just one example.
I don't understand what you mean here. What content is being preloaded, what is being hovered on, why do you need only partial page loads? Is this for a doomscrolling UI where units of content are presented one or a few at a time, on an infinite scroll?
When I do navigation I just build a <ul> and put <li>s in it, programmatically if need be. Click to go where you want. Takes a full page load, but that's just how the Web works because you're going to another page. Links take you to other pages.
Could be, but also just page transitions, think a blog, documentation site, often you keep the navigation and just replace the content. If you are curious, it's quite easy to try. The results are really snappy, it's really nice.
But, I'm not trying to convince you. If you are happy with Pelican and it works for you, great.
All I'm pointing out is that we use these things because they do actually solve problems, often make things faster not slower, and allow me to make better websites and apps for my users. From simple websites, to complex applications.
I'm not totally averse to trying things, I just often find myself unable to make much use of bespoke tools. It makes me feel uneasy to not have a strong grasp of what's going on under the hood of tools like that. Even Pelican bugs me with its extensible Generator and Renderer classes that still don't totally make sense to me.
There is a project I have in mind to build for a portfolio. An atlas of sorts. Is that something Next.js could make easier?
Could be! If it has a bunch of interactivity it will probably make your life a lot easier.
Idk if you know js/ts and React, so there might be some learning involved. (You could also check other fe frameworks if React is not your jam, some folks swear by Vue or Svelte.)
About knowing what’s going, I get that. For me I’ve wasted so much time setting up projects with webpack and all the the other stuff that I have a pretty good idea, but also I’m just thankful that I can just focus on my project haha.
That hidden CSRF field can be added without form_with though, and Rails still protects against not including it. I left it out of the example as it didn't seem relevant
Do you find that your team often has to reinvent the wheel in terms of what libraries like React/Vue/Svelte have to offer? Doesn't that increase time and scope tremendously?
I actually find that I often have to reinvent a lot of the browser's wheel when using React and friends, so it's often a wash.
Complete back button support beyond what the router offers, saving search/sort/filter in query string so users can copy/paste/bookmark/back/forward, handling connection and other errors gracefully, loading, accessibility, having to wrap Vanilla JS components into their own framework-compatible components, having to update things in different parts of the screen. And the last often requires a total paradigm change in terms of how data is handled in the app thanks to the introduction of state managers (React-sans-Redux looks totally different from regular React). All those require extra work on every project I worked, and no, libraries often don't solve them completely or as easily as it is with previous backend tech.
These frameworks are also steering a lot of software into some very problematic product decisions. Like using fancy third party components where stylized native would suffice (and be more useable/accessible), using date pickers for absolutely everything that looks like a date (it sucks to type your birthday in those unless you were born this month), saving things in the browser instead of in the backend (so the site looks different in different computers), or just having some specific UI-framework forced on you so you have to use a certain framework.
There are obvious advantages to frontend frameworks, and I'm a big fan of React/Vue/Svelte. I really like those things, been using those for years and I was doing what used to be called "DHTML" since the late 90s. But it takes so much more complexity than the average web app to reap those advantages... IMO they are definitely overused.
Vue.js has led the way on HTML first in a lot of ways. You can pull it in with no build step, you can add dynamic content to pages without making it a SPA, and it mostly works through overloading HTML attributes for basic use cases.
There's a few reasons for the ratio mentioned in your tweet. Rapid industry growth in the past decade and the fact that junior devs are cheaper to have on a team. It's got nothing to do with writing a website in HTML vs React.
OP Here. This got more engagement than expected, some of the bits I've picked up in discussion:
"Recommends skipping build step then mentions Tailwind": We use static-tailwind, a version with no build step, in development.
"Recommends hyperscript, a new non-js syntax" - Agree this isn't perfect & would prefer something which uses js. Was going to use Alpine but also have found that to be quite brittle in production. Nor do I love any of the libraries on unsuckjs.com, which has a good collection. We're working on something here which we'll launch at some point.
"OP should look at the recent Rails updates" - Been using Rails for 10+ years - everything we build is on top of Rails - I'll write a post on HTML First Rails at some point. I think they'll get there but currently all the named libraries (Turbo, Hotwire, Strada, Stimulus etc) are 1. Rails specific, and 2. Have a high learning curve. One of the points of HTML First is to avoid framework lock-in.
"This is a blog spam post written by an author that has no credibility in the space": Brutal
Personally, I am happy to see someone else thinking about cutting down stuff and simplifying. Similar posts have started popping up more frequently and as a fan of simplicity, reliability and maintainability I am very happy! Don't get discouraged.
My personal gripe with build steps is not the build step itself, rather the unreliability of the JavaScript ecosystem and the often head-scratchingly opaque error messages.
Build steps such as a hypothetical `css-compile` don't address limitations of browsers, but limitations of network connections that may struggle to download (and frankly, at 3.9 MB, devices that struggle to parse) large amounts of CSS and JavaScript.
Even if browsers can download multiple files at once, they can't download files they don't know about, which is why ES modules in the browser haven't taken off as a way to eliminate the build step.
I like this. I share a philosophy similar to this: hew close to the grain of the material. It's heartening to see articles like this. I've created many expressions of my ideas on this in code over the years: Brutal.JS, VanillaView, Bang/Good.html and I recently created one that is even simpler and I'm very happy with. It's similar to a unification of these ideas with Custom Elements. You can check it out here: https://github.com/00000o1/-
Though I do think some of your ideals are worth challenging either because I think you're making an incorrect assumption or holding too close to some particular dogma, it's always good to hear people pushing for simplicity in the space. Keep pushing :)
Well, also, you make some claims that could be interesting then provide zero proof or even discussion at all.
The entire world: interesting in eng being more productive and interested in more maintainable software. So the first 2 sections are interesting.
You then chase them with a list of assertions with zero discussion as to how they make eng more productive, or lead to more maintainable software. Also without even a hint of why people eg prefer not defining styles inline (protip: fun at first. Now try changing one of them... have fun reviewing 3000 inline bits of css.) Like the industry settled on certain things for a reason, and you don't even attempt to engage with that reason.
You also cite dhh when you like his reasoning and ignore him when you don't. about which, well...
"list of assertions with zero discussion as to how they make eng more productive" - this is fair. Initial versions of the post had much more of this but I felt it added noise to the core principles. I will be following up with some more posts and real world examples though.
"Like the industry settled on certain things for a reason" - In my experience An industry "settling" on something hasn't been a great indicator of its effectiveness. Industries tend to settle on practices that increase the value of its practitioners and increase barriers to non-practitioners. The legal industry, for example, is still remarkably expensive, laborious and bureaucratic, and while outsiders recognise this, there are few people within the industry who seek to change it.
Thanks for the feedback
Irish also, but different perspective. (Have lived away for past 5 years & reflected from afar on our relationship to alcohol)
- Strongly dislike the cultural glorification of getting excessively drunk, but can't deny it's there - the stereotype is not based on fiction.
- Also strongly like the international reputation we have as being hospitable, fun, and friendly (as evidenced by the comment above), which is essentially a positive stereotype.
- In my experience when meeting new people, acknowledgement-that-the-Irish-are-drinkers (in a non-antagonistic way) is not in itself harmful, and can often be a good ice breaker and rapport builder. As in, the stereotype itself is not the harmful part. Most people I've encountered tend not to make negative assumptions, are smart enough to reason about group vs individual behaviour, and give the benefit-of-the-doubt, and those who don't have a being-an-asshole problem, not a infected-by-a-stereotype problem.
- My reading of the comment above was that the spirit was non-asshole-y.
Maybe, but maybe rapport based on “I don’t know you but I’ve heard your kind are a harmless lot who are always up for a drinking party after work”, is useful in a very limited set of circumstances, such as meeting a new team of peers, maybe. I’d still argue not, since the point of rapport building is to get to know the person in front of you, not how well they fit your preconception / stereotype.
In a large majority of situations in my experience, like being a senior manager of a new team, the CEO of a company meeting clients or negotiating with vendors and partners, it’s utterly irrelevant at best.
Also, the fact that Ireland has a major, major alcohol problem is no justification for the stereotype; so do many northern hemisphere countries. London had its Gin Crisis of the 18th century, with huge death toll and virtual breakdown of society, and the UK still has astronomical alcohol consumption, but they don’t get labelled the same way as the Irish
> the UK still has astronomical alcohol consumption, but they don’t get labelled the same way as the Irish
It shows how sticky stereotypes are and how they allow people to point at others without really thinking about themselves. I've got an example too. Within the UK Scotland gets a bad rap for being a nation of overweight people who eat deep fried food every other meal, when in reality the rate of obesity within the country are within a couple of percentage points (something like 27.5% in Scotland, 25% in England). I have literally had overweight English people trying to crack wise with me (Scottish, 83kg/190cm - basically in shape) about Scottish people being fat which is kinda funny. I thought it would be a bit rude to turn it round on them - there's a line between banter and direct insults after all :D
Ireland gets it a bit worse though. So many people love to try to mirror the accent or joke about the potato famine or the troubles (not excluding Scotland from this, this stuff occurs across the English speaking world) wee bit edgy for my liking.
Yes, people “doing” the stage-Irish accent in response to an Irish person speaking in a relatively neutral accent is incredibly common, I just don’t get how people don’t realise what they’re doing- and I know for fact that many times it’s meant in a friendly, almost affectionate way, which boggles my mind even more, and then of course there are times when it’s intended to irk and offend but the person doing it hides behind the “banter” and thinks they won’t get called out for it.
>the UK still has astronomical alcohol consumption, but they don’t get labelled the same way as the Irish
To be fair we certainly do have a reputation for drunkenness and general loutishness in parts of the Continent, apparently in anywhere with cheap holiday resorts the UK has a bad name.
Irish also, twelve years to the day I've been living abroad.
I'm not really interested in "drinking", I've more a European approach to it, enjoying a relaxed pint or a glass of wine etc.
I 100% agree with you though, part of the Irish culture people look to experience is the good times around a few pints and some traditional music, with the reward of a hangover in the morning to mark it as a successful night.
The few negative things I've ever experienced were off hand comments about the famine, and some nonsense about the North of Ireland.
Founder here. I launched the site about 6 weeks ago on ProductHunt to gather feedback and am currently building out a larger offering and preparing to open the doors to the public in a few weeks - inline editing will continue to be part of the value proposition, but we're also going to focus on building the simplest content API possible, which was a surprisingly large request among the early signups. Would love to answer any questions people have. Will post to show HN again when we launch the updated site and product in a few weeks.
Technically yes, but we'd like to also be used for storing content used by web apps - the CMS is designed for web sites. An analogy that might work well here is the difference between Redis vs. Postgres. Redis = optimised for key/value data at high volume, Postgres - optimised for relational data. That's how we see ourselves vs traditional CMSes.
