The first is nothing but HTML and text, the second is a fully functioning web front end to a DVCS with issue tracking and documentation, plus metrics and graphs, all only possible due to the 'worsening' of the web with Javascript, CSS, Flash and so on.
I know I prefer GitHub, and the same is true for most modern web applications where there is a choice. And apologies for the shameless Apache Brooklyn plug ;)
Why would you need JS, CSS or Flash to have issue tracking, documentation, metrics or graphs?
An issue tracker is essentially a forum where the threads have an open/closed state attached. People have built such web applications before JS even existed.
Documentation is even simpler, just a bunch of HTML documents, maybe with an HTML form to edit them.
The problem with your first link is not the lack of CSS, it's that the information listed is less relevant than what Github shows.
But instead of comparing with that, try disabling the CSS in the GH page. Ignoring the header section, I think the file list and README look just fine, and I wouldn't be bothered at all to use it as such.
You'll notice though that the main documentation on github is basically just what we already had in the web 1.0 days and not much more.
We had most of those other things in the web 1.0 days too.
Here's a directory hierarchy that's just as navigable as github's
ftp://modland.com/
in the old days, ftp sites used to even have some kind of readme that browsers would autoload and put at the top of the directory list as documentation.
Graphs have been back-end generated and served in web 1.0 days as well and just inlined as <img> tags.
It was basically the same, with less control of look-and-feel, but about as usable and hundreds of times quicker. Responsiveness and accessibility just sort of "happened".
I agree with you, but it's not about what you prefer, or what I prefer. It's about what can be done. The great thing about the web is that we can have BOTH of these designs. If Jack prefers #1 and Alice prefers #2 then there's no problem as they can both co-exist.
But if Jack starts saying design #2 is awful, so we should remove the ability of browsers to display that kinda stuff, then Alice has to use #1 and may well stop using the issue queue entirely. That doesn't seem like a good outcome.
Let's optimise so that the maximum amount of utility can be had by the maximum number of people, instead of trying to push our own worldview on what the web should look like.
The first one is at least kind of responsive. I can zoom in my web browser and get a text size that I'm comfortable with.
On GitHub, I vastly prefer the mobile site. Unfortunately you have to spoof your user-agent to get at it on desktop.
I use a lot of mobile versions of sites, even on desktop. They're usually much better for me. To a large extent because they're simpler. Even news sites tend to have mobile versions that are somewhat human-friendly, easy to understand, fast to load, etc.
Who knows why the built-in Git web UI is so abstruse? Whatever the reasons, they have nothing to do with Javascript, Flash, or even really CSS. A skilled and dedicated designer or typographer could certainly come up with a simple text-based layout that conveys the necessary information, if that were the restriction. Probably git's web UI is not the result of professional designers?
1. https://git-wip-us.apache.org/repos/asf?p=incubator-brooklyn...
2. https://github.com/apache/incubator-brooklyn
The first is nothing but HTML and text, the second is a fully functioning web front end to a DVCS with issue tracking and documentation, plus metrics and graphs, all only possible due to the 'worsening' of the web with Javascript, CSS, Flash and so on.
I know I prefer GitHub, and the same is true for most modern web applications where there is a choice. And apologies for the shameless Apache Brooklyn plug ;)