"Lets make extreme generalizations about tens of thousands of people because of an extremely unique outlier (who doesn't even belong to that group of people)."
Fair feedback. If you scroll down (or press "See it in action") there are some examples.
We definitely could invest more in a flashy landing page, but we're early, and we've focused more on trying to build a product that is useful than one that is well-marketed. For Silicon Valley, we have our priorities reversed, but I enjoy the product building :)
All I can see is a full screen 6 step checklist with the first step being 'install tweeks'. There's no 'see it in action' link anywhere, unless it's behind the modal
Surprised by all the hostility in the comments: if this tool actually works as described in the video, you've created a whole new generation of dev tool with JSX Tool!
Me too. I know HN doesn't love YC companies but I was a little shocked.
I swear it isn't vaporware but there's only one way to find out.
There are definitely rough edges, we are after all a 2 man band but I don't ship things that don't work and it's admittedly not done great with older versions of React. You should try it though!
I've always wondered why this is (after all HN is basically YC) and I feel like it wasn't this way before but don't have evidence. HN leans skeptical and critical so maybe the AI wave brings that out in spades
Hey, sorry, I tried to write my feedback with a little more empathy but I guess I should have been upfront to clarify my point.
What I meant to say is, I can't see this competing with the current state of the art as it comes to local development. As for remote development, we are quite lacking there IMO, and this seems to be a great potential candidate to solve that problem.
I do a large portion of my development locally, it's great, I love it. This product is trying to get me to change my workflow there and asking me to do it from the browser only. Why would I work on a browser only if I have a full suite of tools locally, terminals, IDEs, text-editors, rich LSP / plugins / Agents / etc.
Harper is a nice alternative, but it's still rough around the edges.
For instance, if you have a misspelled word, and the correction options come up, you can't get out of them and return to where you were by using the keyboard. You can hit Escape to close them, but it doesn't restore your place in the text field, so you have to use your mouse to get back where you were.
As a programmer who tries to use the keyboard as much as possible, this (incredibly easy to fix, I'm sure) bug drives me crazy! Almost enough to make me go back to Grammarly.
That seems to me not like a "rough around the edges" thing but "most basic, table-stakes feature". If you cannot resume typing after either cancelling a correction, or doing a correction, I'd say it is very broken and not ready to be marketed as a functioning tool. I mean, it's supposed to help you write, not make it more cumbersome.
Now, to be fair, they wrote the article in 2025, and Tailwind linting was only released five years prior (in 2020) ... five years is hardly long enough to learn relevant tech for your industry /s
The rest of the article seemed similarly ill-informed, with the author fixating on meaningless byte-size differences in contrived examples. However, he ignores the fact that Tailwind is used on some of the most performant sites on the Internet. He also ignores the fact that (for 99% of sites at least) sacrificing a k or two of bandwidth is well worth it for a major increase in developability.
With Tailwind you completely get rid of stylesheets: that alone is huge! There's a reason why so many devs use Tailwind: they don't worry about minimal file size differences, but they do care about massive savings in development time and complexity reduction.
You described a lot of orthogonal points and highlighted your opinions, more than pointed out flaws in the article.
I use Tailwind at work at a large company, and it's... Okay. Its biggest strength is the documentation, since most companies have poorly documented style guide/component library.
I'd never use it for a personal project though. It's fine to disagree
Look, I wrote one of the only published books on Backbone, and it will always have a special place in my heart, but ... the OP has no idea what he is talking about.
Backbone employed a two-way data binding flow. You're responsible for updating the models (ie. state) (way #1) when the user triggers events, AND you are responsible for updating the DOM whenever the models (ie. state) changes (way #2).
In React, they used a revolutionary new paradigm (flux), making it so you only worry about one direction (updating the models/state in response to events); you never render anything (React renders everything for you in response to state changes)!
If you've tried developing a non-trivial site with both, it quickly becomes apparent how much that one difference completely simplifies a huge aspect of development.
This is off topic but I need to ask you to stop breaking the site guidelines. You've been doing it repeatedly lately (not in the current case—present comment is fine), and we end up banning such accounts.
Fear and hatred of experts is how we got into this mess. If pharmaceutical executives aren't all cartoon mustache-twirling villains (and they're not: many actually want to help sick people), then maybe not every employee is either?
Of course it is. Anecdotally however, in my career I've spent a lot of time among people like the author of the article. I've yet to meet a single one who did not present as genuine in their desire to help people. Might it be the case that they are aware of market dynamics within the process? Yes of course. But tropes like Big Pharma intentionally not providing cures or only looking at treatments that require constant application are bollocks. At least to the extent of my hands on experience in the industry.
reply