Bytesmith and Hammer

Dear friends and fellow codesmiths,

This is still very much in beta:

Content on Bytesmith is still pretty sparse, but I’m working on it :blush:.

Feedback of any kind will be much appreciated.




It looks interesting, but I don’t understand its position in Anvil development.

Would you use this to avoid form building in the IDE? I’m not sure I get it (though I am a little thick as anyone will tell you).

1 Like

Hi David,

Thanks for your question. It’s not at all thick. If anything, your question is a consequence of me not explaining myself properly.

My motivation behind the Hammer project is something like this:

  • I’d like to use Python in the browser instead of JavaScript – and use Python “as if browsers understood Python as they do JavaScript”. And I’d like to be able to directly work with the full spectrum of HTML elements and browser APIs - as if I was working in vanilla JS (but from Python).
  • At the same time, I’d like to benefit from elegant client-server communication, integrated database, easy deployment, and integrated services.

Consider all the hype that PyScript has received. What is that all about? It’s (primarily) about client-side Python. But with Anvil, we’ve already got that! As a sworn Anvil fan, the spotlight on PyScript almost hurt my feelings :blush: (yeah, yeah, I know PyScript is also about WASM and packages in the browser, but that aside…).

It’s just that with standard Anvil, you not only buy into “Python in the browser”, but also a certain development approach and level of abstraction. This approach is not so much about the Anvil online IDE per se (a great IDE!) but concerns the abstraction around HTML elements that the HtmlTemplate class and the Anvil component library provide (which in turn is tied to drag-and-drop development – and therefore indirectly to the Anvil online IDE).

Please, please, do not get me wrong. I’m not in any way criticizing the current Anvil value proposition (as if…). In fact, I think it’s brilliant! But I personally hypothesize that Anvil also holds the key (and indeed already has the capabilities) to unlock another value proposition targeting a different (perhaps much larger) segment: “Python in the browser as a direct replacement for JavaScript – coupled with some client-server, DevOps and services goodies (but not more than that)”. Anyway, I could be dead wrong. And as stated, hammer is a personal experiment – not a dogmatic mission :blush:. And yes, I do feel a little bit like a spoiled kid: I’ve gotten the full premium package – and here I am, peeling of precious layers towards a more primitive version.

Finally, about its place in Anvil development: I do consider the Hammer package “very Anvil”. It’s just anvil.js instead of anvil.

All the best,



I shall be following your web blog for sure, because it looks interesting. But I can’t see the benefit for me personally, largely because (unless I have again misunderstood) it looks like it might require me to do the two things I really don’t want to do - use more than one language (in this case html & css) and get too close to the nuts & bolts of how webpages work.

You see, I’m not really a programmer. I build solutions for paying customers’ problems. The faster I build them, the more likely I am to be rehired. Nothing - nothing - has allowed me to build faster than Anvil. It doesn’t force me to be a good programmer, but it makes me look like one :slight_smile: A big part of that is the designer and the abstraction it provides from “webby-stuff”.

It’s horses for courses, I guess. Good luck with it, though!


We’re on the same page: Unless you have an appetite for throwing yourself at the whole HTML, CSS and browser API pony and dog show, sticking with “Anvil standard” is certainly the best choice! As you correctly infer, the premise for my little experiment really is: Learn the all the basic web dev technologies – and then replace JavaScript with Python.