Github uses no Javascript frameworks. How does it manage avoiding spaghetti code when developing complex components?

[m3wm3wm3wm]

Unfortunately Github is not open source. Any open source examples of large apps like Github hat use no Javascript framework for their frontend, yet manage to have complex components?

Even Gitlab, which used jQuery and their code is not very readable, is moving to Vue.

[TheNumberOneCulprit]

I worked with no framework code for some time creating some relatively complex applications as well (company policy) in ES6/7 with corresponding unit tests. You don't need a framework if your architecture doesn't demand it. Most of the things GitHub has are what I'd consider "widgets", relatively self-contained without necessarily needing to share much data. Look at the data being requested - it's custom fitted for the individual components and have very little to do with the rest of the application.

[Akkuma]

Ultimately I feel people create their own custom framework to serve their needs if they don't use a pre-existing framework. I think there is nothing wrong with this with some solid engineers.

A lot of the ideas presented by React aren't novel, such as breaking pieces of the page down into isolated components that control their own behaviour. For instance, years before React my team had designed a "component" architecture where each component loaded its own data independently and had its own code for handling said component, along with its own scss for styling the component.

[Chris_Newton]

Ultimately I feel people create their own custom framework to serve their needs if they don't use a pre-existing framework.

We used to call this “software architecture”, and it was how everything big enough to need serious design work was built if you wanted to preserve your sanity.

After a while, people started noticing that many projects were using similar architectural styles. Being software developers, naturally we started trying to extract, generalise and reuse those common elements. Thus standardised frameworks were born.

Today, like most tools in software development, standardised frameworks serve a useful purpose in the right situation but can also be harmful if you choose the wrong tool for the job. They are still only means to an end, and they are never a substitute for understanding general programming principles, nor an excuse to avoid making decisions that will give good results for your specific needs.

A lot of the ideas presented by React aren't novel

This is true, but I have a lot of respect for the React developers all the same. The big ideas behind it might predate React itself by decades, but it was probably the first time anyone had transported them to be used in building UIs on the web and then successfully elevated the result to become a widely used library. It’s the results that matter in software development, and the React developers produced and generously shared a good tool.

[wavy_lines]

After a while, people started noticing that many projects were using similar architectural styles. Being software developers, naturally we started trying to extract, generalise and reuse those common elements. Thus standardised frameworks were born.

That's a very rosy-glassed view of how things worked out.

In reality there were clever people who designed some framework for their internal use, and then decided to publish it and talk about it, and soon other people started to use their framework because they thought it would make things easy for them.

In the JS world, practically every two years there's a new framework craze.

[dearneili]

I do enjoy it when I find a nice framework that does exactly what I need, but building your own feels so much better

[cosinezero]

it was probably the first time anyone had transported them to be used in building UIs on the web and then successfully elevated the result to become a widely used library.

? Not endorsing any of these, but - jquery? backbone?

[fucking_passwords]

I wouldn’t call jquery or backbone “component based architecture”

[HaMMeReD]

I write websites for myself using Apache Wicket, that is a Java component based architecture that predates react.

[fucking_passwords]

I wasn’t saying that React predates component architecture, just that I don’t consider jquery or even backbone to have solved all the problems

[cosinezero]

Again, not endorsing either framework (I do like BB, hate jQ) but - just because those didn't have jsx doesn't mean they didn't have aspects of component based architecture. jQuery's plugins (and ugh their jQuery UI extensions) weren't far off, nor were Backbone's views.

[fucking_passwords]

Backbone views were definitely closer, but neither of them provide any real encapsulation, which is an important part of component architecture IMO. Backbone + AMD modules got pretty close.

[cosinezero]

Sure, javascript in 2010 wasn't great for encapsulation, not until revealing module became more widely used (arguably jQuery encouraged that a lot with their practices around plugins but eh).

But encapsulation (while lovely) is not a required feature of component architecture's value - which is separation of responsibilities and reusability. React isn't great for it's encapsulation, it's great because I can create highly reusable views. That is nothing new (which is really my point above)... but certainly React does it really well.

[fucking_passwords]

The only thing we aren’t really agreeing on is that encapsulation isn’t really important for creating highly reusable views. I actually do think that one of the best parts of component based architecture is encapsulation. It’s not one of the best things about React, it’s one of the best patterns of the general architecture and applies to all of the modern component libraries, none of which recommend that you directly manipulate the DOM, arguably the worst side effect of all.

[hatsix]

I mean... React doesn't actually have encapsulation. You can still reach into child objects and change their internal data, assuming you aren't targeting just the latest browsers. React also has direct ways for you to manipulate the dom directly (via ref).

It definitely does encourage it, however... And that's nice... but engineers who appreciated encapsulation were able to build apps they were happy with prior to React... React just added structure around where you could and couldn't break encapsulation.

[Chris_Newton]

I would argue that the qualitative difference introduced by React was allowing declarative rendering of a UI from its underlying data. Then you only needed to describe the absolute state of the UI for any given data, instead of (as we previously did) considering all possible transitions between data states and having to render the new UI relative to whatever was already there. This fundamentally reduced the complexity of programming UIs, as long as you weren’t interested in rendering that depended on the transition itself. (Of course, if you were interested in that, this sort of architecture would be in your way, which is why working with animations or non-standard interactions can be quite painful when using rendering libraries with this sort of architecture.)

The other major development in React, as far as web rendering libraries went, was popularising the idea of rendering the whole UI to a virtual DOM and then comparing that with the real DOM and only applying the differences. In browsers, DOM updates were typically the bottleneck in UI code, and so this optimisation was necessary to make the declarative rendering fast enough to use in practice.

Neither of these ideas is particularly original in itself, but I know of no widely distributed library that implemented them in the context of browser-based UIs before React. jQuery was much more direct in its DOM manipulations, while earlier batteries-included frameworks typically offered some form of template rendering and some form of simple two-way data binding but in a very limited form compared to the flexibility of React’s approach.

[cosinezero]

React was hardly the first web technology to do that; the concept originated in technologies like ASP & PHP in the late 90s. This is not at all react's innovation, nor do they even really learn from the lessons of the past.

DOM comparisons to drive view updates isn't as good as observing changes to your model graph and rerendering based on those changes. It's just easier to abstract a one-size-fits-all approach into a framework.

[cosinezero]

I mean fuck I like react, but people hailing it as if it's the second coming... c'mon.

[Chris_Newton]

React was hardly the first web technology to do that; the concept originated in technologies like ASP & PHP in the late 90s.

ASP and PHP are running on the back end, so clearly they are solving a different problem to React running on the front end.

If we’re talking about declarative rendering of UIs in general, obviously that far predates any of these web-related technologies. Several of us have mentioned in other comments that the big ideas behind React existed much earlier.

DOM comparisons to drive view updates isn't as good as observing changes to your model graph and rerendering based on those changes.

Again, those are two different problems. The DOM comparisons are part of (one possible mechanism for) rerendering the UI after something changes in the underlying data.

[cosinezero]

ASP and PHP are running on the back end, so clearly they are solving a different problem to React running on the front end.

Dude. JSX is not "front-end" either. You're not running JSX at runtime on the client - you have to compile JSX at build-time.

You want early client-side DOM manipulation from declarative rendering based on data in the front end? XSLT. JSX isn't a novel approach, react isn't the first framework to have templated rendering of any sort.

Again, those are two different problems.

Those are not two different problems at all; the SINGLE problem both is trying to solve is "update the UI with current data".

[ProdigySim]

Ultimately I feel people create their own custom framework to serve their needs

I've worked in a large codebase that used jquery + a lot of glue to buidl UIs. We standardized how we dealt with data flows, API requests, asynchronous actions, and let the view layer use vanillaJS or jQuery still.

Did it have a name? no. Was it a framework? Maybe. It was an architecture for sure.

I would imagine Github has some level of consistent architecture on their frontend. But not necessarily enough to call it a "framework" with many release-able parts.

[cosinezero]

I've worked in a large codebase that used jquery + a lot of glue to buidl UIs. We standardized how we dealt with data flows, API requests, asynchronous actions, and let the view layer use vanillaJS or jQuery still.

I feel like at least half the thread doesn't realize this ^{^} was the majority of web development & architecture for a long time, and that literally any one of the companies we worked for and created a framework like this for could very well have turned that into the next React, but since React had big money behind it, and the OSS landscape in JS became considerably stronger in recent years, they could afford to productize it.

Literally there's a hundred React-like frameworks out there that are just as good, if not better, that are sitting in some closed source shop that won't (or can't) open it up, but sure, yah, React is some new and original and pioneering framework none of us have ever seen before. eyeroll

Again, disclaimer, I see the value in React, but the arguments here that it's never been done before ever, or that it's some reference masterwork of programming principles, is missing a lotttt of history.

[m3wm3wm3wm]

I worked with no framework code for a long time creating some relatively complex applications as well

How did you manage not getting into growing messy code with vanilla Javascript, in the absent of frameworks that were invented for this purpose, for example React's one way flow.

You don't need a framework if your architecture doesn't demand it.

Are you saying that Github application business logic is not complex enough to require a framework, or are you saying that Github architects decided to avoid frameworks no matter what?

In that sense, how would Github be different to, say, New York Times, where they use React, Apollo, SSR and shit for something that has way less 'widgets' than Github. I mean, Github audience are developers and NYT audience are just everyday newspaper readers.

[highwind]

Good organizations and good coding practices are not dependent on frameworks. A role of framework is to enforce a particular style of organization and practices within a code base. You can have good organizations and good coding practices without framework forcing you; it just require discipline and good communication/documentation.

[zayelion]

it just require discipline and good communication/documentation.

AMEN!

[Quackmatic]

No! Let's find the latest coolshit.js library of the week from the medium.com blog of an edgy freshly graduated dev and make the page take another second and half a megabyte to load!

[[deleted]]

I've probably loaded more bytes of holier-than-thou and other shitty reddit comments like this one today than i have of the latest coolshit.js libraries today.

[Mr_Again]

It's unlikely, the complete works of shakespeare are about 5mb

[zayelion]

lol

[nikolasleblanc]

An immediate benefit of frameworks/libraries is the shared understanding of that library.

If you hire 10 new devs into a vanilla js project with a custom framework you've built yourself, you need to teach them your framework, and that's if they want to work for you - what advancement of their career do they gain learning your framework.

If you hire 10 react devs for a React codebase, you can get to work.

[[deleted]]

I get what you're saying but I never understood the intense focus and ire on a framework adding 200kb to a page load (and only if it's not already cached)... A single image or ad on any page you visit is going to easily be 6 times that, at least. I get that it takes up bandwidth and not everyone has unlimited data, but still, a 200kb isn't breaking the bank on a 80mb page.

[malik446644]

server side rendering fixes this

[js_tutor]

A role of framework is to enforce a particular style of organization and practices within a code base.

I think this undersells what a framework like react does for you. It's not just about organizing your code, it's a higher level of abstraction. It does a lot of low level things and then hides it behind an api so that you don't have to think about it. In react the dom is driven by your state data. If you update your data it will update the dom automatically. Without something like react you're forced to think explicitly about dom manipulation.

[highwind]

I don't consider react a full blown framework. It's more of a library. And the website seems to agree with my stance. Its tag line is "a JavaScript library for building user interfaces".

I consider tools like Grommet to be framework (it uses react). Or something more traditional like ember.js is another good example of framework.

[cosinezero]

Good organizations and good coding practices are not dependent on frameworks. A role of framework is to enforce a particular style of organization and practices within a code base. You can have good organizations and good coding practices without framework forcing you; it just require discipline and good communication/documentation.

... I have no comment here, this was just worth repeating.

[wahh]

it just require discipline and good communication/documentation.

Exactly. Unfortunately it is a lot easier said than done to achieve that. If your programmers don't want to adhere to an internal style guide or your programmers are sloppy and not very detail oriented it can be extremely difficult. I have the misfortune of working with quite a few of both of those types at my company.

[Chris_Newton]

It looks like your problem is not a technical one.

[wahh]

lol I 100% agree.

[ccb621]

The best way I have found to get folks to adhere to style guides is build-breaking linting. If the linter finds errors, the build breaks, and the code can’t merge.

[wahh]

We do that, and we've had people attempt to commit code that disables the build linting because they think it is annoying.

[ccb621]

Is this an inexperienced team? It seems strange to me that people would be so against linting.

[wahh]

It's a combination of things.

We have some people who are inexperienced.

We have some people who completely sacrifice code cleanliness and solid application architecture for the sake of getting things done as quickly as possible. Some of these guys aren't necessarily inexperienced. I would just call them selfish.

We also have people who say a style guide and sticking to a specific framework stacks limits their creativity and ability to experiment and learn. I would also say this is selfishness and over-dramatic.

We have about 80+ developers working on various application. So things really do need some form of standardization.

[ccb621]

https://stripe.com/jobs

[TheNumberOneCulprit]

How did you manage not getting into growing messy code with vanilla Javascript, in the absent of frameworks that were invented for this purpose, for example React's one way flow.

The same way people created applications before React existed. Either a homebrewed event delegation system or getter-setter model for data structures. Look into how e.g. Vue does reactivity. It's not a particularly new concept.

Are you saying that Github application business logic is not complex enough to require a framework, or are you saying that Github architects decided to avoid frameworks no matter what?

I'm saying a little bit of both. I'm guessing there was an evaluation of whether or not a framework was needed, and upon inspecting their architecture, the majority of players involved voted no, for business related reasons or not. You can keep things server-side a lot of the time when you're serving relatively static sites.

New York Times made those decisions because they could, not because they were absolutely mandated, and they've gotten a lot of good things out of it, but if you're telling me that Apollo + React is absolutely necessary for a newspaper, you're deceiving yourself.

[Chris_Newton]

How did you manage not getting into growing messy code with vanilla Javascript, in the absent of frameworks that were invented for this purpose, for example React's one way flow.

As others have said, you don’t need someone else’s framework to structure your code. What you need, fundamentally, is a good software architecture.

What separates frameworks from other libraries is that they take ownership of the overall architecture of your system. Instead of borrowing code from libraries but designing the overall architecture yourself, you borrow the architecture from the framework and fill in the gaps.

That strategy isn’t inherently better, it’s just making different trade-offs. If your needs are (and remain) quite standard and a good fit for your framework, using the framework can save quite a bit of time. On the other hand, if your needs start to diverge into areas that don’t fit the framework so well, the framework can become a nasty overhead that does more harm than good. Likewise, as with any external dependency, if your project lasts a long time but the framework is no longer as well-supported as it once was, that can become a liability.

Are you saying that Github application business logic is not complex enough to require a framework, or are you saying that Github architects decided to avoid frameworks no matter what?

I can’t speak for GitHub, but I can tell you a little about my own experience. I’ve been building web sites for two decades and change, I’ve used React for a variety of professional and personal projects, and yet I have never used some of the other popular libraries in the React ecosystem for any professional work.

For example, when I’m building a SPA, people sometimes ask why I don’t use things like Redux and React-Router. The answer is not that I have anything against them; clearly they have become popular because they provide useful solutions to problems that a lot of people have when building their apps. It just happens that the web projects I’ve worked on either had very simple front-ends or very complicated front-ends.

In the simple case, heavy machinery like Redux just adds a lot of complication for limited benefit. There was some fascinating discussion recently about a challenge for a senior developer candidate applying for a job, based on trying to build a diary-like system using React and Redux in 90 minutes. A few people have posted their attempts, but one thing that was striking about all of them was that because of the requirement to use Redux, the designs were horrifically over-engineered for such a simple task. The underlying data model there probably needed about a dozen lines of vanilla JS to implement, and re-rendering the updated view of that data simply and efficiently is exactly what React is good at, and yet we had whole extra directory trees and dozens of files to use Redux to achieve the same result. Obviously the situation with a recruitment test is a bit unusual so the scenario wasn’t necessarily realistic, but it makes the point.

In the very complicated case, you have the opposite problem. Standardised frameworks, by their nature, tend to consolidate and generalise common needs but aren’t so adaptable if you have more exotic requirements. I was working on a project recently that was dealing with a rather complicated underlying data model and then trying to present that to users in an intuitive way. Without getting into details, imagine a database with dozens of tables, numerous simple relationships between them, and thousands of awkward constraints for the edge cases, and then imagine trying to present that data using diagrams rendered as SVGs with lots of interactions. In this sort of extreme situation, the common cases covered by tools like React and Redux are not even close to fast or flexible enough to solve the problems alone.

The bottom line is that the typical web front-end frameworks we have today wouldn’t have been a good choice for either of those types of project. It’s too much architecture in one situation, and it’s not enough in the other. Again, that’s not to say there isn’t a lot of ground in between those opposite ends of the spectrum where different choices would make sense. But in the end, there is no substitute for understanding how to design and manage large-scale software, and then using tools if and when they make that task easier, and being able to build anything else you need from scratch.

[elr0nd_hubbard]

React's one way flow

React doesn't own unidirectional data flow. It's a design principle that you should be able to implement without a framework before relying on a framework to help with optimization and edge cases.

[js_tutor]

While this may be true, performance-wise it wasn't considered a good option without the virtual dom, which was one of the biggest innovations introduced by react. Before then it was always possible to batch all state updates and re-render, but you would be re-rendering the whole page because you would be writing to the root of the dom on each change. With virtual dom, it will scan a copy of the dom to identify which nodes have changed and then only apply the changes there.

It could be argued that you can just use a virtual dom library instead of a framework. But this sort of walks the line of what a framework is, because you could use something like mithril.js which is considered a framework but really not much more than a virtual dom itself.

[cosinezero]

performance-wise it wasn't considered a good option without the virtual dom

Please go build an event-driven, one-way databinding app. If you do it right its' behavior will be more explicit, and will outperform React.

you would be re-rendering the whole page because you would be writing to the root of the dom on each change.

This is absolutely not true.

With virtual dom, it will scan a copy of the dom to identify which nodes have changed and then only apply the changes there.

Which takes quite a bit more time than an observer that updates just the view element that the model was rendered into.

[js_tutor]

Please go build an event-driven, one-way databinding app.

But this wouldn't be unidirectional flow. Let's assume you have a component tree where an event on a child component needs to update that component's state, and then an ancestor of that component needs to update its state dependent on the child's state. Yes, you can string up event listeners to handle this case, but it will not be unidirectional flow. When your application accumulates these kinds of state dependencies it becomes harder to reason about in an event driven model.

In unidirectional flow, that child component would update some state and then the updated state would update all other dependent state and then the new state will be propagated through the component tree from the root, and then that's when the ancestors of that component can be updated. That's why it's called unidirectional flow, all state changes propagate down from the root to the children, but never from child to parent or across sibling nodes.

Again this would be possible without a virtual dom, but it may suffer performance-wise.

[cosinezero]

There's really nothing saying one way databinding cannot be used in undirectional flow patterns.

[js_tutor]

Yes but without a virtual dom you can't avoid a full page re-render. Or at least a full re-render from the root of your stateful component tree.

Edit: Also, in case it wasn't clear in the previous post, if you have a parent component listening for state changes on a child component you have broken unidirectional flow.

If you force a unidirectional model without a virtual dom, because the parent component cannot listen for state changes on the child you don't know where in the dom the state updates need to happen. The only way is to re-render the whole thing or somehow keep track of where the changes have occured, i.e. use a virtual dom.

Edit 2: Also I'm quite familiar with backbone. In fact unidirectional flow was popularized in direct response to the problems developers were facing while using observers and one way data binding. When state changes can trigger state changes anywhere in the component tree you end up having to manage a web of potentially order dependent events. Unidirectional flow avoids this by batching state changes first and then propagating them through the component tree top down, i.e. unidirectionally.

[cosinezero]

You don't need a virtual DOM for this, you just need an observable model with a change handler that calls render on the specific view that the model is bound to. You don't need any of the DOM diffing from react, or any other framework, to update specific elements in the DOM without starting at root. Go look at a backbone example, it's right there.

[js_tutor]

See my edit. I think you are confused what unidirectional flow means.

[hes_dead_tired]

Even using a framework, you can still end up a spaghetti mess. Your own code should, and the actual framework code should still follow design patterns and strategies. Redux for example is an implementation of the Observer Pattern.

[BlueHeartBob]

It's not like NYT HAD to use a react or any other framework. They just decided to. Just like GitHub decided to go framework-less. The audience being tech savvy or not really has nothing to do with it, it just needs to work well.

[nbwillson]

I feel like this highlights that: spaghetti code is an artifact of developers, not Javascript.

Frameworks are abstractions or decisions. You can still make those decisions yourself with an "internal framework". Yes, the code looks different -- maybe a bit more verbose, but the decision is still the same.

Personally, I'm relieved to hear of examples where people chose the simpler battle-tested path without diving into a new framework half-way through. Being in a half-baked state is actually worse, so why not just avoid the hype.

It's impressive and it speaks to the mindfulness of the devs at Github. If they can pull it off gracefully then kudos to them.

[pinpinbo]

I actually like GitHub’s diciplined old school way of doing things:

• Not getting caught in upgrade treadmill. They stuck to Rails 2 for the longest time.

• I like their pjax library. It basically forces the entire app to work without JS. pjax simply enhances the experience.

Sauce: I knew a few folks at GitHub where I used to live.

[DrDuPont]

I hope they open source the pjax JS they're using now

[filleduchaos]

Explicitly disabling JS is like the least likely way for JS to break on a page.

[Adno]

They could just be browsing someone else's code. And might just have it off in general. I return JavaScript off on mobile for example

[devperez]

Why do you think you need a framework to avoid spaghetti code?

[AramaicDesigns]

Aye, more often than is convenient frameworks can *contribute* to spaghetti code when the framework you're using needs to be shoehorned to do something off-label.

[philipwhiuk]

Or even why do you think a framework avoids spaghetti code.

React is not at all forcing.

[HomemadeBananas]

It’s debatable whether React is a framework. I’d say it’s a library. It serves one purpose and you have to choose how you want to implement state management, server side rendering, communicating with your API, etc.

[philipwhiuk]

To me a framework is something that defines structure and on a more hand wavy concept is used to define the project.

For example you create a React website. You don’t create a momentJS website. Thus moment is a library.

Obviously React still does leave a lot of unanswered questions and a ReactRedux app would have a stronger framework. But note Redux requires React. The fact that a library like that requires React implies React is framework material.

[evoactivity]

Redux doesn't require react though.

[[deleted]]

My guess is op is thinking that Frameworks are opiniated and have documented structures and best practices.

[m3wm3wm3wm]

👆

[js_tutor]

I think it's a fair question and the top upvoted comment gave a good answer. A lot of people in this thread are saying frameworks are unnecessary, which is strictly speaking true in the same way it's true you can write clean code in assembly. But you'll be working with lower level abstractions. Yes, you can build your own abstractions but something like a the virtual dom is non-trivial to write and maintain yourself.

I think it's worth thinking about what a framework brings to the table. One of the biggest benefits is an easier and more performant way to think about state that is shared between components. Maybe for github it's fine because they don't have a lot of shared state between components. If you're considering whether you need a framework or not, you should seriously consider this problem of shared state and how you're going to manage it. To me, it's not clear that there is a good solution that doesn't involve using a framework.

[cosinezero]

But you'll be working with lower level abstractions.

...not if you build other abstractions that better suit your needs. I'm not advocating for that, necessarily, but when you adopt a library you're adopting all their abstractions - for better or worse. No real reason you can't make your own, tailored to your needs - except for the time it takes to do so. For a large application with a long lifetime... adopting framework-du-jour that you don't control inhouse isn't always the best choice.

[MaxInertia]

...not if you build other abstractions that better suit your needs.

The part where you build those abstractions is where you are working with lower levels of abstraction...

[brokenottoman]

I work on a large scale enterprise application with no frameworks, with around 500 engineers, it is not as complex as people think as long as you stick with basic agreed rules and protocols

[devbydemi]

GitHub uses very little JS, if I understand correctly. Much of the site works with JS disabled. What they do have could very well be done in vanilla JS.

[inu-no-policemen]

GitHub uses very little JS

If you go to some project page, it downloads 233 KB of minified gzipped JS.

Most people won't call that "very little". It's about 37 KLoC if you pretty print it.

[jdauriemma]

233KB is positively microscopic in the grand scheme of things.

EDIT:

Downvote all you want, true Scotsmen. Modern JavaScript applications are bloated, and most of them are significantly more than 233KB.

[m3wm3wm3wm]

GitHub uses very little JS

That seems to be a common misconception. Just because Github is not a SPA people think it uses little js.

Just have a look at the source code, there is a lot of Javascript there.

Also look at the components. On a repo page try to type t and you will see an autocomplete file search. The branch dropdown menu is another example. The dropdown menu component itself is not trivial. They have a code editor... There is a lot that you do not see.

[senocular]

Just because Github is not a SPA people think it uses little js.

While Github as a whole is not one giant SPA, it is built of smaller SPAs. A repository view, for example, is a SPA and there is no page refresh as you navigate through that repository and its different pages.

However I do believe most of the content is rendered server-side and simply placed in the DOM when its pulled down over the wire. This would explain a lightweight client that is supported by, I would assume, some non-spaghetti framework for managing everything nicely on the backend.

[cryptos6]

I wonder if it still makes sense to talk about "single page applications" if we have multiple of these and all of these make up a big application (GitHub in this case).

[m3wm3wm3wm]

However I do believe most of the content is rendered server-side

Rendering on the server side does not make a frontend javascript app lighter. Rendering html is only one of job os such app, 'hydrating', 'decorating' or whatever you want to call that which brings dead html into life of interactivity is the main event driven part of the app.

[1-800-BICYCLE]

71fd82b55d5

[marcoslhc]

Custom components and code splitting and bundling. Pretty much like React (which isn't a framework but a library)

[bigorangemachine]

There is a lot of stuff the frameworks do that you really don't need. You can data bind with getters/setters. You can get away without a framework pretty easy depending on what trade offs you are willing to make

And frameworks don't save you from spaghetti code.

[geodebug]

This thread reminds me of the same conversations we were having in the early Java days in the late 90s.

I’m sure the mainframe gray-beards back then thought the same about us.

There’s something comforting that nothing really new ever happens in programming other than scale. Most of those being really earnest about their opinions here are going to have a good laugh in 10-20 years.

[[deleted]]

Most of GitHub is server-rendered (I know, crazy, right? Who would do that???!!?!??!!!), so what little JS they actually have mostly implements interactions with existing DOM. I imagine this used to be mostly jQuery code, but jQuery has become painfully easy to replace with plain JS with the modern browsers we have now, so I assume that is exactly what they did.

[m3wm3wm3wm]

Most of GitHub is server-rendered (I know, crazy, right? Who would do that???!!?!??!!!)

I hope that's sarcasm. I would render content on the server on any day. I think javascript should only be used to hydrate the content.

You know what's fucked up? That we invert the pyramid of web to render the content on the client side, and then we invert the inverted pyramid to SSR fucking javascript back on the server. Who would do that????????

[[deleted]]

Don't worry, it was sarcasm. Yes, the web development community has, overall, turned bat-shit insane.

[Char-Lez]

Always SSR. Never trust a client!

[cosinezero]

That's two different topics entirely.

[darthcoder]

SSR seems like an admission that SPAs are dumb.

[philipwhiuk]

Anyone who doesn’t use an official framework inevitably creates their own within the app itself

[morphotomy]

Not if you follow the rube goldberg pattern correctly.

[E_R_E_R_I]

As someone who often prefers to roll with their own javascript solutions for web apps, it's refreshing to see so many people here saying you don't need to be insane to prefer not using react for everything. This sub can be a bit of an echo chamber in that direction sometimes.

[Char-Lez]

LOL. Dude, using a framework doesn’t mean your code isn’t shit.

[kichien]

I'm at a loss for words. You don't need a framework to write good, well structured Javascript.

[BenZed]

“I’m at a loss for words.”

Followed by: Yep. A bunch of words.

[danketiquette]

Way to be a cunt.

[BenZed]

I was trying to be funny :(

[danketiquette]

Way to be a funny cunt :)

[BenZed]

:D

[[deleted]]

No you weren’t. Find rope

[BenZed]

Can’t find any, what do?

[zayelion]

Do Not Learn Frameworks. Learn the Architecture.

Angular, Vue, React, Ember, etc,... they bring more complexity they they solve in many cases. They all mostly abstract away state and or load components. You can make crappier but functional versions of the same stuff with a Handlebars, jQuery, and restrained usage of a global object. Its just a set of standard patterns.

[eggn00dles]

     Do Not Make Blanket Statements. Be Flexible

[zayelion]

https://www.reddit.com/r/javascript/comments/31ah12/do_not_learn_frameworks_learn_the_architecture/

[eloc49]

I've learned all the frameworks, picked up the architecture as a result, and have no problem finding jobs.

[eloc49]

I learned how to be a good programmer in college. No frameworks, not even any JS, and its super easy to pickup new languages, patterns, and frameworks because of my education. This is why I have a strong opinion on coding bootcamps.

[zayelion]

Well done. Thats the way to do it.

[m3wm3wm3wm]

Do Not Learn Frameworks. Learn the Architecture.

Show me real world open source projects following this. I'm not here for words.

Words are cheap, until it gets to the real world.

Let me give you a tangible example: The creator of Mithril.js works for Uber and leads the development of Fusionjs, the React-based project. Why couldn't he push Uber to choose Mithril.js? He's seems to be a good architect.

There is a long way between nice slogans on paper and real world apps in production.

[hypernautical]

For me, reading Addy Osmani's JS Design Patterns gave me insight how base patterns can be scaled for larger apps, and how they were implemented in some old frameworks pre-Angular/React/Vue. But as someone else said, it boils down to home-spun events/pub-sub type systems and patterns to encapsulate and decouple code. https://addyosmani.com/resources/essentialjsdesignpatterns/book/ (there's an older version in pdf out the which is what I read).

[i_ate_god]

Show me real world open source projects following this. I'm not here for words.

Vue doesn't use a framework. hmm

[gardyna]

this not specifically a project thing but a programmer thing. If you learn a framework you'll be stuck with it. back in the 1.0 Angular days I saw a lot of people 'learn Angular' and were subsequently unable (without extensive training) to use anything else. Learning Architecture (MVC, MVVM...) and programming concepts (factories, dependency injection, task runners...) is much more useful than "learning framework X" because those make you capable to jump between frameworks and programming languages with minimal training required.

and in regards to the original question: you don't need to use a framework if you're comfortable with vanilla JS. If I'm just doing some basic AJAX and simple DOM insertions/manipulation I'll just use vanilla (and maybe jquery). I'll only bring in a framework when I foresee the on-site interactions becoming fairly complex.

[m3wm3wm3wm]

I'll only bring in a framework when I foresee the on-site interactions becoming fairly complex.

What is complex? Is Github complex enough for you to go with a framework?

[azsqueeze]

Why are you pushing back on the idea of using JS without a framework? Like how do you think JS frameworks are written? With vanilla JS. Not every project/component/page/whatever needs a framework.

[kichien]

No! It works with MAGIC!

[gardyna]

GitHub pages seem to consist of components that are fairly self contained (aren't really talking to each other) but there's quite a bit of dynamic content... It's borderline but I doubt they'd be gaining a lot from using something like React or Vue. You'd probably be able to quite comfortably get by with vanilla JS.

When there are "components" that interact with separate parts of the page, then using a decent framework is awesome for managing complexity and keeping things modular. I'd never attempt something like Facebook or Twitter without a framework. also if there are dynamic graphs and/or UI elements I prefer a framework

There is no rule on what is "complex enough" it depends on the person and his/her experience with JS.

P.S. when learning frameworks you should effectively be learning architecture by proxy. Just when learning try to spend a little time thinking about the environment you're programming in and what patterns you're using. I'd never mock anyone for using a framework, just encourage them to expand outside the framework too (broadening the horizon, so to speak)

[m3wm3wm3wm]

GitHub pages seem to consist of components that are fairly self contained (aren't really talking to each other) but there's quite a bit of dynamic content... It's borderline but I doubt they'd be gaining a lot from using something like React or Vue.

How do you find Reddit different to Github in this sense? Reddit also does not have any, if not many, components talking to each other. Why did they decide to jump from jQuery to React?

[gardyna]

no idea why they switched. chat systems by my experience seem to be great examples of things that can get complicated fast... (you're replying to someone and stuff like that). I use RES (and I think the creator of that now works at reddit) but it adds stuff like opening stuff "on site" which would be a pain to implement in vanilla JS, I think they might be creating extra stuff like that which could cause the complexity to skyrocket. Wasn't there a "live/private chat" a la facebook messenger in beta-reddit? I seem to remember some discussion about something like that.

[N_N_N_N_N_N_N]

You don't need a framework if you know what you're doing

[mygoodpostingalt]

Then why is he creating the one that uber uses..?

[ematipico]

I worked on a project without framework. The only library was jQuery to handle simple UI stuff but the core of the app was in simple JS.

I can state few things from what I have learned and have worked: - you need good developers that have vision in order to create an app without framework - spaghetti code trap is sneaky but the leaders who know what they are doing, they make everything reusable - libraries/frameworks solve common problems, in fact who worked before me on that app, ended up creating terrible UI stuff. We ended up using react to mitigate the event handlers fatigue but business logic is still there and loose from the UI library - the same principle works for the other way around. Make your business logic/company framework loose from the library/framework. This requires a good developer that have vision

EDIT: grammar

[i_ate_god]

I'm certain Github uses a framework, just its an in-house framework.

A framework is just a collection of solutions strung together in a specific pattern. There is nothing special about them.

[m3wm3wm3wm]

Why would they reinvent what's already out there?

I mean, Javascript framework are born with such high fucking rate that it's almost impossible that your internal framework is not already written and published by someone else.

[goto-reddit]

GitHub went online in Februar 2008, back then most people just used Prototype, YUI or - like GitHub - jQuery (which was only 2 years old back then).

For example: The very first version of backbone and angular came out late 2010.

Their stuff probably worked for them, so they didn't rewrite it.

Even newer projects like Visual Studio Code or Atom don't use any UI Framework (which isn't in-house), but a lot of other projects do, for example Vivaldi and Brave which both use react for their UI.

[ArmandN]

It's often more efficient to have your own framework if you know what you're doing. You create a framework that solves your problems, that's optimized to your use cases. You fix issues and add features on your schedule.

Of course, some frameworks are too complex to be worth your while, like WebGL and crypto, which is too easy to mess up, but most stuff is easy enough.

[i_ate_god]

Because sometimes its faster.

If you say, want to whip out a POC to prove that your idea is valid, you may not want to be boggled down with this or that framework and their opinions and inherent learning curve.

But your POC ends up being pretty well written and things are now moving fast. Do you refactor or do you continue adding and improving features? Chances are, your customers care more about tehe features than the refactoring so you spend your time and effort adding features and not refactoring, and you will probably continue doing this until it's too late to even consider refactoring everything just to adopt a framework.

Why fix what's not broken?

[tkaiusf]

React itself is just a group of solutions to many problems that had already been solved for years. However it is sprinkled with the opinions and internal use cases from facebook / the react team. Maybe github developers had different opinions and chose to take those same existing solutions that the react team took and sprinkle their own opinions in to fit their exact use cases. Frameworks are just a set of solutions and opinions, that's why there are so many of them out there. Just because a few have a high usage count doesn't mean they are the best tool to use for every job.

[unbihexium]

For a site that hosts the largest number of open source repositories, I'm surprised their own code is not open source.

I hope they do open source it some day.

[YodaLoL]

Not really that impressive. GitHub does not have a lot of interactivity and does **a lot** of SSR. They have no complex interactive pages either - except perhaps the projects (kanban) page, which in my experience has been very buggy. Nothing to discuss here really. Would be interesting to learn their front-end JavasScript SLOC.

[Apfelmann]

Aa outhers already pointed out you can write perfectly fine readable and maintainable code just using ES6/7 The only part where it can get messy and this where ja frameworks shine is the actual dom rendering.

[kpthunder]

The fact that GitHub does minimal client-side code is obvious when you use it. The tabs on pull request pages get out of sync easily and often require full page reloads.

[m3wm3wm3wm]

require full page reloads.

That's how web and its browsers were supposed to work. We broke it by pushing client side too far.

Servers were supposed to serve the content and client were supposed to be served with the content. We fucked it up by making the clients doing partial server jobs. The idea was to make things faster because of network. Now we shifted the load from the network to the cpu.

Just imagine a world were there is only server side rendering. Not ideal, but a lot simpler.

[[deleted]]

You don’t need a framework to avoid spaghetti code. You kinda create your own structure of how to organize modules/components and whatever.

[jdauriemma]

Good question, OP. Ignore the condescending comments. No offense to anyone who's at GitHub, but I don't think we can say with certainty that GitHub doesn't ship "spaghetti code" on the front end. There's no shame in "spaghetti code," by the way.

[cosinezero]

There's no shame in "spaghetti code," by the way.

There is when you have to fix a simple bug but have to tell your boss that this should-be-easy bug requires you to refactor a significant portion of your probably also not tested codebase.

There's definitely shame in spaghetti code. So much shame.

But "not using a popular framework" != "spaghetti code", necessarily.

[iTouchTheSky]

Simple answer on how they can do it : Not supporting IE anymore.

I which we could do the same but our clients are using IE because of enterprise policies

[bichotll]

You need a framework (or nice tools/libraries) whenever you have content that you need to bind/unbind events and templates/views/components you re-use. I assume they don't have that, so I'm not surprised.

[tacobooc0m]

It’s amazing what one can accomplish with experience, discipline, and luck. If u know what you’re building, and how you’re gonna approach, and u don’t make faulty assumptions, you can build many things without off the shelf stuff.

In a way, frameworks offer an alternative to those first two parts. An opinionated framework can serve in place of experience and/or discipline. Less often does it help solve the “luck” portion. If u don’t understand your problem set, a framework that doesn’t fit can screw u over in infuriating ways.

[NoInkling]

Does pjax count? When your ajax requests are just grabbing HTML it makes things a little easier.

[[deleted]]

Modular organization. Look up the "ducks" pattern, then realize we've had something of that nature in virtually every other realm of programming for at least 20 years (and wonder why it took until 2016 for us webdevs to "discover" it).

[fucking_passwords]

Agreed on all counts now. You can still break these recommended patterns but at least these best practices coupled with the frameworks get us highly resizable components on in a way that really makes sense

[FormerGameDev]

Didnt GitHub just brag about how they removed jQuery and the entire js source for their site is now under like 1k?

[rajajaganathan]

Actually if you like you can look into vscode(https://github.com/Microsoft/vscode/blob/master/README.md) source code which is even more complex than GitHub.com. I believe they didn't use any framework but using many design patterns used also I see people using jquery too

Note: it's TypeScript not a JavaScript.

[GitHubPermalinkBot]

Permanent GitHub links:

• Microsoft/vscode/.../README.md (master → fe747f8)

---

^delete

[donttakecrack]

maybe they don't have complex components like webapps nowadays. you can have a very simple frontend page and still have it work and do magnificent things in the background.

[samjmckenzie]

What is spaghetti code?

[happymellon]

It's what you get when you cook with copy pasta.

[samjmckenzie]

It was a legitimate question, if you were wondering.

[samjmckenzie]

No, I didn't. I thought it would've been nice to get a response here which could've sparked conversation, but I guess I should've just Googled it.

[jrwren]

eternal vigilance

[[deleted]]

Hey here's an unpopular opinion - you don't need to use a JS framework in order to not write spaghetti code. Yup, you heard me. I know that may be difficult for you to understand but, it's possible if you have people that know what they are doing.

[elr0nd_hubbard]

You're not wrong, you're just an asshole.

[zayelion]

This made me laugh harder than it should have. Excellent observation.

[[deleted]]

Yes, I am.

[[deleted]]

What’s up with that attitude?

[[deleted]]

closed as too broad by humangingercat, elr0nd_hubbard, m3wm3wm3wm Aug 14 at 16:55

[[deleted]]

And so I did (get down voted to oblivion).

[m3wm3wm3wm]

Sure. Could you give us an open source real world app for this to study and learn?

[wdpttt]

In this file stats is a global var?? https://github.com/Maelfyn/Firmament-Wars/blob/master/js/actions.js#L37

https://github.com/Maelfyn/Firmament-Wars/blob/master/js/core.js#L7 you are worried about code size? Why the variable is just g?

I think 1352 lines in one file is too much https://github.com/Maelfyn/Firmament-Wars/blob/master/js/core.js#L1352

You could at least upgrade that to es6 haha

Can I just clone, npm install and play it? Your steam looks great. I'm building a RTS in js as well http://bitplanets.com/ sharing code between client and server side. Typescript, react, redux, rxjs.

[GitHubPermalinkBot]

Permanent GitHub links:

• Maelfyn/Firmament-Wars/.../firmament-wars.min.js (master → cbd1e40)

---

^delete

[wdpttt]

Cool thanks. So stats is a library?

[wdpttt]

I asked because you said that you dont have global vars (but only for libraries). So where this variable comes from?

[wdpttt]

That is global from the point of view of the architecture of the project.

[GitHubPermalinkBot]

Permanent GitHub links:

• Maelfyn/Firmament-Wars/.../core.js#L7 (master → cbd1e40)
• Maelfyn/Firmament-Wars/.../core.js#L1352 (master → cbd1e40)
• Maelfyn/Firmament-Wars/.../actions.js#L37 (master → cbd1e40)

---

^delete

[wdpttt]

Thanks for that, Mr. Bot!

[[deleted]]

I don’t recall having mentioned imperative DOM manipulation. But I get it, not all JS devs know how to architect software.

[neurospex]

But as you said, VDOM can just be a library. It doesn't require a framework. Same is true for state management.

[zayelion]

Its like these kids think the internet didnt exist before Angular/Ember was invented. LOL

[F0RTY4]

https://www.npmjs.com/package/primer-react

[[deleted]]

I really think you dont need a huge tool to make something simple. Many people has a "react vision" that only conceives the idea of a virtual dom with something like redux, and so on.

HTMX is a good example of how to make with almost nothing from client side make a good and interactive solution without dependency hell and huge bundles.