So many red flags in the abstract alone. It's no surprise that the article itself looks like a middle school project.

You sound very confused.

How do you screw up tapping with two fingers?

Using `display: table` is a great way to lay out your elements in a grid while keeping your HTML semantic.

who said tables aren't semantic? Tables say "Hey, I'm going to show you some things with a row column relationship now." Some times table is exactly the semantics you need. It shouldn't be your primary and only tool but if your showing a set of numbers collated and sorted by rows and columns then its pretty much semantically a perfect fit.

I see this argument a lot. You're right, there are situations where tables are semantic. But unless otherwise stated, it's fair to assume that someone who's talking about semantic markup knows that semantic markup includes tables, but simply discourages them for 99% of layout purposes.

No good if you care about IE6 support

Unless you have a boss telling you to support IE6, you don't. People need to stop using this prehistoric excuse for a browser.

As you said, some people work at companies that mandate its use - they have no choice. While that's happening, it needs to be considered.

If by no longer supporting IE6 we can force these companies to finally go with the times, then by all means, no, we should not consider this. We cannot endlessly cater to every outdated technology ever.

Besides, these companies have absolutely zero valid reasons to keep using this crutch - it's severely outdated, a giant gaping security hole and a hindrance to the entire world wide web.

And no, legacy applications built upon IE6 on which some corporations have based their entire internal communication (or other things) are not an argument for supporting IE6, but instead gives us all the more reason to force them to get rid of it.

> view source

Are you trying to tell me that PG is not a web designer?!

Any chance of doing an internship? I'm doing my master's in maths in Berlin and have experience with development in Python and Clojure.

In web-development (which is where your skills would apply most) we don't do internships.

No, that's not what he's saying... and I don't know if you realize this, but the author, P.J. Eby, is the same guy who wrote the original WSGI spec.

> I don't know if you realize this, but the author, P.J. Eby, is the same guy who wrote the original WSGI spec.

yup (though to conclude anything from that fact is a clear fallacy).

I've realised that what I actually disliked most was his blog-post and not the actual project (I've used identical shims to wsgi-lite by choice over the years).

"CAN'T REPLACE WSGI WITH SOMETHING BETTER? CHALLENGE ACCEPTED"

"WSGI IS DEAD" (Except when it isn't.)

I realise that the above was probably done for facetious editorial reasons rather than his actual intention with the lib. He hasn't really replaced wsgi, he admits should only be used wherever appropriate

Armin uses the async point in part to give technical reasons why WSGI can't really be replaced in full, before concluding that he thinks replacing WSGI for purported notions of pluggable utopia is a red-herring anyway before posing the question of any WSGI replacement: does this really '[make] frameworks work better with each other?'

I don't think PJ really tackles any of that.

> Maybe my "simple" is to have the ability to yield chunks of data as it gets generated using chunked transfer.

I'm curious, have you ever actually had to do this? Even Rails only just got this feature in 3.1 (http://weblog.rubyonrails.org/2011/4/18/why-http-streaming).

Yes I had to do this for an interactive media site.

I agree with you, but Pump is not a web framework. You are not supposed to write your application with Pump. Picasso is a framework I built on top of Pump (https://github.com/adeel/picasso) that's more suitable for that.

(I can see how you could get a mistaken impression from reading the discussion on HN, though.)