Hacker News Reader

Comment by simonw | Hacker News Reader

It's genuinely fascinating to me how many professional web developers these days - smart people who produce good work - don't know how to build interactive features using HTML on its own (and maybe don't even know it's possible).

Being able to do things like this is really useful:

  <form action="https://simonwillison.net/search/" method="get">
    <input type="text" name="q">
    <input type="submit" value="Search">
  </form>

I've seen teams estimate a full day to add a link to a contact form because they need to refactor a bunch of React components to achieve that. I like being able to do this:

  <a href="/contact">Contact us</a>

View on HN

I worked with a team of developers tasked with creating a few 100% static websites. Single page, no interactivity, nothing dynamic. They were talking about which React components to use, server APIs to build, etc when I asked why they didn't just write HTML or use a static site generator and host the page in S3. They didn't know how to write vanilla HTML, they had never used it for more than bootstrapping a React app.

Yes, but remember: static HTML is a one-way street. Better tell your manager otherwise they will one day come up with functionality that can't be done in your website and it's your fault.

EDIT: For example: manager/designer wants to add an assistant to the website; it should be draggable; it should also animate and keep animating smoothly no matter where the user navigates on the website. If your website is a SPA, this is conceptually easy. If your website is static this is going to be a nightmare and suddenly a simple change requires lots of work.

You can't add interactivity to a static HTML site? Or shift the static pages into modern frameworks?

I mean let's not go too far and pretend there is 0 advantage to JS

You absolutely can, but it's way more common to only know how to create a blank site with a framework than to migrate an existing site. React used to have a section in its documentation for how to add it to your site without adding a build system (not common knowledge, unless it's setting up a blank site through a script) and they've since replaced it with a brief tutorial telling you to migrate your website to a JS module with a link to a suggested build system.

All of this matters because the person that has to do this setup might not be you. It's certainly a problem with the frameworks themselves that porting a website (even just to add a little functionality) isn't as easy as setting one up initially but there's not really much an individual can do here. It's one reason I like frameworks like Preact so much, they're actually trying to fix this.

Understood. Makes me think of YAGNI though.

https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it

You mean this: https://react.dev/reference/react-dom/client/createRoot

How you bundle react is left as an exercise to the reader but the data is still there?

>How you bundle react is left as an exercise to the reader but the data is still there?

The Francis Scott Key of web development

"...and the data was still there!"

No because a page-load e.g. breaks the animations.

Are these frameworks incapable of having the static content as something that can be served? Are the links in the existing content unable to be updated to whatever need to happen for the page transitions?

CSS does support page change transitions now.

Not at all.

There are plenty of things you can do with static websites, especially given you can have site generators and/or can write javascript by hand too (shock!).

For example if the requirement is to have website editable by non-programmers, that's where static site generators shine. Sure, one has to press "deploy" button and wait a minute before changes are visible... but you get to keep all the features of static pages, like trivial scalability and very high security and availability.

Even if you have to have dynamic functionality (like a shopping cart), there is no need to do the whole website dynamically. Sure, have an API server which may even render the cart page, but the rest of the website can be fully static, maybe with a tiny bit of javascript to render the "number of items in the cart" icon.

Absolutely. I built something like that during high school for a local artist. Had and interactive backend that allowed him to upload his creations and it would regenerate static HTML when he was done with that. That was my first paid developer job basically.

I re-used it later on in university to hand it in as a project (easiest course ever) and got commended for not putting load on the servers and making the site slow for users by using something like PHP to re-generate the same stuff over and over as users browsed the site. A+

Yes, but remember the much more important rules of programming:

You aren't gonna to need it[1]

Do the simplest thing that can possibly work[2]

1. https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it 2. https://www.ronjeffries.com/xprog/articles/practices/pracsim...

You can make an example that will invalidate any technology choice. Design for the requirements you have.

"That's a very nice car you've made. Unfortunately, if the designer later decides that it needs to survive artillery rounds, you'll wish you had built it out of armor steel as I recommended in the first place."

YAGNI should be tattooed on some people's eyelids.

On the outside of their eyelids it would do nothing for self-awareness, so I'm assuming written on the inside... which they won't be able to see unless they look at something super bright, like the sun, with their eyes closed.

... I guess this season some of us have more time to overthink things.

Still, YAGNI needs careful consideration. What looks like YAGNI right now might be reasonable flexibility that will be needed as the project matures. YAGNI makes perfect sense when delivering a proof of concept, but it's not that straightforward when designing for long-term use.

As if requirements are set in stone.

The parent comment is a bit exaggerated but it still has a point. One needs to be able to predict things and make sure whatever you do today isn't so rigid that it can't adapt to other things in the future without a major overhaul. Typically this means being cognizant of the assumptions made along the way, and making the minimal set of them. This kind of insight requires experience. People preaching YAGNI just don't seem to have much of it. They just read "YAGNI" in a blog post and then yell it at other people.

I agree no one should follow recommendations blindy, but I have seen WAY more instances (firsthand and second-hand) of people mis-architecting for circumstances that never come.

When it comes time to make a change, it's often not as big a deal as it was made out to be, and you have the benefit of everything that has been learned along the way. No one gets it right the first time anyway, so don't overthink it.

The requirements you have today are a lot more set in stone than the requirements you don't have today, that you imagine you might have tomorrow.

It's not anymore!

Multiple options around, I personally love this

https://lit.dev/

You can develop that element and then just drop that onto your static page via /assets/ and you're golden. Easy to develop, simple to deploy and tiny file size.

And it uses html instead of stipid component templating that reinvents html with different semantics.

You can easily put React components into static website once you need them wherever you need them.

That's one of the selling points of react that was initially important that you can use it in limited fashion.

I was going to say the same, I have a webxr (virtual reality) site that has a few react components on it, plus a few vanilla javascript libraries in the main page template.

Build a router and set inner HTML.

This would maybe be a few hours of work if going from a static site to a SPA was actually in scope. Strip headers from the current pages and now serve the body as content from an API.

You don't need your entire site to be built with react to use react within your site and building a JS based router is not very difficult and will get even easier if the Navigation API[1] becomes better supported.

This would actually be harder if you now still need a static site with an across page assistant. I would probably push back on some requirements and store state locally in the browser. Effectively hot reload the assistant on each navigation but even then it's doable, even using react.

1. https://html.spec.whatwg.org/multipage/nav-history-apis.html...

Umm, how is it a one way street? Just add a <script> tag and implement what you need... I'm not 100% convinced that using react from jump street "Just in case we need something in the future" is a great idea. That having been said, I'm not sure I've built a completely static html page in the last decade.... So I often start with react/angular.

It's frustrating the lack of simple tooling out there for static site generation. I have had to write bespoke static site generator build scripts just to get things working.

Everything is React and SSR these days - like people please - it's not that complicated. TypeScript is an acceptable amount of overhead. Use React only if you absolutely need it and even then, use it super carefully because it has no seatbelts.

Petite-vue is a nice middle ground for 99% of websites and I am sad that this approach (templating) to build dynamic content doesn't have more investment.

With Sveltekit it's quite easy to generate a static site, I've had good experiences with it

Writing good HTML is not what employers, hiring managers, HR, and resume algorithms consider to be a skill worth paying for. You gotta know React or GTFO. From the perspective of a newbie developer, why waste time learning the grandpa way of making webpages when React can do all the things?

I'm not saying that situation is ideal. Most of the web should be less JavaScripty.

I'm still fascinated by a website linked on HN some time ago that was written in MarkDown, but then not translated to HTML and served, but sent as MarkDown along with a JavaScript renderer that would then translate and render it on the client. Sure, it works, but why?

(As a marginally related aside, I've recently spun up my mother's old 12" Powerbook G4 from 2005 or so. It worked fine and was reasonably fast and snappy (for a HD based machine), except when I opened the browser. A few tabs brought the machine to a standstill. Goes to show how much crap is on the modern web.)

That's an unrealistic complaint.

These laptops had <1gb RAM. You should be amazed if you could open multiple website.

Each website is essentially a full program with sandboxing etc - and surely you'd be aware that opening I.e. Photoshop 4 times on such a resource restricted system would be just as impossible.

And it wasn't any different back then. At last not on Mac, as I had an iMac and vividly remember the same issue.

The last devices before they switched to Intel had pretty bad performance, that was the reason why they switched soon after.

mdwiki.info? I wrote it because back in 2012 you had a "Public" folder in Dropbox that also was a public static web space. So a way to create a homepage without installing any software and without need to learn html.

Times have changed, Dropbox removed that feature - and no one uses Dropbox even anymore.

As the old man screaming at the cloud, about the insane complexity of modern JavaScript frameworks, who hasn't done much with them and kind hates the experience of dealing with them at all, I hope you are right.

Can I still use my basic HTML knowledge and be productive? I've instead just given up doing any frontend work because I don't want to spend my time in React. Give me something simple, concrete, and understandable like an advanced algorithms textbook, and I'll go to town. Reading user guides or documentation of Typescript/Javascript frameworks feels impossibly hard in comparison.

Working with Turbo and Stimulus with Rails is such a breath of fresh air for me for this reason. Sure its not just writing HTML, but its such a vastly simpler framework for creating a responsive web page than React, Vue, Angular, etc. I don't know how React and the like became the de jour of Web development, its quite a complicated beast. I am partial to DHH's interpretation it was off of zero interest rates and free money.

this is key, working with rails and stimulus - you get to escape the nonsense. but we also have to admit reality - it's easier to pay *rent with react and friends than with other full-stack frameworks.

well it used to be and still is till interest rates went up.

I can't think of any job postings I've seen recently that only wanted straight-forward web development. Everything was asking for a major framework + other supporting libraries for the front end. I'm only 40 and also screaming at the clouds, but I simply don't have the luxury of ignoring some of the larger things like React that gave me a job today.

This is the market pressure which is driving things towards more abstraction. Another iteration will add more abstraction on top of that. I'm fairly certain it can't be stopped now. Doing so would mean convincing tech leadership to start actively managing what technologies go into their products and striving for a "less is more" or minimalism approach.

I'm in the fortunate position of not needing to care much what people are hiring for. Instead I'm more interested in what can I create, and to a lesser extent what sort of team could be scaled on the technology. One of the projects I'm currently contributing to is a massive web app that's nearing 30 years old, all written with a C core and served over CGI in Apache, from an age when C was necessary to process the amount of data that was getting processed per request...

I do think there are somewhat perverse incentives in the job market to be up to date on the latest trend in order to maximize the ability to hop onto the most in demand platform. Which makes sense from the developer perspective! But then it also means that devs and even management feel pressure to churn the tech stack on existing working code continuously, to keep abreast of the changes. There's a lot of devs that don't want to be considered stuck on an "old", e.g. PHP, stack, and sometimes management wants to be hiring the devs that are trying the hardest.

So to me it feels like a lot of change for changes sake, or in other words the design space of web languages are being fully explored at a great pace, using real world projects. I don't think it's technically incorrect or wrong, but it is probably just a "not for me" part of the ever expanding tech world.

PHP just released version 8.4.2 today, so if that's your ball of wax, and you're working on your own projects, have at it. I wrote some PHP earlier this year for this one project. React pulls together a bunch of language features so that writing full blown apps in html, css, and JavaScript is less of a multi-level, multi-language templated nightmare for the developer who's writing it. Facebook was built on PHP so it's possible to build a fully featured web app using PHP and JavaScript, but that's also that's where React came from. React isn't just change for changes sake. PHP and hand rolled JavaScript can take you where you want to go, but getting there with React is just a bit more comfortable because it isn't a pile of templates with two languages you have to keep in your head simultaneously, and you can more easily debug it. For the cost of learning new ways of doing things, there's inheritance and composability. it's far from perfect, but, imo, it got popular because of how much easier it is to wrap your head around a pile of react components than it is a pile of php templates and its attached pile of JavaScript.

Yes, if looking at the right places. :)

https://help.kagi.com/kagi/company/hiring-kagi.html

"""

Core Front-end Team (we are currently full, check back later)

- Passion for creating delightful and swift user interfaces.

- Proficiency in HTML, CSS, and an understanding that JavaScript can be used sparingly to enhance, not create, product experiences.

- You are comfortable not using any FE frameworks, and rather like to be in full control of the DOM and as close to browser as possible.

Fun fact: At Kagi, we prioritize speed, to the point where all functionalities of Kagi Search (except Stripe checkout and Maps) work perfectly without JavaScript. We see JavaScript as a tool to enhance the UX, not create it.

"""

Damn; another reason Kagi rocks. No JS needed!

Unless you use maps or stripe checkout

I totally agree. It's like we've forgotten what browsers and HTML are meant to do.

Back in the day we used to rail on Flash websites because while they looked nice, they weren't accessible to screen readers etc, sites weren't consistent, links didn't turn purple, and the back button didn't work.

Now we've done that again with HTML and React.

Flash is dead, long live Flash.

React and similar frameworks are still generally better for accessibility compared to Flash, but at the same time can be worse because pages may behave sporadically and in unexpected ways, whereas Flash would be a blindspot for many screenreaders and related software.

I don't think that's an exact analogy....maybe if you're using react in some oddball/low skill way. Flash (and ...javafx/applets/whatever the id equivalent was...I can't remember) were 1000x more bumpy than react.

I strongly encourage new junior hires to read MDN, specifications, etc. However, for some, it is like they cannot absorb information if its not in video format.

I'm frustrated at how often a how-to for something that takes three sentences to explain is a video. At the same time, it's amazing for things like simple home and car maintenance.

It doesn’t take a day to do it. It doesn’t even take a day with refactoring. But add in writing the tests, running through QA, code review, getting release approval &c &c and almost anything can take a day.

Right. I don't think adding an HTML link has nearly that much organizational overhead either.

It would at the client I'm working for. Nothing hits Production without going through code review, getting UX approval, testing by QA, UAT testing and approval by product managers, running the automated test suite for the entire application (which takes several hours by itself) to make sure nothing else is failing for any reason, and running through various pipelines. Except maybe a couple of desperately needed hotfixes that process has never taken less than a full day.

Doesn't matter if it's a one line code change (some of my bug fixes have been exactly that).

And often it takes longer because it can take some departments a while to get around to their part of it as they have other things they're working on for other features and tasks as well.

It looks all these rants are from people who need "Hello World" equivalent of web and are angry that there are tools for more complex use cases. I am primarily a backend developer with couple of decades of experience, who is now working on his own startup. I have built a simple HTML/JS site as our launch page. But I would kick out anyone who'll suggest that we should use plain HTML/JS instead of a frontend framework for our main app.

A form submission is not just a post submit. You have to do client+server error handling, dynamically show/hide/add fields, show char count, handle intermittent state and still more. All of these are possible with JS but is faster and more reliable with a purpose-built library. Same goes for a draggable dashboard, filters for search results...

> A form submission is not just a post submit.

Can be. And still work better than a lot of JS-heavy monstrosities.

I agree but it is hard to explain to people what is a difference between a web app and what is 2-3 forms on a website.

Lots of complainants I read seem like people who would do all in plain html never worked on actual web app.

At the same time seems like JS stuff is overused in lots of places and a lot of React or Angular is done by people who want to have it on their CVs.

It's because submitting a form interferes with all the other stuff running on the same page. E.g. after submission animations stop or disappear or skip a frame, annoying designers, etc. etc.

I don't think there is really anything in your "etc. etc." I have never heard from any real user a complaint about animations stopping mid-flow. I think people know how pages work, in that I think they expect clicking things to do something disruptive, altering, changing. It's only been the design astronauts that have argued these discontinuities are "confusing" to users.

If anything, sometimes I think they make the transition too smooth, to the point that it can be possible to miss it. Sharp changes are generally easy to notice.

> I don't think there is really anything in your "etc. etc."

"etc. etc." = anything with state, so this can be quite a lot actually ...

HTMX.

Or worst case scenario, fetch().

But honestly, forms are fine. Not all apps need beautiful animations.

It's better to have great UI, but it's not free.

HTTPS://gov.uk is amazing.

It's not always the right tool but in more cases than modern devs believe, it is.

I've built several web applications recently that don't use any modern JavaScript framework. You'd be surprised how quickly a page can fully reload and equally surprised at how okay of a UX it is to not always persist state.

Here's an example video of an app that does a mix of "state persistence" and "good ol' reload the page" approaches. https://withlattice.com/documentation#nav-create-application

1) Chat interface maintains state (but uses minimal JavaScript)

2) Application status requires a reload

Is this the absolute best UX? Possibly not, but users haven't said anything about it and it's such little code with almost zero dependencies.

Nobody complaining isn't necessarily a "good thing". Absence of evidence and all that.

I've found that it's only like 1/1000 that will.

And this thread (few days ago) about why it's hard to buy nice things touches it https://news.ycombinator.com/item?id=42430450

Many (most?) don't raise issues because they've been conditioned that things won't get fixed.

I'm with you that overdone JS isn't necessary; and we should also consider user-silence to issues to bloat, slowness and jank.

I agree with all of that. Perhaps what I meant to say was that these weren't the things users were complaining about.

I love a beautiful UI and experience. Listen to users and prioritize what helps them.

Forms are the real problem, not the tons of ads, auto playing videos, notification pop-ups, etc :-p

The sites that genuinely need a react frontend are fewer than the sites that use a react frontend. If you forgo react from the start, you have simplicity. At most, track your "state" in a session cookie + "rendering" on the backend. The good old days. I miss them.

Only one day? They must be juniors, that's at least a month or two - few hundred story points, dozen alignment meetings, QA, stakeholder buy-in, A/B tests, security consult, PM/PO/SM/EM/TL sign off, heck just catching up with the UX team alone would add a day's worth of calls.

Input type=“search” has some additional niceties. Html5 is great.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

I'm love old school HTML, need a autoscaling page, lets break out some FRAMESETs and some tables/iframes

> I've seen teams estimate a full day to add a link to a contact form because they need to

Has it ever occurred to you that maybe it only takes them 15-30 minutes (still too much, obviously) but that it is great to be able to only work 15 minutes/day?

Estimates reflect what managers will say ok to, not how much real work it takes.

No, I've seen them do the work. Refactoring those React components genuinely takes ages.

Does it? I'm all too familiar with bad codebases where yes, trivial changes take days.

That's not the fault of the library. It's the fault of the people using the libraries.

I'm not a big fan of web dev at large but there's nothing inherent to React's architecture that makes editing a single component to add a static link difficult (that I'm aware of).

What you're describing is typical average dev that creates impossible spaghetti code and then with an honest heart tells project managers how hard it is to change the color of a button because of incomprehensible tech jargon until the clueless PM goes 'okay okay, will two days be enough?' and the dev goes 'yes, I think so'.

Says more about the team than React.

To spend the other 400 minutes learning something new, right?

this is why I dislike the modern web so much. I love to find websites that are nice and simple, load fast, and have no JS bullshit to render "modern" UIs. But yeah, old man yelling at cloud and stuff... but you know what, I'm fine with that. And I do have the hopes of building something useful and successful that gives the middle-finger to all these "modern" frameworks.

An underappreciated reason people pad estimates is that it gives them some time to breath and know what business goals they personally need to deliver.

In the case of 1 day to add a button, let the developer have a day of knowing "today, my goal is to add a button". Without the padding the developer would be thinking "I'll add that button, but after that I have no idea what's coming, whatever bullshit comes down the pipe I guess".

It's really hard to shift mental gears. People can do multiple tasks well, but only if there is a coherent thread they can follow through those tasks. Current software management philosophies are very hostile to those coherent threads.

I don't do web stuff for a living, but I've been hacking since the early days of JavaScript - what I don't understand is what happened to separation of content, layout and interactivity - most of these react et al. monstrosities start with a big mess of JavaScript generating the html as lisp-like nested trees of tags. in that case, why not just use lisp?

Because not everyone likes writing lisp?

writing lisp in JavaScript is so much worse!

It worked for documents and maybe sprinkling jQuery here and there.

For web apps it breaks especially for SPAs really quickly.

So I believe it went out of the norm like 10 years

it's not like SPAs are more responsive today - they're horribly sluggish and things break constantly. modern and trendy doesn't mean better in any way.

People realized that slicing it that way wasn't nice to work with.

The htmx guy has a small post on this. https://htmx.org/essays/locality-of-behaviour/

The example there is kind of poor. The problem isn't that the implementation is separated (in fact the implementation of `hx-get` is just ignored, which is cheating). The problem is that the jQuery example is using a button id to specify behavior instead of an attribute like the htmx version. Old CSS wisdom was to give your elements meaningful classes and apply properties to those. Or xpath let you do pattern matching on elements/attributes and apply templates to that.

So the jquery version could be the same as the htmx one, but you do `$('[hx-get]').on("click"){...}` or whatever (I don't know jQuery/do javascript).

regardless of what CSS query you use to look the element up, in the jquery example you'd still have your logic (the url, etc) defined elsewhere

the htmx version is symmetric with the href attribute in that it completely specifies what is going to happen directly on the element itself

of course you could do something in jquery like using a data attribute to store the url and HTTP method, etc, but at that point you'd be building https://intercoolerjs.org, the predecessor to htmx that was built on top of jquery

> button hx-get="/clicked"

that doesn't look like a complete subroutine to me.

it’s not, but it is a complete specification of behavior, just as <a href=“/clicked”> is

that sounds about as helpful as a chocolate teapot.

I have never used a chocolate teapot, but anchor tags (and form tags) have been an important piece of the success of the World Wide Web as a hypermedia system.

htmx generalizes this notion of hypermedia controls in a syntactically symmetric manner, preserving the locality of behavior inherent in those controls.

https://dl.acm.org/doi/pdf/10.1145/3648188.3675127

it's not about the tag, it's about the claim that putting /clicked in the href or equivalent is somehow superior to $("#the-button"). click(function () { do stuff here}).

right exactly, it is superior in Locality of Behavior (LoB) terms because the behavior of the tag is apparent by only looking at it, whereas in the jquery example the behavior is in code that is located elsewhere.

It is also inferior in Separation of Concerns(SoC) terms.

These two design principles are in conflict and the reason I invented the term LoB was to help people, like myself, who prefer locality to argue for it effectively in software design discussions.

so a comment would have done the same job? you don't need htmx to add a comment.

man, that's a really good point

The htmx behavior is exactly as specified as the jQuery behavior, as what I'm suggesting is the last thing you said: you can literally implement the htmx attributes with jQuery.

That factoring has been the recommended way to separate concerns since before jQuery existed (e.g. with xhtml). Selecting specific IDs was always bad practice. Same with CSS. You were meant to use properties.

Tellingly, this is how html itself is designed. It's had ways to add your own tags since nearly the beginning, and the built-in ones stand as examples of how to design your custom tags' apis.

regardless of what CSS query you use to look the element up, in the jquery example you'd still have your logic (the url, etc) defined elsewhere

the htmx version is symmetric with the href attribute in that it completely specifies what is going to happen directly on the element itself

The htmx also has the logic defined elsewhere. It's literally exactly the same html.

with an anchor tag's href attribute, is the logic defined elsewhere?

If you're being consistent, yes. The DTD specifies that you should refer elsewhere for the semantics, just as <button hx-get="/clicked"> has semantics that depend on whether you say "this is htmx" or "this is X library based on jQuery". Or alternatively those things all exactly specify the behavior, and you can go look at their specification for the details.

fantastic I think the idea of locality of behavior is one that will not make sense to you

To the extent that it depends not on the code or its behavior, but on the interpreter that runs it, I suppose so. If you write the exact same code with the exact same meaning, I'm not sure why it matters.

exactly

2 neat libraries I've found to work like this are Surreal[1] and CSS-Scope-Inline[2] to get your Locality of Behavior (and Style) without a huge overhead.

That said, your markup can get unwieldy fairly quick, and you end up with a lot of similar and duplicated code/style blocks. My solution on a personal site, was to also use a backend-style templating library with partials[3], a file watcher[4] to build them automatically etc to kind of SSG a static site while maintaining reusable components. You can see where this is going, at what point does it make sense to just "reach for xyz framework" out of the gate? For as often as people (especially here) cry "ya aint gonna need it", there are at least as many times where people (less vocally) cry silently to themself, "I wish I'd just used a framework instead of unintentionally building a franken-framework".

This from a minimalist developer who has been doing it for a long time, with STRONG opinions about the modern state of the art. Honestly, it's very common for me to feel torn about ideals vs actual pragmatism.

[1]: https://github.com/gnat/surreal [2]: https://github.com/gnat/css-scope-inline [3]: https://github.com/leafo/lapis [4]: https://gittup.org/tup

woah! i couldn't agree more. i built my own router for React because i was exhausted by having every link be some overly heavy abstraction around... a few characters of text. KISS is key for me.

The complexity makes automated testing easier. We arrived here for reasons that may or may not not be critical to you but warranted implementation nonetheless. There is no conspiracy.

Unfortunately, many of us are choosing to forgo the productivity gains you and DHH provided via Django and Rails.

Forever grateful to you folks.

Reply on news.ycombinator.com