docs/explains/faq.html.md

# FAQ


<!-- WARNING: THIS FILE WAS AUTOGENERATED! DO NOT EDIT! -->

## 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):

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

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

5.  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:

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

## Why the distinctive coding style?

FastHTML coding style is the [fastai coding
style](https://fast.ai/docs/dev/style.html).

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](https://www.answer.ai/posts/2024-08-03-fasthtml.html#why).

## Why use `import *`

First, through the use of the
[`__all__`](https://docs.python.org/3/tutorial/modules.html#importing-from-a-package)
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](https://fastht.ml/about/foundation) in ASGI and [tech
stack](https://fastht.ml/about/tech), 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](https://www.youtube.com/watch?v=9Q6sLbz37gk&ab_channel=JeremyHoward).
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](https://nbdev.fast.ai/) 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](https://nbdev.fast.ai/),
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.