npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

arthus

v0.0.14

Published

Yet another web framework.

Downloads

41

Readme

Arthus


A solid framework for building webapps.

Goals

  • All pieces should be separated and decoupled. Everything should be easily testable. That means no globals or anything.
  • A common pattern for controllers and helpers.
  • Framework should be separated from the actual app.
  • A great view layer.
  • Utilize streams where possible.
  • Fast, of course.
  • Include client-side framework.
  • Great support for rich JavaScript client applications.
  • Easy to profile and benchmark.
  • Centralized logging.
  • Follow Node patterns.
  • Great for developement.

Implementation

How to reach each of the goals.

Decoupled and separated parts

Different parts of the application will always require some kind of configuration. Instead of putting the configuration in a global location, each part gets the configuration passed on instantiation.

This can be done automatically by mapping the configuration section to the name of the object that needs variables.

Common pattern for object

By defining strict rules for how object constructors may look this can be generalized.

Framework separation

By writing the framework itself as a separate project we can further force ourselves to separate app logic from framework logic.

Great view layer

Each controller should return a view object. The view object is an object that defines how a page should be rendered. The framework will then inspect this object and render it and pass it to the browser.

During AJAX requests this view object can be serialized to JSON and sent to the browser for rendering on the client.

Utilize streams

The view layer could possibly be abstracted to work with streams in some way.

Client side framework

On the client side there should be a router layer that correctly invokes the controller for the current page.

The view objects from the server should be made to work on the client.

View objects defines a target for how it should be rendered. For incremental requests (like endless scrolling) they can set a selector and wether the result should be prepended or appended to the target.

The client side should support single page applications where supported by the browser. Pages should be stored in the DOM to make jumping back and forth a breeze.

Easy to profile

I believe this is achieved by writing clear, separated logic. Hooks and events will have to be provided for this kind of functionality to sit outside the app.

Centralized logging

The application should provide a simple way of doing logging. Runtime configurations can then be made to decide where the log messages are sent.

Follow Node patterns

Callbacks should all do error first. All that good jazz.

Great for dev

Keep convention over configuration for stuff like folder structure etc. Provide scaffolding methods for creating models, helpers, controllers etc.