DEV Community: Paul Rumkin

Less confusing defaults

Paul Rumkin — Fri, 15 Nov 2019 17:08:02 +0000

The less confusing (and harmful) defaults for code and configuration are different and opposite. Here it is:

By Default

Run production code.
Use development configuration.

Other should be specified implicitly.

Why?

Development code can skip some checks or allow users to override permissions. Production code is (well should be) free of such dangerous behavior. That's why production code should be run by default.

In the same time development configuration usually specifies test database and API endpoints. And thus such configuration couldn't spent users funds or send a real messages and considered less harmful.

How

Debug/Dev mode

❌ Wrong:

const DEBUG = process.env.NODE_ENV !== 'production'

✅ Correct:

const DEBUG = process.env.NODE_ENV === 'development'

Config

❌ Wrong:

const CFG = process.env.NODE_ENV || 'production'

const config = require(`configs/${CFG}.js`)

✅ Correct

const CFG = process.env.NODE_ENV || 'development'

const config = require(`configs/${CFG}.js`)

People shouldn't code

Paul Rumkin — Wed, 09 Oct 2019 01:37:17 +0000

The most important thing I've realized after 18 years of coding: people shouldn't code. Machines should code. People should use the result.

I extremely love coding. But I code to bring the moment when people start to enjoy the life instead of sitting behind computers.

Why do you code, what’s your big goal?

Smart web design. Part II: Customizable color theme in 10 minutes 🦜⏱

Paul Rumkin — Wed, 02 Oct 2019 09:47:09 +0000

Customizable color palette use css variables for color values to make it easy to change via JS or CSS. But good theme requires colors with shades.

HSL vs RGB

The oldest and the most popular color model on the Web is RGB (Red, Green, Blue). It has pretty simple and short syntax #ff0000 (red). But it's really hard to remember all the combinations of colors and manipulate them without color picker.

But there is one color scheme which is extremely simple in work! It's HSL (Hue, Saturation, Lightness):

Hue tells wether the color be blue, red, yellow, green or violet, it refers to color wheel angle.
Saturation tells how much hue is there, wether it fade (0%) or bright (100%).
Lightness tells wether it dark (0%, black) or light (100%, white).

HSL represents colors in more human way. Red in HSL is hsl(0, 100%, 50%) to turn it into blue we just need to change hue param hsl(200, 100%, 50%).

Theme Colors

Now we need to define theme colors. We will create duotone theme, but you can use as much colors as you need, just don't overdo it. Let's call our colors major and minor. To receive color shades we will change the lightness parameter. Shades will be named with two digit indexes from lightest to darkest, e.g. --major-10 lightest and --major-90 darkest.

:root {
  /* Major color is red */
  --major-5: hsl(0, 100%, 95%);
  --major-10: hsl(0, 100%, 90%);
  --major-30: hsl(0, 100%, 70%);
  --major-50: hsl(0, 100%, 50%);
  --major-70: hsl(0, 100%, 30%);
  --major-90: hsl(0, 100%, 10%);

  /* Minor color is yellow */
  --minor-5: hsl(50, 100%, 95%);
  --minor-10: hsl(50, 100%, 90%);
  --minor-30: hsl(50, 100%, 70%);
  --minor-50: hsl(50, 100%, 50%);
  --minor-70: hsl(50, 100%, 30%);
  --minor-90: hsl(50, 100%, 10%);

  --bg: white; /* background color */
  --fg: black; /* text color */
}

Live demo:

Advanced theming

You can customize colors using custom css files in combination with media queries. For example printable version could be black and white only.

Basic theme.css file could look like this:

:root {
  --major-10: hsl(0, 100%, 90%);
  /* ... */
  --minor-10: hsl(50, 100%, 90%);
  /* ... */

  --bg: white;
  --fg: black;
}

Dark theme

Dark theme section in theme.css:

@media (prefers-color-scheme: dark) {
  :root {
    --major-10: hsl(0, 100%, 90%);
    /* ... */
    --minor-10: hsl(50, 100%, 90%);
    /* ... */

    --bg: black;
    --fg: white;
  }
}

Printable version

Printable theme section in theme.css:

@media print {
  :root {
    --major-10: hsl(0, 0%, 90%);
    /* ... */
    --minor-10: hsl(50, 0%, 90%);
    /* ... */
  }
}

Theme switching

There is a lot of options how to implement a switcher, but the simplest one is a switcher that changes link or style elements order, moving the target theme related element to the end of children list. This is how it implemented in live preview:

function applyTheme(name) {
  // Find style element with matching id
  const style = document.getElementById(name + 'Theme')

  // Move it to the end of child list
  const parent = style.parentElement
  parent.removeChild(style)
  parent.appendChild(style)

  // Remember user's choise
  localStorage.setItem('theme', name)
}

// Get switcher
const switcher = document.getElementById('themeSwitcher')

// React on select input value changed
switcher.addEventListener('change', (e) => {
  useTheme(e.target.value)
})

// Select color in select input and apply theme selection
applyTheme(
  switcher.value = localStorage.getItem('theme')
)

⚠️ Accessibility

Please, don't forget to include high contrast themes in your design. It will be very helpful for people with color blindness.

Conclusion

That's all. Now you know how simple it is to create a customizable CSS design for you site. Using favicon-switcher from my previous article "Smart web design. Part I: light/dark mode favicon." you able to make real stunning design.

Credits

Cover image by David Clode on Unsplash.com.

What is web shell and why create it?

Paul Rumkin — Mon, 30 Sep 2019 00:26:11 +0000

Web shell is a next generation of browsers. Web shell fixes browsers incompleteness and make the Web a self-hosted platform.

Observer is the first web shell. It's built with Electron. It has a lot of features which hasn't announced yet and will be kept in secret for some time 😎 (that's a reason to follow Observer profile).

Short announcement

After a long time I've finally decided to build the Observer as a complete application for demonstration purposes and here it is:

Motivation

So why to build new browser today? In the history of the Web there was two great browser wars: the first has won by Internet Explorer which defeated Netscape Navigator and the second when Firefox defeated IE. The second war finished twelve years ago in 2007. For this twelve years the only thing that has changed is a leader, now it's Chrome.

The second war was caused by poor standard support and backwardness of IE. But today all browsers are supporting standards well, they all works together to solve the issues. What the reason to change something?

This is my reasons:

Modern browsers are just an addition to the operation system's native apps, while they should be the first class citizens and work seamlessly on any platform. Browser should became the one and only application required to cover any user activity.
Browsers aren't secure: Users could not control the code they run! Users couldn't check what web application do! Does it sniff ports or create fingerprint. Publisher could do whatever they want on users' computers!

So what am the goal of Observer? Observer will make the Web a complete and the only platform for running applications.

References

Observer profile.
Observer repository (will be filled with code soon):

observer0x / observer

The Observer browser

🍹🌟 CSS for fun

Paul Rumkin — Sat, 21 Sep 2019 16:16:36 +0000

Sometimes you just want to make things work and not to think about names. Emojis here to help.

⚠️ Don't overuse it. Read about how people with vision impairments use emoji.

Example

This is a BEM-like emoji classnames example.

.🦄 {
  height: 100%;
  display: grid;
  align-items: center;
  justify-content: center;
  background: cornsilk;
}

.🦄-header {
  font-size: 72px;
  color: violet;
}

And apply it:

<div class="🦄">
  <h1 class="🦄-header">
    Unicorns rule!
  </h1>
</div>

Preview

Smart web design. Part I: light/dark mode favicon.

Paul Rumkin — Sat, 14 Sep 2019 10:53:02 +0000

Today we have new super cool ability to detect OS UI theme and change the site view according to it. It makes us to use new techniques to write themeable and easy to customize css and html. In this series of posts I'm going to tell you how to create simple themeable design for your web apps.

While we can change the page visualization with CSS and HTML, there is one element which still has no such ability. And you already have know what I'm talking about. Yes, it's a favicon.

If you take a look at favicons of Dev.to or Github in dark mode, you'll see they became almost invisible. We need to change it and make favicon to react on theme switch. The most logical way to do so is media attribute of the link element which allows favicon to react on CSS media query passed into attribute value. But, unfortunately, the list of media queries supported by link's media attribute doesn't include prefers-color-scheme.

And, fortunately, we could make it works using JavaScript. Well let's do it.

Here it is the live preview of how it could work.

TL;DR For those who want ready solution, use the library:

rumkin / favicon-switcher

Make favicon react on media queries

Listen for theme switch

We need to collect all link elements from the page head, get media attribute and match it using window.matchMedia() method. This method returns MediaQueryList, which allows listen changes and we will use it:

window.matchMedia('(prefers-color-scheme:light)').addListener((e) => {
  e.matches // Determine wether query matched or unmatched
})

Add icons

Now we need to insert icons for different themes into a page body:

  <link rel="icon" media="(prefers-color-scheme:dark)" href="favicon-dark.png" type="image/png" />
  <link rel="icon" media="(prefers-color-scheme:light)" href="favicon-light.png" type="image/png" />

Switch the icon

To make browser switch a tab's icon it's enough to make <link> element to be the last <link> element inside of the <head>. This works fine, but Chrome currently has a bug which breaks such icon switching in some conditions. To avoid this bug, we need to create new <link> and append it to the head children list after other links.

const favicon = document.createElement('link')
link.setAttribute('rel', 'favicon icon')
head.appendChild(link)

// Listen media change
window.matchMedia('(prefers-color-scheme:light)')
.addListener((e) => {
  if (! e.matches) {
    return
  }
  // Apply new favicon source
  const source = document.querySelector('link[rel*="icon",media="(prefers-color-scheme:light)"]')

  if (source === null) {
    return
  }

  link.setAttribute('type', source.type)
  link.setAttribute('href', source.href)
})

Just duplicate the last expression and replace light with dark to enable dark theme icon.

Note! We check wether source is null due to possible DOM mutations.

Conclusion

Now you know how to make a page favicon to react on theme switching.

Thanks for reading. Use favicon-switcher which covers more use-cases and supports other media-queries, like max-width, min-width, etc.

Credits

Photo by Linda Xu on Unsplash

What do you call people who don't code?

Paul Rumkin — Sun, 08 Sep 2019 23:52:53 +0000

There are two groups of people who can create programs and those who don't. I'm about writing article about this groups and I need to name them somehow. There is no problem with the first group. It's easy. But what's about another? It's too wordy to call them "noncoding people". Also I'm not a big fan of terms with negative prefixes like "non-coders".

I'm stuck and my English vocabulary isn't so good to find such definition. Also it's hard to determine whether there are negative connotations or not to name them on my own. Any suggestions?

Creating JS web server without Node.js

Paul Rumkin — Sat, 07 Sep 2019 19:37:15 +0000

Today there are exists a lot of web servers created for Node.js and it's hard to tell which one is better. Engineers are working to add something new into their products and using the last JS and v8 abilities to bring faster, handy and effective solutions. And I'm working on one too. It's Plant. In this article I will tell about Plant's ability to work without Node.js.

Plant is a WebAPI charged web server, what means it's using the same interfaces as browsers do. Also it's transport agnostic and you can deliver requests using anything: TCP, WebSocket, WebRTC, etc. Tying all this up it could work in a browser and on a server in the same way. What this ability gives to us?

We can develop a web server using only code editor and web browser, using DevTool's debugger instead of console.log for troubleshooting and then just move it to Node.js.
We don't even need to install anything.
It makes tests more reliable and simple to write, run and understand.
Easy to learn: code is isolated into browser and free of environment influence.
Truly crossplatform: it works in the same way everywhere.

TL;DR. Here it is the simple demo and complex demo.

Demo repo · Plant repo

Well let's start. All you need to start is to create simple HTML file with empty page.



<!DOCTYPE html>
<html>
  <head></head>
  <body></body>
</html>

Import

To use Plant in your web page just import it from unpkg.com:



<script src="https://unpkg.com/@plant/plant@2.4.0/dist/plant.js"></script>

Put it into <head>. Then create new <script> into <body> element for our application.

Create server

Server creation is similar to Express' or Koa's with small differences.



// Instantiate server
const plant = new Plant()

// Add handler
plant.use('/index.html', ({req, res}) => {
  res.html('<!DOCTYPE html><html><body>Hello</body></html>')
})

That's it. We created a very simple request handler which serves '/index.html' page. Note that route is very strict. It would handle /index.html but not /.

Making request

Browsers couldn't listen requests and we will simulate it on ourselves. This code could be used to handle requests delivered by WebSocket or any other transport, so it could be used by anything.

This is our final code which will de explained later:



const handle = plant.getHandler()

const context = createContext('GET', 'https://localhost:8000/index.html')

handle(context)
.then(({res}) => {
  res.status // -> 200
  res.body // -> '<!DOCTYPE html>...
})

Creating context

Plant context is a simple Object instance. It requires Socket, Request and Response instances to be passed as socket, req and res properties respectively.



function createContext(method, url, {headers = {}, body} = {}) {
  const req = new Plant.Request({
    url: new URL(url),
    method,
    body,
    headers,
  })

  const res = new Plant.Response({
    url: new URL(url),
  })

  const socket = new Plant.Socket({
    peer: new Plant.Peer({
      uri: new Plant.URI({
        protocol: 'browser',
        host: navigator.appName,
      })
    })
  })

  return {req, res, socket}
}

Socket requires a peer instance which represents another party of a connection. Peer should always have an address provided as URI. URI is using here instead of standard URL due to URL's inability to work with custom schemes. All this needed due we suggest that peer could receive connections too, because Plant can use transport supporting this ability.

POST requests

To simulate POST request we need to create ReadableStream instance and pass it into Request constructor.



const body = streamFrom('Hello')

new Request({
  method: 'GET',
  url: 'https://localhost:8000',
  body,
})

function streamFrom(value) {
  return new ReadableStream({
    start(controller) {
      // Encode UTF8 into Uint8Array and push it into the stream
      const encoder = new TextEncoder()
      controller.enqueue(encoder.encode(value))
      controller.close()
    },
  })
}

Function createStream creates ReadableStream instance and write whole passed value as a single chunk into it.

Conclusion

Now you can put it all together and emulates request right in a browser on your own without using Node.js. Or you can get write and debug your API in a browser and then move it to Node.js with minimal changes. And the same code could be used in tests.

If you meet some difficulties or want to check yourself use simple example or more complex demonstration.

Repositories

rumkin / plant

🌳 JS web server charged with WebAPI and neat HTTP2 support

Plant

NPM · Source · Readme

Plant is WebAPI standards based HTTP2 web server, created with modular architecture and functional design in mind. Also it's pure and less coupled.

Plant supports HTTP 1 and HTTP 2 protocols. But it's transport agnostic and can work right in the browser over WebSockets, WebRTC, or PostMessage.

Features

☁️ Lightweight: only 8 KiB minified and gzipped.
✨ Serverless ready: works even in browser.
🛡 Security oriented: uses the most strict Content Securiy Policy (CSP) by default.
📐 Standards based: uses WebAPI interfaces.
🛳 Transport agnostic: no HTTP or platform coupling, ship requests via everything.

Install

# Install plant web server
npm i @plant/plant
# Install node HTTP2 transport
npm i @plant/http2

Examples

Hello World

Hello world with HTTP2 as transport.

⚠️ Note that default CSP header value is default-src localhost; form-action localhost This will…

View on GitHub

rumkin / plant-browser-demo

Nodeless web server demo

Plant Browser Demo

This is a single-file demo web application. Its' purpose is to show how to develop fully functional web server with test coverage without Node.js using only browser and code editor.

Usage

Save page on disk.
Open it in code editor.
Update #Server and #Spec scripts code.
Refresh the page. DevTools console should contain complete output of your test.

Dependencies

Structure overview

Code of the example is structured into several scripts. Each script contains code related to specific task.

<script id="Server"></script>
<script id="Spec"></script>
<script id="TestupHelpers"></script>
<script id="PlantHelpers"></script>
<script id="Main"></script>

Where:

#Server. Your http API code.
#Spec. Your tests for the…

View on GitHub

CopyBar: © for collaboration

Paul Rumkin — Fri, 30 Aug 2019 18:00:37 +0000

Today every developer is using others work. It's just near to impossible to avoid third party dependencies in your project. But there are not so much ways to support other developers. We need to find a solution which will help independent developers and in the same time would not harm the open source movement itself. And the result should be a technical solution not a conversation.

My proposal is to show a list of libraries we use in our web apps. For this I propose to transform useless copyright message into functional component.

Support initiative with star on Github.

Preview

Motivation

Funding-gate with implementation proto-advertisement network into standard npm package.
Libraries developers have less chances to receive funding than authors who use their work.

Specification

Convert copyright message like "©, Author, 2019" into group of links or buttons, where:

"©" refers to about section with app dependencies
"Author" refers to author's contact information
"2019" refers to app's changelog.

About section

This section contains license information, list of used packages, application name and version.

Author section

This section doesn't require any particular structure.

Changelog section

Present valuable information into a web app about its' changes. Should hold list of versions with changes and links to commits.

Pros

Usefulness. It brings new ways for developers to promote their work.
Usability. It's a very simple way to figure out which libraries was used in implementation.
Security. Everyone can figure out is it safe to use the app.
Legal issues. We should provide information about used software in our products according to licenses.
Ethics. It's just correct to share information about those who helped you.

Cons

No found yet.

Real life example

You can see it in action at Code-to-Image web app:

References

Copybar Spec

Ultimate web app requirements list

Paul Rumkin — Thu, 22 Aug 2019 00:35:08 +0000

I'have been working on creation of web applications around 18 years of my life. Since the time when I started the Web has been changed from simple "Internet with services" to what we have today. And now developers working on a new web application should make hundreds of decisions and learn a lot of stuff. Lets' collect all requirements and things to do/know as a list to share experience.

Order of items doesn't represent importance.

Also it would be awesome if you'll share your experience to complete it or help with advise how to organize it better.

Production

Client requirements

HTML rendering/manipulation.
Navigation/history manipulation.
i18n.
Input/Output validation.
Input/Output infiltration.
Frontend delivery.
CSS methodology.
HTML semantic markup.
Accessibility attributes (ARIA).
OpenGraph metatags.
SearchEngines metatags.
OS specific metatags.
Manifest.json.
Service worker.
Versioning and migrations.
Transport encoding.
Minimal runtime support.
Synchronization strategy.
Usage statistics measurement.

Server requirements

HTML rendering/manipulation.
i18n.
Input/Output validation.
Input/Output infiltration.
HTTP API architecture.
Web Server/Balancer.
API Server.
HTTP Security management: CSP, CORS.
Authorization.
CI/CD.
Roles managements.
User notification/feedback.
Data Storage.
Logging.
Caching.
Services communication.
Client data encryption.
Process monitor.
Versioning and migration.
2FA.

Environment requirements

Code delivery.
Infrastructure deployment.
Access management.
System reboot strategy.
Instance communication encryption.

Development

Client requirements

JS compiler/transpiler.
CSS compiler.
Bundler.
Accessibility check.
Performance measure.
Tests.
Regression tests.
Debugger.

Server requirements

API Documentation.
Environment manipulation.
Stage deployment.
Tests.
Regression tests.
Debugger.

Environment requirements

Architecture description.
Key management.
Data storage organization.

This is the first iteration for the utter guide of a modern web developer knowledges. Hope it will help others to understand what to learn next and where to move on their carrier way.

Plant: HTTP2 and P2P web server for Node.js and browsers.

Paul Rumkin — Fri, 26 Jul 2019 15:51:41 +0000

Plant is a new WebAPI compatible HTTP2 web server. It's transport agnostic, highly modular, very secure by default and small: Plant's size is 8 KiB + optional node.js HTTP transport is 38 KiB (minified, gzipped) ; 74 KiB and 125 KiB respectively (unminified, ungzipped).

Plant was designed to use bleeding edge technologies, reduce complexity and make server portable. This portability gives you ability to write and test server-side APIs right in browser using only text editor. Plant has additional packages like http-adapter, router and bunch of http transports.

    const Plant = require('@plant/plant')
    const {createServer} = require('@plant/http')

    const plant = new Plant()

    plant.use('/greet', ({res}) => {
        res.body = 'Hello, World!'
    })

    createServer(plant)
    .listen(8080)

In-browser example

This is a very simple example of how it could work. It's just renders request into inlined iframe. It doesn't emulate browser. It's goal to show how to produce requests and emulate network connection with Plant.

Codesandbox · Preview

Details

HTTP/2-ready

Plant can push responses to the client using HTTP/2 resource push mechanics.

    plant.use(({res}) => {
        res.push('/js/index.js')
        res.push('/css/style.css')

        res.html('<!DOCTYPE html><html><head>...')
    }

WebAPI compatible

Objects like Request, Response, Headers and streams have the same or familiar interfaces that already exists in WebAPI. Plant's Request and Response are mirrored from the Client, that's why Request object has Response's method json().

    plant.use(({req, res}) => {
      req.url.pathname // "/"
      req.headers.get('content-type')
      res.headers.set('content-length', 5)
      res.body = 'Hello'
    })

    // Retrieve JSON with one single command
    plant.use('/echo', async ({req, res}) => {
      const body = await req.json()

      res.json(json)
    })

Plant is using ReadableStreams instead of Node streams. That's why it can work seamlessly in browser. For example in ServiceWorker.

Transport agnostic

Plant isn't tightly coupled with the Node.js http module server, instead Plant is using it as external dependency. You can easely create your own transport. That's why you able to deliver requests via anything: WebSockets, MessageChannel, raw TCP, WebRTC or even email (why not). It makes things extremely simple, especially your tests.

    const Plant = require('@plant/plant');
    const {createServer} = require('@plant/http2');

    const plant = new Plant();
    plant.use(({res, socket}) => {
      res.body = 'Hello, World!'
    })

    createServer(plant, {
      key: '...', 
      cert: '...',
    })
    .listen(443)

Create requests manually:

    const plant = new Plant()

    plant.use(({res}) => {
        res.body = 'Hi'
    })

    const url = new URL('http://localhost:8080/')

    // Create HTTP context's params
    const req = new Plant.Request({
      url,
    });
    const res = new Plant.Response({
      url,
    });

    // Request peer. Peer represents other side of connection.
    const peer = new Plant.Peer({
      uri: new Plant.URI({
        protocol: 'ws:',
        hostname: window.location.hostname,
        port: window.location.port,
      }),
    });

    // Create connection socket
    const socket = new Plant.Socket({
        peer,
        // If socket allows write upstream, then onPush method could be defined to handle pushes.
        // onPush should return Promise which resolves when response sending completes.
        onPush(response) {},
    });

    const handleRequest = plant.getHandler()

    handleRequest({req, res, socket})
    .then(() => {
        // Request handled. All requests (even faulty) should get there.
    }, (error) => {
        // Something went wrong
    })

Modular

Plant is trying to separate responsibility between modules and not to bloat own size. Everything, especially transport related, is moved out of server package and could be replaced with you own code.

Additional packages:

http	Node.js native http module transport
https	Node.js native https module transport
http2	Node.js native http2 module transport
https2	Node.js native http2 module with TLS transport
router	Router package

Secure by default

Plant is using the most strict Content-Security-Policy out of the box. And this is the only web server which bring security first and doesn't sacrifice it. This policy doesn't allow webpage to do anything, even run a single piece of JS. Default value of Content-Security-Policy header is very denial and should be used in production to protect client and server from accidents. Developers should specify exact permissions which their site requires.

    const plant = new Plant({
      csp: Plant.CSP.STRICT,
    })

For development should be used Plant.CSP.LOCAL policy.

Router example

const Plant = require('@plant/plant')
const Router = require('@plant/router')
const {createServer} = require('@plant/http')

// User API router
const router = new Router()

router.post('/', () => {})
router.get('/:id', () => {})
router.put('/:id', () => {})
router.delete('/:id', () => {})

plant.use('/api/users/*', router)

createServer(plant)
.listen(8080)

References

Github · NPM

P.S.

I'm an author of this package, so you could AMA. Also, notify me about grammatical errors. I would very appreciate it.

Trick how to replace path module with URL for path resolution

Paul Rumkin — Thu, 09 May 2019 01:17:20 +0000

This is a tiny trick which could be useful when you need to resolve paths and make it in a crossplatform way. This code has no dependencies what makes its' usage extremely simple and cheap. Also such code could migrate from Node.js to a browser without dependencies bundling: no browserify, rollup or whatever is needed.

The trick is in using file: protocol in URL constructor.

Well, let's take an example:

const path = require('path')

const absPath = path.resolve('/some/root', '../index.js')

And replace it with:

const absPath = new URL('../index.js', 'file:///some/root/').pathname

In both cases we receive the same absPath value:

/some/index.js

Note that built-in fs module accepts URLs as paths. Thus in cases when you need to use resolved path within the module, it's possible to just use a URL as argument:

const absPath = new URL('../../hello.txt', 'file:///project/root/')

fs.writeFileSync(absPath, 'Hello, World!')

DEV Community: Paul Rumkin

Less confusing defaults

By Default

Why?

How

Debug/Dev mode

Config

People shouldn't code

Smart web design. Part II: Customizable color theme in 10 minutes 🦜⏱

HSL vs RGB

Theme Colors

Advanced theming

Dark theme

Printable version

Theme switching

⚠️ Accessibility

Conclusion

Credits

What is web shell and why create it?

Short announcement

Motivation

References

observer0x / observer

The Observer browser

🍹🌟 CSS for fun

Example

Preview

Smart web design. Part I: light/dark mode favicon.

rumkin / favicon-switcher

Make favicon react on media queries

Listen for theme switch

Add icons

Switch the icon

Conclusion

Credits

What do you call people who don't code?

Creating JS web server without Node.js

Import

Create server

Making request

Creating context

POST requests

Conclusion

Repositories

rumkin / plant

🌳 JS web server charged with WebAPI and neat HTTP2 support

Plant

Features

Table of Contents

Install

Examples

Hello World

rumkin / plant-browser-demo

Nodeless web server demo

Plant Browser Demo

Usage

Dependencies

Structure overview

CopyBar: © for collaboration

Preview

Motivation

Specification

About section

Author section

Changelog section

Pros

Cons

Real life example

References

Ultimate web app requirements list

Production

Client requirements

Server requirements

Environment requirements

Development

Client requirements

Server requirements

Environment requirements

Plant: HTTP2 and P2P web server for Node.js and browsers.

In-browser example