This guide shows some example usages of the HtmlRapier library. This library forms a good MVC foundation for modern web applications without going overboard.

Use the navbar on the left to visit the various sections. Either dive into the Reference guide or look at the individual demos.

HtmlRapier Goals

Instead of being just another javascript framework we try to think differently. For starters we don't even actually use javascript, but instead use typescript. These are the fundamental goals of the library and should help give you some insight into why things are done the way they are.

  • Total separation of html (view) and typescript (logic). This is the foundational requirement of this library. The current front-end trend is to combine these two together, however, we believe that the separation is good and the barriers this creates can actually help you write better, more reusable code.
  • Do not create another programming language. Most similar libraries fail here by adding extensions into html even for something as simple as an if statement. While this does not seem like a problem on the surface we believe lots of people can understand html and some custom attributes that are always static. Add logic, even just if statements and those people can no longer work on your code. All logic should go into typescript, that is the programming language, your html is a data file.
  • Use standard html. All custom attributes in HtmlRapier are properly prefixed with data-. This way HtmlRapier code is fully html5 compliant and will validate without the need for additional tools. This also prevents your markup from being totally locked into a particular system. It also makes it easier to embed HtmlRapier into another application if desired, since you will always be html compliant and the data-hr-whatever attributes should be unique.
  • Do not recreate the browser in javascript. So many of these frameworks want to also let you make mobile apps, so they include things like routing and view management so you can build "Single Page Applications." We believe that a browser written in c++ with a well defined, standardized api will always be superior to this, so we let the browser handle this lifecycle.  HtmlRapier works on a concept of a "View Program" where a particular view may be a farily rich application (think a crud table that lets you search and update items without refreshing the page), but we are not trying to shove the entire thing into one page. If we have another crud table for some other piece of data, that will be its own html endpoint with its own request and browser load.
  • No experimental features. We could improve some of our code using experimental features in typescript like decorators, however, we won't use anything not committed to by its original authors as stable.
  • Strongly Typed. HtmlRapier is strongly typed using Typescript to write code. We believe this increases the maintainability of the code by having better tooling and a compiler able to check for certain classes of errors.
  • Flat node_modules structure encouraged. By default npm and node want to use the exact version of a particular library when running. HtmlRapier is designed to be used with yarn and to use yarn install --flat to install dependencies. If something is broken it needs to be fixed, not just silently use some old version.
  • Use dependency injection. All controllers are created with a dependency injector. This makes configuration easier and provides more flexibility for the code you write.
  • Be Small. The file that is generated to make the demos was 99kb not minified or compressed with comments and newlines and everything. It also includes the library and the code for the demos. It is 32kb minified. Minified and gzipped it is 7kb. These sizes may change for your code, but overall the library is signifigantly smaller than even jQuery.
  • Be Reusable. If you write a controller to handle crud operations you should only have to do it once. This is more easily achieved since we have total separation of html and typescript. As long as the html defines the required controllers, toggles, views and forms it should be able to work. The core libray does not include the reusable parts, but check out HtmlRapier.TreeMenu or HtmlRapier.Widgets to see some examples of reusable components.
  • Be Modular. The core library is pretty focused. If we need to do a big add on for more functionality we are most likely to put it in a new library.

Hopefully that list will inform what you are seeing as you explore HtmlRapier. This library is already being used in several projects including the site you are looking at right now. This website was created with Edity McEditface a static html content engine with a git based back end. All of the editing capability you see in that program is powered by HtmlRapier.