Lotus Reader - The Hackernews Client

Lotus Reader

If you click (or tap) on the name of a parent in a discussion, you will be directed to the comment that the parent wrote.

GitHub is replacing Rails front end rendering with React

todsacerdoti

3 years ago

111

121

https://twitter.com/rauchg/status/1591464351990697984

pacifika3 years ago

GitHub probably is more of a webapp than a webpage at this point, so makes sense.

superkuhpacifika3 years ago

Yeah, supporting people who use older software and older computers doesn't make financial sense for Microsoft. Plus now it's a lot harder to index the pages so it's more lock-in. Web apps have so many advantages for for-profit corporations in filtering out the unprofitables.

lghhsuperkuh3 years ago

> Plus now it's a lot harder to index the pages

Why does using react mean it is harder to index pages? You can certainly write something that's difficult to index in React, but using React does not mean it is inherently more difficult to index. This is especially true if you're using SSR + modern react features with a meta-framework like Next.js

> supporting people who use older software and older computers doesn't make financial sense for Microsoft

Pretty much the same point here. Fundamental misunderstanding of React.

1123581321lghh3 years ago

You just said it: if your HTML delivers a react app that hasn’t taken the extra steps to be SSR, then the crawler has to run the JS in order to index the content instead of just parsing the HTML response.

shadowgovt11235813213 years ago

Modern component libraries make it harder to write the site in a non-indexable way than to just make it easy to index.

1123581321shadowgovt3 years ago

Only as a user of Next and similar renderers. The default in the larger web application world is to ship an empty target element and a JS bundle.

sailasuperkuh3 years ago

I just disabled JS in my browser and most stuff still works, although there's a few things that don't, like loading commit data and dropdown menus. I would guess they're doing server side rendering and progressive enhancement so that at least the core functionality still works okay.

eyelidlessnesssuperkuh3 years ago

Guillermo (Twitter OP) replied in the thread saying it will be server rendered. Other replies point out it’s not enabled for all users, so this (and presumably the UI changes it brings with it) isn’t final. I do see the changes, but I also opt into most if not all preview features and I wouldn’t mind if I’m part of an A/B test or whatever.

I wouldn’t be so paranoid to think this is some nefarious plot, it’s probably just incomplete. Whatever their “lock in” strategy, it’s more about building and extending a feature moat that users don’t want to leave than restrictive dark patterns. Harming searchability is more damaging to GitHub (which thrives on being highly ranked in Google/etc searches) than it could possibly be to would-be defectors who are almost certainly capable of using their API either directly or by using any number of tools to do that for them. If anything, shipping this widely as-is would probably drive users away not lock them in.

Judging by the timing of adoption of React/Next for their Blocks landing page (also mentioned in the Twitter replies), I wouldn’t be surprised if this is intended to be rolled out alongside further stabilization of React Server Components, or otherwise integrated with existing internal SSR implementation. (Leaning towards the former given it’s a Vercel person speaking confidently about GH’s plans for server rendering)

davziepacifika3 years ago

I have to say, the notion you can only build webpages with Rails and not webapps did make me chuckle.

If Rails can take a company such as GitHub this far then it, along with other traditional server side rendered frameworks like Django and Laravel, should more seriously be considered when starting new projects and apps.

threatofraindavzie3 years ago

If you've already mastered a system, then the n+1 case is going to be much more timely and cost-effective. So if you know RoR and you've got a similar team then go for it. But for greenfield projects I'm not sure one should go with Ruby on Rails, and this is coming from someone who used Ruby before Rails.

If I'm not mistaken, even 37 Signals made a new framework for their new Hey app.

https://hotwired.dev

mnuttthreatofrain3 years ago

Hotwired is a ruby gem that sits on top of Rails' existing Turbo approach: start with a regular server-rendered ERB page, layer on Turbo to allow for page updates without page refreshes (via XHR-fetched html fragments) and layer on Hotwire to sync state with websockets.

systemicdannadavzie3 years ago

I absolutely love Django and used it for many many years for all my new projects. Nowadays I only use it in a very limited set of use cases. Having an instant admin UI is a huge advantage for some business cases, flexible auth is great, very fast prototyping is still amazing, etc. Wouldn’t choose it for any front end heavy app.

scrollawaysystemicdanna3 years ago

Have you looked into Django Ninja?

I use FastAPI exactly because of the reasons you point out... but damn do I miss the Django ORM and admin. Django-Ninja is an acknowledgement of the realities of that.

systemicdannascrollaway3 years ago

Having heard of Django-Ninja before. Looks really good! If I understand correctly it would allow me to keep the best parts of Django (ORM, Admin UI) and build a FastAPI-inspired API? That’s an awesome combo! Curious to see benchmarks how it compares to ExpressJS.

trey-jones3 years ago

I can't believe they were still running a rails frontend til now, to be honest. I thought rails had fallen out of favor at least 5 years ago (deservedly in my biased estimation). We'll see what happens with Github. I don't have any use for the new bells and whistles like editing the repo directly from the webpage (scary!), or deeper VS Code integration. I'm not interested in Co-Pilot, though a co-worker told me the other day that it had saved him hours in a particular instance.

I just hope they don't kill the parts that I think are useful, and the things that made GH so valuable in the first place. It's a worrying trend that software seems to get worse for users in the name of making more money.

cientificotrey-jones3 years ago

Why can't you believe they were using rails?

trey-jonescientifico3 years ago

I didn't say I couldn't believe they were using rails. I knew very well that Github was originally written on Rails. I was surprised to learn today that the frontend was still rails. The narrative in my head was that, like Twitter, which started as a rails app and eventually outgrew it, Github had abandoned Rails some years ago.

CharlesWtrey-jones3 years ago

> I thought rails had fallen out of favor at least 5 years ago (deservedly in my biased estimation).

For the folks downvoting, GitHub said basically this in 2018: https://www.theregister.com/2018/08/16/github_rails_microsoft/

"GitHub is about a third of the way through an architectural change that began last year. The company is moving away from Ruby on Rails toward a more heterogeneous, composable infrastructure."

This doesn't mean that they're rewriting Rails infrastructure for the sake of it, so legacy Ruby/Rails software will presumably power big chunks of GitHub for many years to come.

deergomoo3 years ago

This seems like a good move. GitHub worked great using server rendering for a highly interactive app, but it was quite easy to end up in a situation where two UI elements would show different things for the same piece of information, because one was updating live and the other wasn't.

agosdeergomoo3 years ago

Easy way to make the UI end in an inconsistent state: when somebody asked you to review a PR, you’ll see an “add your review” banner and CTA. If from that same page you add yourself as a reviewer the banner won’t appear unless you reload

cntainer3 years ago

Honestly github always felt snappy and intuitive to me, more so than many "cool" react fronts I've seen.

It would be great if they wrote an article about this switch to understand some of the challenges they were facing.

I would also be curious if they considered other approaches and stacks.

ronniercntainer3 years ago

I don't have any data to back this up, just my opinion, but I prefer backend rendered sites with Javascript augmentation for the parts that need it. Just feels faster.

These JavaScript UIs feel clunky and slow IMO. Maybe it's the (sometimes) dozens of calls the UI make back to the server to get data whereas if it was all rendered in the backend the round trip time would be a lot faster since the server is closer to the data, but my browser needs to make a call across the internet to the server and then to the database or whatever.

Also for tools websites at companies I work at, as a backend dev, building those tools in react is huge overhead. Webpack and react and redux etc. It's a lot to deal with for some simple tool. I'm wondering how much internal tool websites built in react slow down the development process at corps.

323ronnier3 years ago

In theory React websites should transfer less data since you just send a JSON model instead of one annotated in full HTML markup. The React runtime would be cached after the first visit.

martinald3233 years ago

The problem isn't the amount of data but the number of round trips required to get it.

Imagine you need to do the following calls to get the page rendered with the various information different parts of the page has:

1. Get user information

2. Get projects for user

3. Get the selected project

Now, if this was all server side rendered, it might take 1ms to go to the database and get the various bits of info, or 3ms for 3 sequential requests.

With a react app and say 250ms of latency to the database, you're looking at 750ms of overhead - 200x slower.

Of course you can architect all your APIs to always return everything the user needs so they don't have to do multiple requests, but that has its own drawbacks and honestly is very difficult to do and plan ahead for, especially at scale with multiple consumers of various APIs.

lomereitermartinald3 years ago

What you describe is solved with GraphQL, which is a very mature technology by now.

ronnierlomereiter3 years ago

Now we are in the world of graphql, react (and all the other stuff that comes to react), plus the backend server and language. It's a complicated world and I'm not sure we really need that much complexity. There are times when it is needed but I think we've over done it in some cases where we can just have a golang or ruby backend server that renders the page server side. I recently did this and it's a very good feeling just sticking to my server side language that I use daily + html.

lomereiterronnier3 years ago

Who are these 'we'? It's all up to personal preference in the end. As Github demonstrates by postponing SPA framework adoption, there are enough companies out there that share your desire to keep things simple.

ronnierlomereiter3 years ago

We is our industry.

lomereiterronnier3 years ago

Our industry is so disorganized that after half a century 'Software Engineer' is still not a recognized profession, and there is just as little interest in unionizing. I lack the audacity to make sweeping judgments about it.

cercatrovamartinald3 years ago

NextJS server side rendering and React Server Components basically solve this problem.

coffeefirst3233 years ago

That’s the theory, but every time I measure it the combined data and JS needed to render it wind up being more than plain HTML both in bytes transferred and milliseconds to render.

There will be exceptions of course, but I haven’t found them.

throw_m239339ronnier3 years ago

> These JavaScript UIs feel clunky and slow IMO

They don't feel slow, they are slow, even more so on mobile, but developers have stopped caring about mobile web performance a long time ago. So much for "flash is killing my battery", now it's Javascript.

paxyscntainer3 years ago

Snappy and intuitive while loading static pages of text, sure, but their code browsing and search experience needs massive improvement. I'd love to not have to clone a repo and pull up an IDE just to be able to understand the code.

theggintheskypaxys3 years ago

Trur, when I need to browse code I just use codespaces, which you can access by using github.dev/owner/repo, or pressing dot ( . ) when inside the repo

gw98paxys3 years ago

Actions is also a broken pile of shit. The UI falls to bits constantly.

diarrheagw983 years ago

I work with it on a daily basis and am still confused by most pages in Actions.

brightballdiarrhea3 years ago

Gitlab ftw on the CI front

williamdcltpaxys3 years ago

GH Codesearch is in beta, it seems to improve exactly that

diarrheapaxys3 years ago

It’s not impossible to imagine Web IDEs surpassing desktop ones, but it’s not happening anytime soon. Until then desktop IDEs will remain superior, so this experience won’t change anytime soon. For every new feature a web IDE adds, we’ll end up missing desktop features still.

papitocntainer3 years ago

One thing they did at Github years ago was get closer to the metal by ditching JQuery. You can do the same things - and more - with ES6 and updated browser support pretty much across the board. Nowadays you don't even need a transpiler.

https://github.blog/2018-09-06-removing-jquery-from-github-frontend/

noahtallencntainer3 years ago

I actually disagree — GitHub has been relatively slow for me when it comes to page transitions. For example, switching between a PR’s various tabs would probably be a lot faster with client rendering.

Of course, performance will come down to how well the team builds the site and optimizes it. It is very easy to make a site slow in so many different ways. You always have to be looking at and optimizing it for improvements, both on the client and server. React isn’t immune to this, just as various server frameworks aren’t immune to it either.

hardwaregeeknoahtallen3 years ago

Agreed. I'm rather surprised at people in this thread saying they prefer GitHub's server rendered setup. I use GitHub a lot in my job and it feels rather slow/clunky.

Aeolunhardwaregeek3 years ago

All the people that were used to Bitbucket’s 20s page loads think Github is heaven.

cntainernoahtallen3 years ago

I'm curious what relatively slow means for you.

As an example I just made a quick test from my Firefox mobile browser in desktop mode and the switch between PR tabs is not instant but close enough to not be bothered by it.

adamredwoodscntainer3 years ago

Interesting, they use html content templates for code re-usability, which is more difficult to use than React.

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

mirekrusin3 years ago

Funny to read this because since couple of days I've noticed github is loading noticably slower for me. I thought something may be off with my internet connection (I'm on 400 Mbps in Switzerland, M1 16GB, FF).

StreamBrightmirekrusin3 years ago

It is noticeably slower. I do not have the data to back up this claim though.

dombeszmirekrusin3 years ago

I second this, this week was noticeably slow.

rocketbopmirekrusin3 years ago

Had the same experience since Thursday or Friday.

jakub_jo3 years ago

Not sure how I should feel about this. GitHub always felt snappy to me. It's a joy to use and I always admired their approach sending html over the wire. Let's see how this unfolds in the future.

z9znzjakub_jo3 years ago

I'm not a frontend guy, so maybe someone else here knows how to effectively benchmark the current system. I would be very curious to see how the current system performed versus a new React FE. Surely MS will do this themselves, but I don't know if they will publish it (especially if it shows the net result of the change was negative).

systemicdannaz9znz3 years ago

There is also a very big difference in dev experience/toolset and dev velocity between RoR templates and React. Large apps that use RoR or Django templates become very messy and unenjoyable to work with over time. Plus being able to reuse parts of the state on the client is a big productivity boost.

For me personally API+front end is a much cleaner and productive paradigm than having to pass massive dictionaries from a controller to a template. This separation of concerns allows to focus on and optimize data sources/retrieval and UI/rendering independently. Really nice!

DoesntMatter22systemicdanna3 years ago

Api + a fe framework is easier than all backend? .... Ohhhh kay

systemicdannaDoesntMatter223 years ago

"Easier" is a difficult word to describe and agree on. Building rich UI is incomparably faster and more enjoyable in React than it is in Django or RoR (hence why most rich web UIs are built using JS frameworks).

Deploying API and FE separately can also be more efficient, as these services likely require a different tech stack, a different scaling/load balancing setup, and have a different release cycle.

DoesntMatter22systemicdanna3 years ago

> incomparably faster and more enjoyable in React than it is in Django or RoR

That's a complete opinion as well.

systemicdannaDoesntMatter223 years ago

Do you think older tech companies are migrating from pure backend to API+React architecture because it’s trendy and fun?

When was the last time you read about a UI heavy web app migrating from a JS framework to Django templates?

FerociousTimessystemicdanna3 years ago

> than having to pass massive dictionaries from a controller to a template.

Don't you pass already massive JSON payloads from your API endpoints down to your client to update the views?

How's this any different than your hypothetical or even real world scenario?

systemicdannaFerociousTimes3 years ago

API can be a very thin layer that a well constructed client can utilize right from the "view" (a React component). A template file in a backend framework is a one-way feature in the majority of cases. You have to construct and pass _all_ its context (or create helpers, global context, etc) every time. So the controller needs to request data, prepare it (template data manipulation is mostly minimal), pass it. Basically a controller starts doing too many things over time, too much business logic is added to accommodate pretty low featured templates.

> Don't you pass already massive JSON payloads from your API endpoints down to your client to update the views?

Not really. You send many parallel API requests from the client, each response is a smaller JSON. And when you navigate to the next page, most of its data is already in your state, so you have to request just the missing part (e.g. a different post). When you are constructing context for a page on the backend you have to provide all its context every time. The template doesn't make requests based on some logic.

ianbutler3 years ago

I wonder if they're just replacing the parts of the site that needs to be dynamic with React, since you can mount a react app on any page. It seems overkill to replace even the relatively static parts as well.

systemicdannaianbutler3 years ago

They will probably start with that and progressively replace all parts. Having a mixed front end framework is a very inefficient setup and a bad dev experience. Much easier to just SSR those static-ish pages and cache them until content changes.

gedy3 years ago

Not involved with this project but FYI (some) React sites can be rendered server side as well. This doesn't have to be some slow SPA load.

colin353gedy3 years ago

We're not using server side rendering extensively at GitHub (yet) but are experimenting with it on some React pages. Hoping to make the pages even faster than the previous Rails/ERB pages

eyelidlessness3 years ago

So, this seems to be at least partly related to early introduction of Blocks[1] features. If so, and assuming that several of Blocks features are implemented with React, it makes some sense that they’d broaden adoption of React overall. You can use React for smaller isolated parts of a mostly client-static/server-rendered page, but it’s not typical on a page which is already as highly interactive as GH repos are (even if that interactivity is not immediately obvious).

I personally wouldn’t pick React for, well, anything under my personal control. But it’s a sensible choice for the features they describe at their scale, and a sensible choice for their repo experience generally. I’ve seen some comments about bugginess in navigation etc, but none that don’t sound familiar from their Rails implementation. Hopefully with some bugs ironed out this will be bug compatible or better.

1: https://blocks.githubnext.com/

mhoad3 years ago

Genuinely confused why someone would reach for React in a 2022 rewrite scenario.

It is on a bad path in terms of integrating with the web platform and doesn’t seem to have any clear signs to resolving that technical debt.

StreamBrightmhoad3 years ago

Scaling development efforts is a challenge. Reaching for the most popular thing out there is a solution.

azemetreStreamBright3 years ago

Does "most" popular thing actually matter? Or is it mostly choosing X because everyone else choose X as well?

I mean we aren't talking about a rewrite in Mithril.js here. It's not hard to find people that want to work in vue, svelte, or solid. These three also seem to beat react at every benchmark (also nearly everything is better than react performance wise it seems).

https://krausest.github.io/js-framework-benchmark/current.html

I honestly wonder how much bloat and loss of performance we're wasting on hundreds of millions of clients because companies and teams and orgs are no longer opting for better experiences thru experimentation or choosing better tools but simply chasing after wrong KPIs set by people that don't care about tech.

nvllsvmmhoad3 years ago

So what would you recommend instead?

mhoadnvllsvm3 years ago

Probably something like Lit.dev seems exceptionally well positioned to stay aligned with the platform and give the same developer experience and a much faster user experience.

dmitriidmhoad3 years ago

Literally everything that runs in the browser is "aligned with the platform" since there's nothing but the platform that is running in the browser.

Meanwhile, "the aligned with platform" lit.dev is busy reinventing React, but poorly:

- uses non-standard syntax like `<div ?hidden=xxx .value=yyy .@click=zzz`

- special functions of the form "this particular function call even though it looks like a regular function call will actually throw an exception if used outside a very specific place inside a string". See "built-in directives"

- as a part of the mess that is Web Components in general is now busy reinventing React Context

and so on and so forth.

But yeah, sure, "more aligned something something"

mhoaddmitriid3 years ago

You seem kind of confused about what people are referring to here and I don’t know if it’s out of ignorance or partisanship but I mean using options that don’t have to reimplement entire core parts of the web platform that already exist but in JavaScript and in a way that doesn’t work with anything else.

I’m making the argument that would be a bad choice to make in 2022 but totally understand why it made sense a decade ago.

dmitriidmhoad3 years ago

> You seem kind of confused about what people are referring to here and I don’t know if it’s out of ignorance or partisanship

Ah yes. Go directly for ad hominem attacks without ever telling what exactly you mean. That will definitely help you win an argument.

> I mean using options that don’t have to reimplement entire core parts of the web platform that already exist

Again: what the hell are you talking about.

randomguy0mhoad3 years ago

What would your suggestions be in place of React?

Existenceblinksrandomguy03 years ago

Solid. It will be a smooth transition DX-wise. And it's better in every angle. Except of course so called "big community", "lots of library", "easier to hire" .. poor excuse for technology advancement.

ojkellymhoad3 years ago

React is still a safe bet, there’s an enormous quantity of engineers who know how to use it.

The performance you can achieve is respectable, especially as your application grows.

> It is on a bad path in terms of integrating with the web platform

What do you mean?

xmonkeemhoad3 years ago

I chose React in 2022 for a new app. I looked at the alternatives, and the only ones that seem mature enough are Vue and Svelte. Vue honestly doesn't really seem that different to me. Svelte is great, but the ecosystem is a fraction of react's and I don't want to waste time looking for libraries. The one alternative that looked amazing was htmx. I would honestly love to use that but my app is too dynamic and making it in htmx would be a fun puzzle, but a puzzle nonetheless.

dmitriidmhoad3 years ago

> It is on a bad path in terms of integrating with the web platform

This is some unsubstantiated claim

mhoaddmitriid3 years ago

It’s lack of proper support for both the DOM and native browser events are both giant holes that immediately come to mind and have the unfortunate side effect of making React integrate with anything that wasn’t specifically designed for React a giant PITA.

dmitriidmhoad3 years ago

> It’s lack of proper support for both the DOM and native browser events

What

mhoaddmitriid3 years ago

I’m not sure what YOU are on about here. They are both well known gaps that make integrations a pain in the ass. Not sure if you’ve ONLY used React or never used React.

dmitriidmhoad3 years ago

> They are both well known gaps that make integrations a pain in the ass.

Funny how you keep not saying what you mean across two threads. While accusing others of being ignorant, partisan, or never using something, it looks like you're just describing yourself.

weinzierl3 years ago

"Repositories" and "Activities" on the Dashboard are not loading for me anymore. All I get are two endlessly turning spinners. Never had this issue before and looks like these two components can't load their data.

warpech3 years ago

GitHub is a great example of mostly server-side generated HTML. Their output HTML is very stable: the structure rarely changes, is semantic, logical, and self-documenting. This has helped hundreds of browser extensions (e.g. Refined GitHub, ZenHub) and userscripts, including dozens of my own.

Of course, treating HTML as API/data exchange format is fragile and might be seen as hindering progress by some of the GitHub staff. However, it has been like that for many years and was beneficial for the community. Perhaps not that beneficial for GitHub, who would prefer integrations over the official API.

If GitHub's HTML changes to a dynamic React-powered div-soup, that might be the end of browser extensions and userscripts. And another reason for power users to flock to other platforms.

Edit: React does not necessarily mean div-soup, but I have seen too many React-powered div-soups to expect GitHub's HTML to stay the same.

solarkraftwarpech3 years ago

> If GitHub's HTML changes to a dynamic React-powered div-soup, that might be the end of browser extensions and userscripts.

But that feels more like a failure of user script developers (myself included). Why don't we have great tooling for modifying React apps (or do we but I don't know about it?)? The amount of them is already high and only going to increase.

For modifying the Tidal UI I had to use MutationObservers, tied to how the components will render. It's bad, I'd rather modify the React app more directly, but hey, it does work reliably (albeit only because the app doesn't change much): https://gist.github.com/solarkraft/edd9d49bcf0f548b1aa285da7a8bf3ae

Can we do better?

warpechsolarkraft3 years ago

> Can we do better?

I hope yes! Some people are interested in this field. I think, we would need more mor flexible, adaptive scrapers based on content not the HTML structure. This week alone, I had interactions about "AI assisted web scraping" with two people:

- https://twitter.com/geoffreylitt/status/1589677131873021953

- https://news.ycombinator.com/item?id=33555426

colin3533 years ago

I'm one of the engineers at GitHub who was behind this new UI, let me know if you have any questions. We chose React for this code search/code view because it has a lot of interactivity, and it has worked well so far.

And we do intend to write a blog post with more details in the coming weeks.

the_lonely_roadcolin3533 years ago

Are you going to switch to API mode for Rails as part of this process?

colin353the_lonely_road3 years ago

This is just the first step of using React within GitHub.com, so we still use a lot of traditional Rails/ERB, even on the React pages (e.g. for the header/footer).

rad_gruchalskicolin3533 years ago

I was not expecting to see this comment at the top of this thread but since it is here… this UI really sucks on mobile (at least on iOS).

A couple of immediate problems:

1) I am no longer able to visually distinguish folders from files, where did the folder icon disappear?

2) Swiping back is weird, sometimes it does work, sometimes it doesn’t. When it doesn’t, it either leaves me with a blank screen, or loads back what I just swiped away.

3) This really aggravates me, swipe back doesn’t preserve scroll position on long file listings, it renders the contents and scrolls to the top. This is really bad.

4) Where’s the footer?!

5) The whole thing just feels slow.

GitHub ui is getting worse on mobile as time goes. For example, why can’t I fork a repo from the mobile page?

I don’t know how you measure how your UI is used but I don’t think me browsing the code while sitting on the throne, or looking up a piece of code while laying in bed is so unusual. Maybe some of you should try that before such half baked stuff is released with much fanfare. Because the way I read it is “we’re excited to announce that we have broken your GitHub experience”.

colin353rad_gruchalski3 years ago

Yep, aware of these mobile issues and are actively fixing them, will hopefully improve in the next week or so.

And thanks for the feedback. We're in Beta right now exactly so we can get feedback so please don't hesitate to reach out (in-app, via Discussions https://github.com/orgs/community/discussions/categories/code-search-and-navigation, or any other way you can reach us), even if it's something minor

rad_gruchalskicolin3533 years ago

If you’re in beta, how come do I see all this half finished stuff? Your beta features are usually behind a feature flag?

colin353rad_gruchalski3 years ago

I'm guessing you are in our Code Search Technology Preview (which was at cs.github.com), which gives you access to this new UI as well.

By the way, feel free to opt out if you hate the new UI - it's super easy to opt out from the code view page, or from the feature preview menu.

rad_gruchalskicolin3533 years ago

Thanks, that fixed all my problems.

Aeolunrad_gruchalski3 years ago

> GitHub ui is getting worse on mobile as time goes

Like Reddit, they’re probably trying to push you to the mobile app.

colin353Aeolun3 years ago

Not the case, the mobile app is great, but we know developers use mobile web. It matters to us. Will definitely improve it

Dayshinecolin3533 years ago

Have you fixed the problem where opening any moderately large document in chrome on android would just lock up chrome entirely? :)

The editor was clearly trying to load the whole thing!

colin353Dayshine3 years ago

We have fixed it behind a feature flag that isn't yet rolled out. Still experimenting with it. But expect to see that resolved in the next couple weeks

rad_gruchalskiAeolun3 years ago

Never. I often just look up some specific lines, copy links to those lines, send to slack or similar. Not sure how would that work with an app.

givemeethekeyscolin3533 years ago

Why not Svelte? Why not Stimulus Reflex / Hotwire?

colin353givemeethekeys3 years ago

GitHub has been investing in React for a while (e.g. see our accessible React design system https://primer.style/react/). Many developers at GitHub have experience with React, which helps. And the tooling is just more mature (IMO)

dmitriidgivemeethekeys3 years ago

Why not Solid/Marko which seem to be tailor-made for these kinds of things (mostly static, with interactivity spliced in)

eyelidlessnessdmitriid3 years ago

Marko is tailored for that. Solid has mostly focused on highly interactive SPAs until very recently. Solid’s creator also worked on Marko and has written a lot on the subject. But even so he mostly deferred to Astro for mostly static use cases with Solid until the most recent release (Solid/SolidStart) officially supported partial hydration.

kjuulhcolin3533 years ago

When viewing code I like the feature, however, when browsing folder structures it is a completely redundant feature. And just adds visual clutter. This feels like a half-step between an editor and a static file listing. I would personally prefer either a very static view of the core, in pure html, or an interactive experience (Ctrl+.) for opening vs-code on the repo.

Secondly, the code search feature is nice, but is there a reason why it has to be a column to the right, couldn't it be part of the editor, like we're used to in most editors nowadays.

A gripe I've had recently with github, is just that it all seems so slow. It feels like trudging through mud, it may be, because I don't live in the US. But this is getting out of hand, and makes me want to consider leaving it for something else.

Sorry for the rant, I like progress, I just don't like unneeded complexity, especially for a tool I love =D

colin353kjuulh3 years ago

Appreciate the feedback.

> static view of the core

Not sure what you mean by that, can you elaborate?

FWIW we are working to more tightly integrate code search into the code view.

And absolutely, performance matters a lot to us. Sorry for the slow experience, you're not the only one, particularly outside the US. Only thing I can say is we're working on it.

kjuulhcolin3533 years ago

Sorry miss-spelled. Meant static view of the _code_. Ie. Just a file listing with the option to view the code, like you've always had.

Anyways best of luck to you. It hasn't been an easy year for github with the downtime earlier in the year, and what I would expect to be a nasty migration from a monolith =D

eyelidlessnesscolin3533 years ago

How much, if at all, has anticipated and/or apparent stabilization of React Server Components factored into this [expanded] technology choice? Can you speak to considerations of other component frameworks?

eyelidlessnesseyelidlessness3 years ago

I… guess I offended someone by asking what I thought were totally innocuous, curious questions that they invited. Of all the fucking things to downvote! I mean, by all means tear this’n to shreds. But if anyone has a problem with my questions above could you please be bothered to say why?

jverrecchiaeyelidlessness3 years ago

Just because you didn't get an answer doesn't mean someone got offended. Chill.

Waterluviancolin3533 years ago

Can you teach me how you absorb and respond to all this criticism/feedback with such grace? Worst part of my job. Well done.

colin353Waterluvian3 years ago

Positive feedback feels nice, but negative is way more useful to making a great product.

We're changing an website that millions of people use every day. Hopefully we mostly have a positive impact. But if we're making it worse, even in a small way, that matters a lot to be aware of.

Waterluviancolin3533 years ago

Very true. I love “negative” feedback. But I don’t know how to not take it personally sometimes. It often feels like a failure. Especially when it’s a “darn I should have caught that!”

ilikecodeWaterluvian3 years ago

Everyone fails sometimes. Take every failure as a learning experience. Taking it personally and feeling emotions doesn’t actually help the problem - that you made a mistake and need to just learn and move on. Focus on the future, on the problem, on now, not the past. If however you make a mistake and get defensive and don’t learn anything then yeah it’s only a toxic thing on you. Learning from it helps you grow.

Masters of subjects don’t learn overnight. They learn over years, decades, a lifetime. In that time they make countless mistakes. But they persevere and don’t let it affect them emotionally and they grow into those masters.

I make mistakes daily. I’ve thrown away hundreds of thousands of lines of code in my career because it didn’t work as expected. But each time I grew a little and learned something to make the next iteration better.

100k3 years ago

(I worked on the backend for this, not the frontend.)

Yes, the new code search and navigation experience is powered by React for the frontend. We decided to use that because we wanted to build a stateful, rich navigation experience.

If you want to try it, please sign up for our beta https://github.com/features/code-search (we have been clearing the waitlist daily.)

rad_gruchalski100k3 years ago

And yet, the two things I cared for as a user, are gone: scroll position no longer preserved on mobile devices, swiping back doesn’t work reliably.

lossolo3 years ago

Rendered HTML on backend was faster for me and now seeing that last commit header to load and not just show instantly feels weird and slowish, whole site feels heavier for me now.

hrbf3 years ago

Is this intended as satire or actually a serious statement? I increasingly cannot seem to make a confident distinction nowadays.

fellellor3 years ago

I always wanted my phone and tablet devices to serve as mini heaters/hand warmers. Thanks!

Existenceblinks3 years ago

GraphQL has been downgrading their API product for a long while, now React will also downgrade their front pages product. I saw a html/custom-elements advocate engineer left a year ago, .. my speculation just kicks in.

eurasiantigerExistenceblinks3 years ago

GraphQL is a language.

0xblinq3 years ago

I really hope this does not end up like Reddit. Or that at least they keep an old.github.com that’s usable.

johhhnnalin97733 years ago

Use angular

johhhnnalin97733 years ago

Use Angular, much better!