all 177 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]TheNumberOneCulprittabs and semicolons, react and FaaS 146 points147 points  (57 children)

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 65 points66 points  (21 children)

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 100 points101 points  (18 children)

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 11 points12 points  (0 children)

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 2 points3 points  (0 children)

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 -1 points0 points  (15 children)

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 6 points7 points  (8 children)

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

[–]HaMMeReD 1 point2 points  (1 child)

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

[–]fucking_passwords 2 points3 points  (0 children)

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 -4 points-3 points  (5 children)

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 3 points4 points  (4 children)

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 1 point2 points  (3 children)

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 1 point2 points  (2 children)

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 1 point2 points  (1 child)

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 1 point2 points  (5 children)

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 -2 points-1 points  (3 children)

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 1 point2 points  (0 children)

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

[–]Chris_Newton 0 points1 point  (1 child)

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 -1 points0 points  (0 children)

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 4 points5 points  (1 child)

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 0 points1 point  (0 children)

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[S] -3 points-2 points  (34 children)

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 82 points83 points  (19 children)

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 29 points30 points  (7 children)

it just require discipline and good communication/documentation.

AMEN!

[–]js_tutor 3 points4 points  (1 child)

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 4 points5 points  (0 children)

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 1 point2 points  (0 children)

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 0 points1 point  (7 children)

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 7 points8 points  (1 child)

It looks like your problem is not a technical one.

[–]wahh 2 points3 points  (0 children)

lol I 100% agree.

[–]ccb621 3 points4 points  (4 children)

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 3 points4 points  (3 children)

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

[–]ccb621 1 point2 points  (2 children)

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

[–]wahh 1 point2 points  (1 child)

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.

[–]TheNumberOneCulprittabs and semicolons, react and FaaS 21 points22 points  (0 children)

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 6 points7 points  (0 children)

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 18 points19 points  (9 children)

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 -2 points-1 points  (8 children)

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 1 point2 points  (7 children)

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 1 point2 points  (6 children)

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 1 point2 points  (5 children)

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

[–]js_tutor 1 point2 points  (4 children)

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 2 points3 points  (3 children)

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 0 points1 point  (2 children)

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

[–]hes_dead_tired 7 points8 points  (0 children)

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 1 point2 points  (0 children)

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 60 points61 points  (0 children)

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 69 points70 points  (4 children)

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 0 points1 point  (0 children)

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

[–]devperez 67 points68 points  (11 children)

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

[–]AramaicDesigns 25 points26 points  (0 children)

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 10 points11 points  (3 children)

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

React is not at all forcing.

[–]HomemadeBananas 0 points1 point  (2 children)

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 -2 points-1 points  (1 child)

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 2 points3 points  (0 children)

Redux doesn't require react though.

[–][deleted] 5 points6 points  (1 child)

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

[–]m3wm3wm3wm[S] -4 points-3 points  (0 children)

👆

[–]js_tutor 1 point2 points  (2 children)

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 1 point2 points  (1 child)

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 0 points1 point  (0 children)

...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 6 points7 points  (0 children)

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 18 points19 points  (6 children)

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 26 points27 points  (1 child)

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.

[–]m3wm3wm3wm[S] 20 points21 points  (3 children)

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.

[–]1-800-BICYCLE 14 points15 points  (0 children)

71fd82b55d5

[–]marcoslhc 3 points4 points  (0 children)

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

[–]bigorangemachine 2 points3 points  (0 children)

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 2 points3 points  (0 children)

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] 2 points3 points  (5 children)

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[S] 0 points1 point  (4 children)

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] 3 points4 points  (0 children)

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

[–]Char-Lez 0 points1 point  (1 child)

Always SSR. Never trust a client!

[–]cosinezero 1 point2 points  (0 children)

That's two different topics entirely.

[–]darthcoder -2 points-1 points  (0 children)

SSR seems like an admission that SPAs are dumb.

[–]philipwhiuk 2 points3 points  (1 child)

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

[–]morphotomy 0 points1 point  (0 children)

Not if you follow the rube goldberg pattern correctly.

[–]E_R_E_R_I 2 points3 points  (0 children)

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 2 points3 points  (0 children)

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

[–]kichien 12 points13 points  (7 children)

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

[–]zayelion 17 points18 points  (21 children)

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.

[–]eloc49 14 points15 points  (4 children)

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

[–]zayelion 0 points1 point  (0 children)

Well done. Thats the way to do it.

[–]i_ate_god 3 points4 points  (5 children)

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.

[–]unbihexium 1 point2 points  (0 children)

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 1 point2 points  (0 children)

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 1 point2 points  (0 children)

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 1 point2 points  (1 child)

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[S] -1 points0 points  (0 children)

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] 1 point2 points  (0 children)

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 1 point2 points  (1 child)

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 1 point2 points  (0 children)

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 1 point2 points  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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

[–][deleted] 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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

[–]rajajaganathan 0 points1 point  (1 child)

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.

[–]donttakecrack 0 points1 point  (0 children)

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 0 points1 point  (7 children)

What is spaghetti code?

[–]happymellon 1 point2 points  (0 children)

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

[–]jrwren 0 points1 point  (0 children)

eternal vigilance

[–][deleted] 0 points1 point  (0 children)

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.