FAQ

Why does my editor say that I have errors in my FastHTML code?

Many editors, including Visual Studio Code, use PyLance to provide error checking for Python. However, PyLance’s error checking is just a guess – it can’t actually know whether your code is correct or not. PyLance particularly struggles with FastHTML’s syntax, which leads to it often reporting false error messages in FastHTML projects.

To avoid these misleading error messages, it’s best to disable some PyLance error checking in your FastHTML projects. Here’s how to do it in Visual Studio Code (the same approach should also work in other editors based on vscode, such as Cursor and GitHub Codespaces):

Open your FastHTML project
Press Ctrl+Shift+P (or Cmd+Shift+P on Mac) to open the Command Palette
Type “Preferences: Open Workspace Settings (JSON)” and select it
In the JSON file that opens, add the following lines:

{
 "python.analysis.diagnosticSeverityOverrides": {
      "reportGeneralTypeIssues": "none",
      "reportOptionalMemberAccess": "none",
      "reportWildcardImportFromLibrary": "none",
      "reportRedeclaration": "none",
      "reportAttributeAccessIssue": "none",
      "reportInvalidTypeForm": "none",
      "reportAssignmentType": "none",
  }
}

Save the file

Even with PyLance diagnostics turned off, your FastHTML code will still run correctly. If you’re still seeing some false errors from PyLance, you can disable it entirely by adding this to your settings:

{
  "python.analysis.ignore": [  "*"  ]
}

Why the distinctive coding style?

FastHTML coding style is the fastai coding style.

If you are coming from a data science background the fastai coding style may already be your preferred style.

If you are coming from a PEP-8 background where the use of ruff is encouraged, there is a learning curve. However, once you get used to the fastai coding style you may discover yourself appreciating the concise nature of this style. It also encourages using more functional programming tooling, which is both productive and fun. Having said that, it’s entirely optional!

Why not JSX?

Many have asked! We think there’s no benefit… Python’s positional and kw args precisely 1:1 map already to html/xml children and attrs, so there’s no need for a new syntax.

We wrote some more thoughts on Why Python HTML components over Jinja2, Mako, or JSX here.

Why use `import *`

First, through the use of the __all__ attribute in our Python modules we control what actually gets imported. So there’s no risk of namespace pollution.

Second, our style lends itself to working in rather compact Jupyter notebooks and small Python modules. Hence we know about the source code whose libraries we import * from. This terseness means we can develop faster. We’re a small team, and any edge we can gain is important to us.

Third, for external libraries, be it core Python, SQLAlchemy, or other things we do tend to use explicit imports. In part to avoid namespace collisions, and also as reference to know where things are coming from.

We’ll finish by saying a lot of our users employ explicit imports. If that’s the path you want to take, we encourage the use of from fasthtml import common as fh. The acronym of fh makes it easy to recognize that a symbol is from the FastHTML library.

Can FastHTML be used for dashboards?

Yes it can. In fact, it excels at building dashboards. In addition to being great for building static dashboards, because of its foundation in ASGI and tech stack, FastHTML natively supports Websockets. That means using FastHTML we can create dashboards that autoupdate.

Why is FastHTML developed using notebooks?

Some people are under the impression that writing software in notebooks is bad.

Watch this video. We’ve used Jupyter notebooks exported via nbdev to write a wide range of “very serious” software projects over the last three years. This includes deep learning libraries, API clients, Python language extensions, terminal user interfaces, web frameworks, and more!

nbdev is a Jupyter-powered tool for writing software. Traditional programming environments throw away the result of your exploration in REPLs or notebooks. nbdev makes exploration an integral part of your workflow, all while promoting software engineering best practices.

Why not pyproject.toml for packaging?

FastHTML uses a setup.py module instead of a pyproject.toml file to configure itself for installation. The reason for this is pyproject.toml is not compatible with nbdev, which is what is used to write and build FastHTML.

The nbdev project spent around a year trying to move to pyproject.toml but there was insufficient functionality in the toml-based approach to complete the transition.

FAQ