31–40 of 79 posts
that is totally unsurprising, i would use javascript to build github too. why is this on the front page?
Lean, mean javascript only bothers hardliners. But everybody suffers a user experience hit from async-javascript-for-the-sake-of-it
At the end of the day GitHub is a web app. I don’t think it’s worth complaining about unless it’s something like Wikipedia that stops working.
I see that GitHub now tries to become at the same time a social media for hacker-friendly people and some sort of super-CI server with automation. For sure these are good features. However I also see why people are sad that the old (and defining) functionalities stopped working without JS.(look at commit, browse the sources, read and submit issues / PR and code review). It saddens me a bit to often see working websites getting more and more complex, adding more and more features, probably to remain "fancy" and competitive.
I think GitHub being an SPA is largely fine, it has good reasons to be in many situations, what I object to is when a shopping site or, even worse, a content site requires JS to work. This seems terrible when serving HTML is a much better experience for most users.
Which is fine ... but something has gone wrong somewhere if we require a full blown programming language to display text on the internet. It is absurd. It is one thing for HTML with a bit of extra JS on the side, but to be unable to display text without scripting enabled is comedy.
And if nothing else this really makes searching and indexing harder. That isn't good for the average internet denizen.
The least important part, I guess. /s
Honest question and no pun intended: I don't understand people's desire to prevent JavaScript from being a language that runs in the browser. Could someone shed some light on this?
https://en.wikipedia.org/wiki/Semantic_Web
This is a really important point, because the worldwide web (www) was designed for openness, collaboration, and compatibility.
This is also the origin of ideas like XML, which were designed to have schemas, namespaces, and transformability.
A lot of principal ideas have been lost in the name of productivity or profitability. Which is undermining innovation, free data movement. Also, JavaScript also used to be a weapon in the browser wars for creating incompatibilities in browsers (see Internet Explorer).
So the saga is rather complex. But the conclusion is clear: if you care, insist on openness and compatibility on the web. And study the classics, the original design principles of the web, and their motivations.
I think GitHub being an SPA is largely fine, it has good reasons to be in many situations, what I object to is when a shopping site or, even worse, a content site requires JS to work. This seems terrible when serving HTML is a much better experience for most users.
(As an aside I hate the Jira UI for being the same.)
I think GitHub being an SPA is largely fine, it has good reasons to be in many situations, what I object to is when a shopping site or, even worse, a content site requires JS to work. This seems terrible when serving HTML is a much better experience for most users.
> This seems terrible when serving HTML is a much better experience for most users. Tracking. Pure HTML doesn't allow much tracking. Our sector convinced c-suite that we need all kind of data, and now they want it.
Earlier quoted context omitted.
> This seems terrible when serving HTML is a much better experience for most users. Tracking. Pure HTML doesn't allow much tracking. Our sector convinced c-suite that we need all kind of data, and now they want it.
Tracking isn't always bad, it is often being used to make the product better and discover usability issues.
Very poorly collected data, analyzed by people without much understanding about ux/product or data, and without any sensibility or intelligence took the place of thorough user interviews.
An example: in an ecommerce I've worked, a much better image gallery was released to show products than the previous one. All data showed users interacted with it much more. But it also showed conversion going down. The old gallery nobody used was then picked again and conversion went up again.
Now, what really happened was that users liked the gallery, what they didn't like where the pictures of the items. Those made them re-think buying it.
Thus, a crappier version of the website was released again, and users ended up having a worse experience, all in the name of the better conversion.
Seriously, with all due respect, I worked enough on front end and data collection to know that the whole tracking is generally harmful towards the user, slows down websites considerably, violates their privacy, leads to a worse experience and only rarely shows anything meaningful that user interviews wouldn't got.
It's mostly snake oil for c-suite, data "analysts" and product people and marketing so they can pretend they are providing any value. They generally aren't.
Honest question and no pun intended: I don't understand people's desire to prevent JavaScript from being a language that runs in the browser. Could someone shed some light on this?
JavaScript itself is not usually the problem (aside from certain fundemental issues). The computational gap between a developer on a M3 Macbook and a person on a used Dell from 2008 is already quite large, meaning what feels "snappy" and "responsive" to the former can feel "sluggish" and "annoying" to the latter. The other factor between the two people can be network speed, many areas of the world have access to extr…
If you do a View Source on Reuters.com main landing page, it's script file is a single line that's 1,300,000 characters long. And every time you land on a page it tries to dump 1,300,000 characters of script on you (on top of the multi-MB videos it auto-loads) [and the pop-ups]
Most major corporate websites are that way. All written by algorithms with massive JS downloads and huge 64bit hash keys on every . Tracking 64bit click numbers on each element and dumping all the calculation on the user.