| Nov 25 |
Met a guy at a wedding last week who had read this book. It had created a completely closed epistemic loop, where every point I made was returned with either “We don’t know that because AI is grown not built” or “That is just blind faith”. One of the most frustrating conversations with a stranger I’ve ever had. I say this as someone who is way-more-open-than-most to “doomer” perspectives.
I’m guessing that was one of the goals of the authors - to create an ideology that withstands critique, so hats off to them for that. 100% brain-wormed. Sample of one of course. Interested to hear others experiences
|
4 |
0 |
0 |
1.1k |
608 |
. |
| Nov 18 |
The most important trait for hiring or getting hired is Professional Theory of Mind. If you can intuit what matters to other people (customers, managers, clients), you need only moderate management & can figure the rest out, but if you can't, you become a burden
|
6 |
0 |
0 |
2k |
266 |
. |
| Sep 15 |
Been using this for the last hour - I think we may be close to the promised land that makes vibe coding viable for real apps. Incredibly exciting, and also a little scary.
|
18 |
3 |
3 |
6.1k |
171 |
. |
| Aug 27 |
The reason many products are low quality, or badly-thought-through, or dont-make-sense, is that it's actually very difficult to find people-who-care.
These products have talent in engineering and design - the missing piece is just the person-who-gives-a-shit
|
14 |
0 |
3 |
1.2k |
260 |
. |
| Aug 22 |
“Html first rails” is rails with htmx and mini js instead of Hotwire and stimulus. Doing a big clean up on the repo but will release open source at some point
|
10 |
1 |
0 |
2.3k |
158 |
. |
| Aug 22 |
People often ask for examples of @htmx_org in the wild. Here are 7 codebases where it’s being used today in production.
|
9 |
2 |
0 |
3.1k |
119 |
. |
| Aug 22 |
Part of the reason I have so much conviction in the html first stuff is the variety of things we’re building, which allows us to sense check & compare. Currently we’re working in parallel on:
- Online accounting platform with thousands of customers - html first rails, 2.5 yr old codebase
- E Learning platform with 100k MAUs - rails with stimulus & Hotwire. 8yr old codebase
- Contractor freelancing platform - html first rails. 3 yr codebase
- Fully digitised platform for a shipping port. HTML first rails, 4 yrs old codebase
- Internal tools for large salon software SaaS - html first rails - 3yrs
- YC backed AI customer support/training platform - next js/typescript
- Online US visa platform - html first rails, just started.
- Kiosk software for the construction industry - html first rails backend, preact standalone + couchdb for offline first frontend
- Consumer Mobile app with 1k downloads/day (react native/html first rails hybrid) - 2 months
- Consumer mobile app going viral on insta - pre launch (react native/ html first rails hybrid)
When https://t.co/c4irCqD8K4 went viral on HN a lot of the comments were “this guy has clearly never used this in practice” which shouldn’t get to me but it did - might have even fuelled all the work we’ve been doing to get it right.
|
17 |
1 |
1 |
4.4k |
1.3k |
. |
| Aug 20 |
So… I live in Amsterdam but didn’t get a railsworld ticket because I thought we wouldn’t be here for it. But we are, and I really would like to go. Is there anyone in my network that’s either selling one or would know how to come by one?
Cc @AmandaBPerino 😆
|
8 |
1 |
7 |
3.4k |
259 |
. |
| Aug 12 |
The @hatchboxio team keeping their prices at $10/month is the saas equivalent of the 99c Arizona Iced Tea. Such a great deal.
|
11 |
3 |
0 |
2.3k |
125 |
. |
| Jul 26 |
Something I find super odd - a lot of components you see design engineers obsessing over - you almost never see in real products. The multi-level dropdown is a great example - the only place these menus persist in most UIs today are at the OS level or for some native apps and that's about it. But they're one of the first things in every component library.
|
4 |
0 |
2 |
1.3k |
357 |
. |
| Jun 08 |
I'm finding our dev hiring now converging on 2 kinds of archetypes:
- Early Career - Strong written/verbal communication. Organized. Fast Learner. Knows the basics (html, css, js) - can learn their skill gaps.
- Senior - Gritty problem solver - great at figuring out really hard problems and getting their hands dirty.
Any senior who can't solve hard/unsexy problems and/or whose main focus is on "making the code super clean and elegant" just doesn't really fit anywhere.
|
26 |
1 |
7 |
7.2k |
475 |
. |
| Jun 01 |
The level of arrogance and ignorance in these posts drives me crazy.
It is 100% possible to build “software at scale” with simple solutions (including no build), *if* you put in the effort to figure it out. I’m confident in this take because I’ve spent a lot of time figuring those things out, all while being told by people like Adam that it’s not possible.
I’m pretty sure “Works for splash pages” is meant to bait people like me for engagement. I wish it didn’t work, but it does.
|
14 |
1 |
6 |
4.5k |
487 |
. |
| May 27 |
If I were an investor looking to invest in one of AI coding tools (including Cursor, Windsurf, Devin etc), I would be putting my money on @codegen
They are building really novel and valuable stuff, and unlike the others are actually under hyped right now
|
16 |
6 |
1 |
2.6k |
256 |
. |
| May 21 |
Ok this is impressive from @cursor_ai using O3 Max.
We've been building a hybrid boilerplate (similar to hotwire native) and doing some weird atypical stuff.
Kept getting stuck on things that should be straightforward but weren't, and up to now Cursor was useless - none of the models seemed to *understand* what was happening.
Just tried with O3 Max (thanks @Shpigford) and it got me a working solution in one pass. Not only that, it managed to build an understanding from the code that the previous models couldn't.
|
10 |
1 |
1 |
2k |
522 |
. |
| Mar 31 |
My new favourite pattern for using islands of React in a @rails app (or any app for that matter). No build step, super lightweight, readable & maintainable. Perfect if you want to use React for little bits without having to replace the whole UI. https://t.co/v8U4BUvyCs
|
15 |
0 |
2 |
1.1k |
273 |
. |
| Mar 28 |
Something happened Claude since yesterday. 3.7 is now one-shotting things it was previously failing completely at. It's so good
|
3 |
0 |
0 |
1.3k |
127 |
. |
| Oct 18 |
The history of web development:
1. Frameworks and tooling (abstractions) are built to do what the platform can't.
2. The platform can now do those things.
3. Abstractions get deprecated. Platform's capabilities grow
On a long enough horizon, the abstractions are the tech debt https://t.co/wu58C4fQad
|
14 |
5 |
4 |
4.2k |
302 |
. |
| Oct 10 |
This looks like the smartest way to combine the benefits of Rails on the backend and js-ecosystem on the frontend. If I wasn't all in on server rendered Rails this is where I would be looking 100%. So awesome to see @rails as the second officially supported framework.
Great work @skryukov_dev & @evilmartians
|
12 |
1 |
1 |
2.3k |
311 |
. |
| Oct 07 |
Really enjoyed doing this with @shl. Kudos to him for keeping an open mind. Glad we could clear things up on my beloved @rails
|
50 |
3 |
4 |
14.1k |
126 |
. |
| Oct 03 |
This is the thing that needs to be solved for the server rendered approach to become more prevalent. It's *possible* to do really nice, simple stuff with htmx, it's just really not obvious. https://t.co/CWtXfgABES
|
3 |
0 |
0 |
1.4k |
213 |
. |
| Sep 30 |
Had a good chat with @shl about the future of software dev and whether @rails is tech debt.
We agreed on way more than we disagreed on - he’s given it a lot of thought and is much more nuanced than comes across here. (I also don’t think he *still* thinks rails is tech debt, but I’ll let him comment on that)
His first point is that you get much more out of the box with next/react to build polished, slick frontends. Which you kind of have to figure out in rails apps (I agree).
His second point was that having everything typed makes it much easier to work with AI, and makes you much less worried about breaking things. I can see this but I think there are non-obvious trade offs to adding layers on top of the platform that become more of an issue over time - so this really depends what you’re optimising for.
We’re gonna do a live stream where we both build something out - me in rails and him in @nextjs, to let people see the benefits/trade-offs of each. Should be fun!
|
63 |
1 |
10 |
5.7k |
982 |
. |
| Jul 22 |
Announcement: Today we're launching Really Good Software - the first software agency built for the future, that acknowledges....
1) Individual developers augmented with AI will increasingly surpass the capabilities of entire teams, and...
2) In the new world, the dominant Software Agency pricing model (charging for bums on seats and hours worked) will need a significant rethink.
Our answer is an incredibly-priced monthly subscription that gives you all of the ingredients needed to ship great software.
Go check it out 👇
https://t.co/7lWI7JnXSt
|
20 |
1 |
4 |
2.9k |
553 |
. |
| Jun 30 |
"Integration Settings" by @louisdainguyen
Finished Result: https://t.co/1TpMONHQ2j
#RGSQuickbuild https://t.co/iuipvdsXQu
|
4 |
1 |
0 |
1k |
124 |
. |
| Jun 30 |
Mini Announcement
For the past 2 years we've been building a software agency called Tonic. In the next week, we're going to be launching our Productised Offering - Really Good Software.
The ultimate goal with Really Good Software is to become the obvious answer when someone asks "Do you know of any good freelancers or agencies?". To unlock that we'll have public, transparent pricing, and (soon) a lot of public content - both on the work we're doing, and on our approach.
I've been obsessed with the idea of Building Good Software Affordably since I began building teams over a decade ago. Silicon Valley engineering culture has convinced us that quality is unavoidably expensive, and I would like to show people that with the right approach, it's really not.
|
24 |
2 |
1 |
2.1k |
765 |
. |
| Jun 06 |
There are Hypertexters and Javascripters.
Both talk a lot about why their way is objectively better, but in reality neither chose their approach for its merits. It was always about personal taste.
Hypertexters prefer writing html, Javascripters prefer writing javascript.
|
4 |
0 |
2 |
1.2k |
274 |
. |
| Feb 26 |
This is why I don’t recommend using Hotwire or Turbo with @rails unless you really need real-time, web socket enabled features. People (including @dhh) talk a lot about how awesome it is, but the reality is that the supporting material just isn’t there - and the people who made it don’t seem to care too much about documentation etc. so getting it in use on a team has much more friction than say, just using @htmx_org.
|
8 |
0 |
4 |
4.7k |
420 |
. |
| Feb 10 |
Working on something along the lines of "Shadcn for HTML". Is this a dumb name? https://t.co/19Nm9gKT7T
|
11 |
2 |
7 |
1.5k |
103 |
. |
| Jan 20 |
Working on several migration projects this week for hobby and client projects and thinking about the idea of codebase Durability.
Some Takeaways
When you've been around for a while and worked on web app codebases that are 10+ years old, you notice how little the product fundamentals have changed in that time (we're still using html to draw rectangles and put data in them from a database, which is likely to still be the case for decades to come). Yet when we see a Github repo which was last updated more than 2 years ago, most of us think of it as "out of date/obsolete".
Theoretically, the most durable (future proof) possible codebase is one that only relies only on functionality and concepts that browsers natively support (html, css, js). Every new library added on top carries a maintenance burden as new concepts and trends come and go, which happens every 3 to 5 years. (This isn't really possible today IMO as browsers aren't there yet).
The codebases with lots of named libraries and concepts are obviously the least durable. (Some of the things we're removing or replacing this week: Turbolinks, ActionCable, Tachyons, Semantic UI, Webpacker.)
It feels like in the industry there's this idea that everything's a cycle and that we're perpetually looping and not progressing, but in reality browser standards are incrementally improving to support more things, and at some point we won't need to layer frameworks and libraries on top.
The ultimate goal is getting to codebases that are durable-by-default - that require zero new libraries/concepts to be added but still have fast, polished, maintainable web apps. That can be left operating, code untouched for 5, 10 years, but if/when changes need to made they can be operated on with zero friction.
When it comes to libraries, there's not yet any way to avoid them entirely - we still need them to patch things the browser can't do natively. But we should choose libraries that are 1. Likely to still be around in 10+ years, and 2. Not likely to introduce any new concepts/breaking updates in that time.
|
10 |
0 |
1 |
1.6k |
2.1k |
. |
| Jan 08 |
We need a way to talk about the comparative *Conceptual Load* of different libraries that lets us distinguish between "sprinkles" libraries like @htmx_org, which basically have one or two important concepts and can be learned in an hour or two, and fully-fledged "frameworks". https://t.co/1npK77IVFK
|
6 |
0 |
1 |
8.7k |
300 |
. |
| Dec 30 |
The biggest mistake I've seen tech leaders make is being too relaxed about how technologies are chosen in the tech org, and ending up in specialization hell ("Tim is our redux guy, John is our AWS guy") etc. If you want to keep a handle on costs, you *have* to keep a handle on what you build with.
Love the terms "Canonicity" and "Avoid non-essential variance" for capturing this. This article is great
https://t.co/wXpUYgTlIs
|
9 |
0 |
1 |
1.4k |
429 |
. |
| Dec 23 |
Similarly, until an AI can orchestrate a recurring feedback loop between code editor, command line, browser, and external services, we won't see fully-AI-written (no developer required) software.
The current wave of text-to-UI demos are cool but IMO a distraction in terms of what's actually going to "change everything"
|
4 |
0 |
2 |
1.8k |
322 |
. |
| Nov 20 |
TIL the complexity of a menu, a list of transactions, and a toggle (gasp!) will require a well defined (frontend) architecture to avoid "unmaintainable spaghetti"
🤔
cc @htmx_org https://t.co/faoFKQYlmC
|
7 |
0 |
3 |
1.1k |
203 |
. |
| Nov 18 |
Working on a new post for https://t.co/EgIFQGIGpH that outlines the flavour of web software that this approach is meant for.
We don't yet have a term for simple web software that is, at its core, a set of screens and forms on top of a relational database. I like "Formware" https://t.co/MWmQtmDQnx
|
14 |
3 |
3 |
1.7k |
299 |
. |
| Nov 14 |
A lot of the responses to https://t.co/1ckVMk8TCx were "Cool but it's just not possible to do X without react" (multi-selects, styled dropdowns etc.)
I get the sentiment, but there's nothing fundamentally preventing us from building these things in an HTML First way, and until now I just don't think there's been that many people trying (and there are still good solutions in html first libraries like Alpine).
Here's an example of a working multi-select using mini js (not yet released).
|
15 |
1 |
4 |
1.1k |
491 |
. |
| Nov 12 |
Mr HTMX approves 😊
https://t.co/eIYm0TT0qf
|
12 |
0 |
1 |
1.3k |
43 |
. |
| Sep 27 |
The reason many hosting/cloud bills are *way* higher (often 10x+) what they could be
The Prevailing Wisdom
-The only acceptable cloud platforms to use for reliability are the big ones (AWS/GCP/Azure)
- We *must* have every service (including non prod) on it's own server (best practice).
Results: 5 codebases * 8 services *2 environments (production, staging) * medium-level server ($96) = $7680/month.
The Reality
- The main line item on your team's cloud hosting bill is what's called a VM (virtual machine). Every platform has created it's own fancy name for this (Amazon is EC2, Google is Compute Engine) but behind the curtains you're paying for the same thing - commoditised, open source technology.
- There are many hosting services, with similar uptime stats, that sell the exact same thing the big platforms do, for 90% cheaper. For example the equivalent of a $96/month Azure server is available on @ContaboCom for $6.30/month.
- You probably don't *need* a separate instance per service for non-production systems, (you also probably don't need all those services/codebases either, but that's for another day).
The cloud provider offerings are *intentionally* confusing to both technical and non-technical people.
When your team says "This is just what it costs to run our software, we can't do it cheaper", they don't mean "This is the cost required to service our volume of traffic", they mean "This is what 'best practices' costs and this is what everyone else is doing so we're not overpaying"
There are many teams out there paying many thousands per month for servers when the actual compute cost to service their volume is closer to $10/month - this sounds crazy but is true.
To be clear I agree that paying a premium for reliability & convenience makes sense, but not at these ratios. And I also know there's no way business/finance people would sign off on those numbers knowing the actual *most-affordable-option* cost.
Wasn't going to post this because I thought it was common knowledge, but speaking to more people recently & realising this is fairly commonplace and that people often think that their hosting bill is just the *cost of doing business*.
|
26 |
2 |
4 |
3.4k |
2.2k |
. |
| Sep 11 |
I had a passage typed up where I argued the exact opposite of this point (I also have adhd and find typed languages to be a large obstacle because it lengthens the dopamine-driven feedback loop). Not saying this to dispute this particular developer, but to illustrate that every person is different. On the whole I don’t think it’s a good idea to bring ADHD/learning/accessibility into an already very charged debate.
|
5 |
0 |
6 |
2.1k |
417 |
. |
| Sep 07 |
If you follow people like this and are new to the industry, please ignore messaging like this (that if you don’t adopt a certain style or framework that you’re an “incompetent” engineer). Some people need to use strong normative statements to justify their decisions and preferences.
|
11 |
0 |
1 |
1.5k |
283 |
. |
| Aug 23 |
This is particularly true if you can ship fast and regularly, because you can iterate your way to solving the problem perfectly. A common failure mode is to ship so slowly that you assume discovery is needed on everything, which ironically slows the process even more.
|
5 |
1 |
0 |
1.1k |
268 |
. |
| Aug 17 |
Working on the simplest way of explaining how this works. Does this seem intuitive? https://t.co/cOvk7Pz0rx
|
4 |
0 |
0 |
1.9k |
107 |
. |
| Aug 15 |
We went ahead and built this. Starting testing this week, excited about it. @htmx_org you seem like you may have been down this path before, any thoughts?
|
0 |
0 |
1 |
1.6k |
154 |
. |
| Jun 26 |
Great single slide overview of the actual “tradeoff” that many teams make and how ridiculous it is, particularly when compared to “add a single line of code to your page (@htmx_org) which gives it the missing capability”. https://t.co/XHzDvbzdKk
|
57 |
10 |
1 |
6.3k |
245 |
. |
| May 19 |
Wasn’t expecting this from the react ecosystem. It’s cool that hooks help, but ultimately you’re still trapped inside react/npm/pre/post processors etc
What if I told you you could insert dumb-tailwind, hyperscript and htmx in your head, and get copy-paste-ability in raw html.
|
14 |
3 |
0 |
2.7k |
278 |
. |
| May 08 |
I feel a similar level of affinity to @htmx_org as I did/do to @rails, not just because I love the patterns and simplicity it enables, but also the philosophy (locality of behaviour etc) . So seeing influential devs like Michael check it out puts a silly grin on my face.
|
13 |
2 |
1 |
3.7k |
272 |
. |
| Apr 16 |
Really enjoying both @AcquiredFM and @FoundersPodcast recently, difficult to listen to them and not want to do something great with your life.
|
19 |
0 |
3 |
3k |
143 |
. |
| Mar 15 |
Big fan of @intercom and the team in there but I think pinning your brand on customer support that doesn’t require humans is the wrong direction and forgets that’s the most important person in the CS equation is the customer
|
4 |
0 |
3 |
2.7k |
224 |
. |
| Mar 06 |
Built myself a little app to track my finances over Christmas. Decided over the weekend to make it look nice and let some friends use it. https://t.co/NWUtzEb5mm
|
14 |
0 |
1 |
1k |
161 |
. |
| Feb 20 |
Last year, my team started a "Remote Development" experiment. We're still iterating, but it's already a core part of our workflow. The learnings are broadly applicable/interesting to both a technical & non-technical audience, so I've written this thread for both.
👇
|
11 |
1 |
1 |
1.9k |
271 |
. |
| Jan 21 |
A few years ago I suggested the term "co-code" as a product/tool that allows both developers and non-developers to build/collaborate in the same environment. Of the products I've used since then, @framer is the exemplar. Still early but they're nailing it
https://t.co/NmNl8DxGue
|
4 |
1 |
2 |
1.1k |
280 |
. |
