Is it? I know hating CSS is a fun pastime for folks around here, but maybe it’s just that building good, rich user interfaces that people can use is an inherently hard problem.
Sure, the browser is slightly more difficult due to maintaining backwards compatibility and multiple implementations, but I’ve yet to see a better UI framework/language that has to deal with the other constraints of the web platform.
> I know hating CSS is a fun pastime for folks around here, but maybe it’s just that building good, rich user interfaces that people can use is an inherently hard problem.
That CSS and web never really addressed did they? There's almost nothing in the web platform to build rich user interfaces. You can barely do styled text.
CSS and HTML are literally littered with accidental, ad-hoc, badly thought-out and badly designed one-off solutions, often to problems no one asked for. There's a reason it took until 2026 to animate `height: auto`. There's a reason why `article` "semantic" element has to be used when you display product cards or widgets. There's a reason why CSS scoping has been stuck in limbo for 10+ years. There's a reason...
The web is one of humanity's greatest achievements. But let's not pretend that it's not a textbook study in accidental complexity.
> That CSS and web never really addressed did they? There's almost nothing in the web platform to build rich user interfaces. You can barely do styled text.
Let me guess, you stopped reading web standards documents because Facebook told you it didn’t matter, since you could just ship 10MB of javascript with every request
Right - but those constraints are inherent to the medium. Like basically unconstrained screen sizes from large desktops to mobile, with the user free to resize anywhere in between (and can't be constrained in the way that 'real' apps often are). Input methods of both fine mouse control, and course touch.
> Is it? I know hating CSS is a fun pastime for folks around here, but maybe it’s just that building good, rich user interfaces that people can use is an inherently hard problem.
I dunno, seemed easier 20+ years ago when in high school we were taught how to use Delphi than now.
HTML/CSS is just terrible way to build interfaces. It was made to build basically resizeable documents, not applications, and it shows in every crevice
It is a hard problem. That is why in the pre-browser days a small number of entities did the hard work and gave the rest of us mere mortals tidy APIs to make use of their efforts without everyone having to painstakingly duplicate what they created each and every time.
But then CSS came along and threw out the baby with the bathwater, returning us back to the bare primitives, forcing entities to redo all that work again. Except this time CSS didn't offer a good mechanism to wrap up that hard work in a nice API bow, so everyone ended up getting pushed into having to redo that same hard work every time they started a new project, leading to a bunch of poor, inconsistent, and often downright wacky implementations.
To be fair, the problem isn't CSS per se, it is just that it is much too low-level for all but the small number of entities focused on the aforementioned hard problems and browsers failed to offer anything higher-level for the rest of us. Javascript has tried taking on a stand-in role for the lack of the higher-level abstraction being natively offered by the browser, but that comes with its own limitations so it isn't always a viable choice, not to mention that having to resort to using a full programming environment completely defeats the purpose of having CSS.
CSS gets all the hate because it is more often than not the wrong tool for the job but the only tool available at hand.
CSS is for styling documents, not for creating applications interface (which has a whole sets of constraints). It's like trying to use typographic design rules to create a car dashboard. CSS is great, just not fit for that particular job. There's an handful of properties that are the same (padding, margin, border, background color,...), but one common thing with native toolkits is that they have specific widgets for layouts.
It is for styling documents, but nobody (except for maybe designers trying desperately cling to a job) wants every document to have a bespoke style. I want to use a style created by experts that is consistently shared with every other document across the whole of the internet. CSS is fine as a low-level primitive for those experts, but it is not the mechanism the rest of us should be using. However, there is nothing in-between, at least not unless you lean heavily into Javascript, but, again, if you are going to use a programming environment then CSS is pointless anyway. There are much better ways to draw to screens when you have a programming language at your disposal.
People do want bespoke style (think booklets) and there’s a load of templates (and frameworks) on the internet if you want a standard set of components. The web as a platform was built for documents, and when we try to twist it to do applications, the crack appears. It’s just the wrong tool for the job.
Javascript is used for the Gnome shell and it’s doing a fine job there. And if you paired javascript to something like Tk (as in Tcl/Tk), I guess it would be fine too. The web primitives are just horrible for desktop uses.
3 months post Microsoft acquisition, GitHub expanded the free plan to include unlimited private repos.
The next year they removed the limitation on collaborators on private repos for free users.
In the last 4 years they’ve significantly improved their project management tools. I think a lot of teams can make do with GitHub Projects, they’re pretty decent.
Who knows if any of these are directly because of Microsoft or not. But there has naturally been material improvements to GitHub in the years after being bought by Microsoft.
Some AI systems have done things like hack out of a docker container to access correct answers while being benchmarked.
That is mildly concerning and I will give holding the AI accountable to some degree when it is actively being malicious like that, even though the user could have locked things down even more.
But it had write access to the prod DB without circumventing controls and dropped your tables? That is just a total fail.
Maybe fixing the root cause is slower, and this janky workaround was quicker as its something largely already built (a few views/links in Github already open issues in a drawer).
You've never done a temporary fix to stop the bleeding?
This seems uncharitable. Priorities aren't exclusive, especially at scale across large engineering orgs like GitHub. It could be that these are the top level priorities, but teams or individuals who aren't able to contribute to these priorities will work on other things like new features.
Agree that priorities aren't exclusive and there may be teams/individuals that aren't able to contribute if they stay in their current teams/roles
Where it becomes questionable though is when enough progress isn't being made on the top priority (reliability). If Github is being true to their word, they need to be pulling people off of teams that are working on features to work on reliability so that top priority gets the resourcing it needs.
Given the pace of improvement, and the cited example of moving to Azure from months ago, it's not super clear they are doing that. Also not clear that they aren't, maybe the move to Azure is just a more than 6mo project no matter how many people are on it.
Sure, but frontend devs fundamentally cannot contribute to the structural reliability issues.
The person who rewrote the issue page view probably doesn't know anything about multi-cloud scaling for millions of users with Azure-crippling throughput. That's an incredibly specialized set of knowledge and experience that is utterly disjunct to frontend work.
But at the same time, given the state that GitHub is in, I personally wouldn't want to allow any devs to push anything to prod that doesn't immediately affect stability. I'd completely freeze frontend work until the infrastructure is more stable. But then again I write C for microcontrollers so what do I know?
I don't know their architecture but I would bet if FE devs wants to contribute to availability in a capacity-constrained world (as GH CTO mentions) they could focus on profiling and optimization, backend-access patterns for example, caching, etc. Maybe they already have people dedicated on that but if they are coming out of a "new features first" operating regime I would bet there's some fruit to pick there.
I disagree with that,
There’s likely quite a bit frontend devs can do to improve things. Stuff like optimising the requests to reduce the load being put on the backend.
Ditto. I agree though, just because the priority is reliability, doesn't mean others can't work on features, especially features that might help with reliability, which I read was the motivation behind the new single-issue view, so that's my bad, might have been a bit much.
I still think the rest of my point stands, especially the last one which is the move that has the biggest impact to the most of us developers.
Is it? I know hating CSS is a fun pastime for folks around here, but maybe it’s just that building good, rich user interfaces that people can use is an inherently hard problem.
Sure, the browser is slightly more difficult due to maintaining backwards compatibility and multiple implementations, but I’ve yet to see a better UI framework/language that has to deal with the other constraints of the web platform.
reply