How we use Web Components at GitHub

GitHub has long been a proponent of Web Components. Here’s how we use them.

At GitHub, we pride ourselves on delivering a first-class developer experience. A considerable part of our work is on our front end, which we strive to keep as lightweight, fast, and accessible as possible. For a product as large as GitHub, this can be quite the task. Like many front-end codebases, we leverage components, independent, isolated, and reusable pieces of code that allow application teams to deliver high fidelity UI quickly and efficiently while still keeping to our high standards of quality.

We’re using Web Components in a big way at GitHub. We have over a dozen open-source Web Components and with dozens more that are closed source.

How we got here

When GitHub launched over a decade ago, we had a modest front-end codebase that mostly used jQuery. Ten years and nearly 85,000 lines of code later, we had a large front-end codebase that was starting to show growing pains. We ultimately transitioned away from jQuery (for reasons which we detailed in a blog post at the time) and started using new technologies which could better solve our problems.

We began to dabble with a new technology called Web Components, a set of native browser technologies that allow the development of customized HTML elements, progressively enhanced with JavaScript.

We chose to use Web Components because our codebase was already structured into component-like behaviors. Still, as the GitHub monolith grew in size, we saw the need to implement better encapsulations before the front-end became unmanageable – and Web Components fit the bill. Web Components offered better portability and encapsulation than our existing JavaScript behaviors. We were happy to experiment with Web Components alongside our existing front-end infrastructure since it doesn’t incur any upfront cost or “buy-in” to a specific framework.

Our first two custom elements shipped in 2014: elative-time and local-time, which show times and dates in friendly formats, and include-fragment, which allows us to lazy load HTML fragments. Slowly we realized just how powerful these elements could be and began replacing design patterns within the codebase wholesale, such as replacing our “facebox” modal dialog pattern with details-dialog. Our components now range from very generic, multi-purpose behaviors like remote-input to specific single-purpose components such as the markdown-toolbar element and its siblings.

For the power Web Components affords, there are still pain points and pitfalls. With such a large codebase owned by hundreds of engineers across dozens of teams, we need to provide as much support and tooling as possible, encoding best practices without manual code review becoming a bottleneck.

#github #web-components #web-development #programming #developer

What is GEEK

Buddha Community

How we use Web Components at GitHub

How we use Web Components at GitHub

GitHub has long been a proponent of Web Components. Here’s how we use them.

At GitHub, we pride ourselves on delivering a first-class developer experience. A considerable part of our work is on our front end, which we strive to keep as lightweight, fast, and accessible as possible. For a product as large as GitHub, this can be quite the task. Like many front-end codebases, we leverage components, independent, isolated, and reusable pieces of code that allow application teams to deliver high fidelity UI quickly and efficiently while still keeping to our high standards of quality.

We’re using Web Components in a big way at GitHub. We have over a dozen open-source Web Components and with dozens more that are closed source.

How we got here

When GitHub launched over a decade ago, we had a modest front-end codebase that mostly used jQuery. Ten years and nearly 85,000 lines of code later, we had a large front-end codebase that was starting to show growing pains. We ultimately transitioned away from jQuery (for reasons which we detailed in a blog post at the time) and started using new technologies which could better solve our problems.

We began to dabble with a new technology called Web Components, a set of native browser technologies that allow the development of customized HTML elements, progressively enhanced with JavaScript.

We chose to use Web Components because our codebase was already structured into component-like behaviors. Still, as the GitHub monolith grew in size, we saw the need to implement better encapsulations before the front-end became unmanageable – and Web Components fit the bill. Web Components offered better portability and encapsulation than our existing JavaScript behaviors. We were happy to experiment with Web Components alongside our existing front-end infrastructure since it doesn’t incur any upfront cost or “buy-in” to a specific framework.

Our first two custom elements shipped in 2014: elative-time and local-time, which show times and dates in friendly formats, and include-fragment, which allows us to lazy load HTML fragments. Slowly we realized just how powerful these elements could be and began replacing design patterns within the codebase wholesale, such as replacing our “facebox” modal dialog pattern with details-dialog. Our components now range from very generic, multi-purpose behaviors like remote-input to specific single-purpose components such as the markdown-toolbar element and its siblings.

For the power Web Components affords, there are still pain points and pitfalls. With such a large codebase owned by hundreds of engineers across dozens of teams, we need to provide as much support and tooling as possible, encoding best practices without manual code review becoming a bottleneck.

#github #web-components #web-development #programming #developer

Web Components at Github

Kristján Oddsson detailed at the Web Components SF meetup how GitHub uses Web Components and the patterns GitHub identified to foster readable, performant, and accessible front end components.

Oddsson started by illustrating how a a simple behavior would be implemented in vanilla JavaScript at GitHub:

on('click', 'js-hello-world-button', function (event) {
  const button = event.currentTarget;
  const container = button.closest('js-hello-world');

  const input = container.querySelector('js-hello-world-input');
  const output = container.querySelector('js-hello-world-output');

  output.textContent = `Hello, ${input.value}`
}

with the corresponding HTML on the page:

<div class="js-hello-world">
  <input class="js-hello-world-input" type="text">
  <button class="js-hello-world-button">
    Greet
  </button>

   
</div>

The previous code does not rely on any abstractions beyond the standard web APIs and as such may be among the most efficient way to write the required behavior (displaying a welcome message on a button click). However, Oddsson mentioned a few issues with the approach: a naming scheme is required, the DOM querying is explicit, classes are not scoped and could be overloaded unwillingly. This results in more work on the developer side.

Oddsson then explained that the team at GitHub has been converting behaviors like the previous one into progressively-enhanced custom elements. GitHub’s custom elements align as much as possible on built-in elements behavior. GitHub custom elements additionally do not use the shadow DOM.

Oddsson then uses the <auto-check> custom element — that automatically check the availability of a repository name while the user is typing, to illustrate the boilerplate involved in writing web components.

First, custom elements define an interface that includes four methods (connectedCallbackdisconnectedCallback adoptedCallbackattributeChangedCallback) corresponding to different stages of the lifecycle of the element. An observedAttributes method also specifies which attributes to notice change for. Additionally, a custom element typically would have methods to retrieve and set the attributes that constitute the interface it exposes to the component users.

Then custom elements must be added to the registry if they are not already there (window.customElements.define method). The DOM elements that are involved in the behavior must also be queried — this.querySelector('input') for instance retrieves the input child element where the user enters the repository name. Additionally, as GitHub uses TypeScript, the relevant types must be created:

declare global {
  interface Window {
    AutoCheckElement: typeof AutoCheckElement
  }
  interface HTMLElementTagNameMap {
    'auto-check': AutoCheckElement
  }
}

#javascript #github #web components #web development #development #architecture & design #news

Spring: A Static Web Site Generator Written By GitHub Issues

Spring

Spring is a blog engine written by GitHub Issues, or is a simple, static web site generator. No more server and database, you can setup it in free hosting with GitHub Pages as a repository, then post the blogs in the repository Issues.

You can add some labels in your repository Issues as the blog category, and create Issues for writing blog content through Markdown.

Spring has responsive templates, looking good on mobile, tablet, and desktop.Gracefully degrading in older browsers. Compatible with Internet Explorer 10+ and all modern browsers.

Get up and running in seconds.

中文介绍

Quick start guide

For the impatient, here's how to get a Spring blog site up and running.

First of all

  • Fork the Spring repository as yours.
  • Goto your repository settings page to rename Repository Name.
  • Hosted directly on GitHub Pages from your project repository, you can take it as User or organization site or Project site(create a gh-pages branch).
  • Also, you can set up a custom domain with Pages.

Secondly

  • Open the index.html file to edit the config variables with yours below.
$.extend(spring.config, {
  // my blog title
  title: 'Spring',
  // my blog description
  desc: "A blog engine written by github issues [Fork me on GitHub](https://github.com/zhaoda/spring)",
  // my github username
  owner: 'zhaoda',
  // creator's username
  creator: 'zhaoda',
  // the repository name on github for writting issues
  repo: 'spring',
  // custom page
  pages: [
  ]
})
  • Put your domain into the CNAME file if you have.
  • Commit your change and push it.

And then

  • Goto your repository settings page to turn on the Issues feature.
  • Browser this repository's issues page, like this https://github.com/your-username/your-repo-name/issues?state=open.
  • Click the New Issue button to just write some content as a new one blog.

Finally

  • Browser this repository's GitHub Pages url, like this http://your-username.github.io/your-repo-name, you will see your Spring blog, have a test.
  • And you're done!

Custom development

Installation

  • You will need a web server installed on your system, for example, Nginx, Apache etc.
  • Configure your spring project to your local web server directory.
  • Run and browser it, like http://localhost/spring/dev.html .
  • dev.html is used to develop, index.html is used to runtime.

Folder Structure

spring/
├── css/
|    ├── boot.less  #import other less files
|    ├── github.less  #github highlight style
|    ├── home.less  #home page style
|    ├── issuelist.less #issue list widget style
|    ├── issues.less #issues page style
|    ├── labels.less #labels page style
|    ├── main.less #commo style
|    ├── markdown.less #markdown format style
|    ├── menu.less #menu panel style
|    ├── normalize.less #normalize style
|    ├── pull2refresh.less #pull2refresh widget style
|    └── side.html  #side panel style
├── dist/
|    ├── main.min.css  #css for runtime
|    └── main.min.js  #js for runtime
├── img/  #some icon, startup images
├── js/
|    ├── lib/  #some js librarys need to use
|    ├── boot.js  #boot
|    ├── home.js  #home page
|    ├── issuelist.js #issue list widget
|    ├── issues.js #issues page
|    ├── labels.js #labels page
|    ├── menu.js #menu panel
|    ├── pull2refresh.less #pull2refresh widget
|    └── side.html  #side panel
├── css/
|    ├── boot.less  #import other less files
|    ├── github.less  #github highlight style
|    ├── home.less  #home page style
|    ├── issuelist.less #issue list widget style
|    ├── issues.less #issues page style
|    ├── labels.less #labels page style
|    ├── main.less #commo style
|    ├── markdown.less #markdown format style
|    ├── menu.less #menu panel style
|    ├── normalize.less #normalize style
|    ├── pull2refresh.less #pull2refresh widget style
|    └── side.html  #side panel style
├── dev.html #used to develop
├── favicon.ico #website icon
├── Gruntfile.js #Grunt task config
├── index.html #used to runtime
└── package.json  #nodejs install config

Customization

  • Browser http://localhost/spring/dev.html, enter the development mode.
  • Changes you want to modify the source code, like css, js etc.
  • Refresh dev.html view change.

Building

  • You will need Node.js installed on your system.
  • Installation package.
bash

$ npm install

*   Run grunt task.

    ```bash
$ grunt
  • Browser http://localhost/spring/index.html, enter the runtime mode.
  • If there is no problem, commit and push the code.
  • Don't forget to merge master branch into gh-pages branch if you have.
  • And you're done! Good luck!

Report a bug

Who used

If you are using, please tell me.

Download Details:
Author: zhaoda
Source Code: https://github.com/zhaoda/spring
License: MIT License

#spring #spring-framework #spring-boot #java 

Kabanda  Nat

Kabanda Nat

1624094899

[Part 2]: Using Lightning Web Components to Create Progressive Web Apps

When a server sends a push notification to a subscribed user, it needs to authenticate itself as the same server to which the user subscribed. To do this, there is an entire spec (called the VAPID spec) that dictates how this authentication works. Fortunately for us, the web-push package helps to abstract away most of these low-level details.

The one thing we do need to do, however, is generate a VAPID public/private key pair, and store it in a .env file so we can access those keys as environment variables.

#web dev #progressive #web apps #lightning web #components

Evolution in Web Design: A Case Study of 25 Years - Prismetric

The term web design simply encompasses a design process related to the front-end design of website that includes writing mark-up. Creative web design has a considerable impact on your perceived business credibility and quality. It taps onto the broader scopes of web development services.

Web designing is identified as a critical factor for the success of websites and eCommerce. The internet has completely changed the way businesses and brands operate. Web design and web development go hand-in-hand and the need for a professional web design and development company, offering a blend of creative designs and user-centric elements at an affordable rate, is growing at a significant rate.

In this blog, we have focused on the different areas of designing a website that covers all the trends, tools, and techniques coming up with time.

Web design
In 2020 itself, the number of smartphone users across the globe stands at 6.95 billion, with experts suggesting a high rise of 17.75 billion by 2024. On the other hand, the percentage of Gen Z web and internet users worldwide is up to 98%. This is not just a huge market but a ginormous one to boost your business and grow your presence online.

Web Design History
At a huge particle physics laboratory, CERN in Switzerland, the son of computer scientist Barner Lee published the first-ever website on August 6, 1991. He is not only the first web designer but also the creator of HTML (HyperText Markup Language). The worldwide web persisted and after two years, the world’s first search engine was born. This was just the beginning.

Evolution of Web Design over the years
With the release of the Internet web browser and Windows 95 in 1995, most trading companies at that time saw innumerable possibilities of instant worldwide information and public sharing of websites to increase their sales. This led to the prospect of eCommerce and worldwide group communications.

The next few years saw a soaring launch of the now-so-famous websites such as Yahoo, Amazon, eBay, Google, and substantially more. In 2004, by the time Facebook was launched, there were more than 50 million websites online.

Then came the era of Google, the ruler of all search engines introducing us to search engine optimization (SEO) and businesses sought their ways to improve their ranks. The world turned more towards mobile web experiences and responsive mobile-friendly web designs became requisite.

Let’s take a deep look at the evolution of illustrious brands to have a profound understanding of web design.

Here is a retrospection of a few widely acclaimed brands over the years.

Netflix
From a simple idea of renting DVDs online to a multi-billion-dollar business, saying that Netflix has come a long way is an understatement. A company that has sent shockwaves across Hollywood in the form of content delivery. Abundantly, Netflix (NFLX) is responsible for the rise in streaming services across 190 countries and meaningful changes in the entertainment industry.

1997-2000

The idea of Netflix was born when Reed Hastings and Marc Randolph decided to rent DVDs by mail. With 925 titles and a pay-per-rental model, Netflix.com debuts the first DVD rental and sales site with all novel features. It offered unlimited rentals without due dates or monthly rental limitations with a personalized movie recommendation system.

Netflix 1997-2000

2001-2005

Announcing its initial public offering (IPO) under the NASDAQ ticker NFLX, Netflix reached over 1 million subscribers in the United States by introducing a profile feature in their influential website design along with a free trial allowing members to create lists and rate their favorite movies. The user experience was quite engaging with the categorization of content, recommendations based on history, search engine, and a queue of movies to watch.

Netflix 2001-2005 -2003

2006-2010

They then unleashed streaming and partnering with electronic brands such as blu-ray, Xbox, and set-top boxes so that users can watch series and films straight away. Later in 2010, they also launched their sophisticated website on mobile devices with its iconic red and black themed background.

Netflix 2006-2010 -2007

2011-2015

In 2013, an eye-tracking test revealed that the users didn’t focus on the details of the movie or show in the existing interface and were perplexed with the flow of information. Hence, the professional web designers simply shifted the text from the right side to the top of the screen. With Daredevil, an audio description feature was also launched for the visually impaired ones.

Netflix 2011-2015

2016-2020

These years, Netflix came with a plethora of new features for their modern website design such as AutoPay, snippets of trailers, recommendations categorized by genre, percentage based on user experience, upcoming shows, top 10 lists, etc. These web application features yielded better results in visual hierarchy and flow of information across the website.

Netflix 2016-2020

2021

With a sleek logo in their iconic red N, timeless black background with a ‘Watch anywhere, Cancel anytime’ the color, the combination, the statement, and the leading ott platform for top video streaming service Netflix has overgrown into a revolutionary lifestyle of Netflix and Chill.

Netflix 2021

Contunue to read: Evolution in Web Design: A Case Study of 25 Years

#web #web-design #web-design-development #web-design-case-study #web-design-history #web-development