
Wapp – a single-file web framework by the creator of SQLite - networked
https://wapp.tcl.tk
======
SwellJoe
One of the things I like about Mojolicious (a pretty full-featured async web
framework in Perl in an incredibly small amount of code) is that it has a Lite
variant, which allows building your whole app (routes, app functions, helper
functions, models, data, etc.) in a single file. Once you've gotten it off the
ground and the one small file starts to become one big file and it starts
feeling hairy, you switch to the full version, and break out all the pieces
into the usual directory layout (which can be done mostly automatically).

With regard to Wapp and some of the comments here disparaging Tcl...I've often
said Tcl gets much more hate than it deserves. For a lot of tasks, it's fine.
I wouldn't pick it for anything, but I understand why some folks still do.
And, I did build my current companies first website with Tcl
(OpenACS+AOLServer) more than a decade ago. It was more enjoyable to work with
than all of the PHP CMS-based sites I've built for the company since then. I
wouldn't rule it out, if there were some project I wanted to use that happened
to be written in Tcl.

~~~
nopacience
Mojolicious is fantastic! A plus is that its complete and has zero
dependencies on other modules. So its very quick to install.

It is good to see mojolicious be mentioned here at HN.

Mojolicious::Lite docs
[http://mojolicious.org/perldoc/Mojolicious/Lite#SYNOPSIS](http://mojolicious.org/perldoc/Mojolicious/Lite#SYNOPSIS)

~~~
f055
Mojolicious is beyond fantastic! I have a hard time touching anything else, as
every step of the way I think "damn this could have been so much easier with
mojo..."

------
symisc_devel
Note that Hipp before working on SQLite was a member of the TCL core board and
wrote something similar in the early 2001: A database-driven web server in a
self-contained executable named TWS where dynamic content is served from TCL.

[http://www.hwaci.com/sw/tws/index.html](http://www.hwaci.com/sw/tws/index.html)

------
sigzero
I love Tcl. The community is great. I watch the TCT (Tcl Core Team) and they
are very meticulous about what changes are being made in the language. Tcl has
added some things in the last few years as well. It has an object oriented
framework built in (TclOO) now, which most people don't know about. I think I
love it because it IS so different.

~~~
scruple
I really enjoyed working with it when I was writing Expect scripts (a long,
long time ago) and found myself writing some Tcl scripts alongside the Expect-
specific bits. What sorts of things are you using it for?

~~~
sigzero
I use it for sysadmin scripts and quick Tk gui utility stuff.

I have some ideas that I want to express in Tcl as well.

------
SlowBro
I like the idea but I’m not quite ready to learn a new language at the moment.
Can anyone recommend something similar in Python? The single-file part is less
important to me than the simple API. I’m a simple guy and my app will be
simple as well :-)

~~~
giancarlostoro
I'd say Flask will literally let you do that. Though CherryPy will as well if
you really want to. I usually don't do CherryPy that way unless I'm building
something small and contained enough. If you need templating I used Mako with
CherryPy as well. Just look at the "Hello World" for CherryPy you only need
that one file to run a web server, supports also running under WSGI and
hosting other applications that need WSGI hosting.

CherryPy:

[http://cherrypy.org/](http://cherrypy.org/)

Mako:

[http://www.makotemplates.org/](http://www.makotemplates.org/)

~~~
kakwa_
I've used cherrypy + mako in a few projects
([https://github.com/kakwa/dnscherry](https://github.com/kakwa/dnscherry) and
[https://github.com/kakwa/ldapcherry](https://github.com/kakwa/ldapcherry)).

It's quite easy to pick-up and does the job very well. It supports running
directly over http, but you can also run it in wsgi or fastcgi modes without
issues.

And it's also quite stable in term of APIs, my projects are now 4 years old,
and I didn't have any breaking changes in their API. It makes it quite easy to
support various distributions and version without kludges in the code to
handle different versions or having to bundle cherrypy with the application.
Even my monkey patches of the framework (slight change in the configuration
parser) are not breaking ^^.

~~~
giancarlostoro
My project is 1 year and 6 months old or so and yeah I've had a similar
experience. CherryPy is a great framework, and Mako not sure why I chose it
was also an equally great choice.

------
elvinyung
I hate to be the young whippersnapper parrotting buzzwords, but CGI is
theoretically supposed to lend itself really easily to deployment onto
serverless runtimes, right?

~~~
pjc50
CGI is one of those "simplest thing that could possibly work" tools: for every
request to a specific url path, the webserver runs an executable. Headers
passed in the environment, stdin and stdout plumbed to the network socket.

Back before serverless, we called it shared hosting.

Of course, fork() is not especially fast, so people came up with Fastcgi:
persist the process and let it handle multiple requests. Then people started
writing java where the startup time was prohibitive, and "application servers"
like Tomcat came into being.

~~~
sebcat
> Of course, fork() is not especially fast

fork itself is pretty fast, relatively speaking (unless you have a large
virtual address space and 4K pages or similar). fork+execve+process-runtime-
initialization is much slower.

On my X201 (anno 2010), with 10000 iterations, sequential fork+exit(0)-in-
child+wait takes:

    
    
        $ /usr/bin/time ./forkfest
                2,49 real         0,38 user         2,19 sys
    

while sequential fork+execve("/usr/bin/true",...)-in-child+wait takes:

    
    
        $ /usr/bin/time ./forkfest2
               10,99 real         3,10 user         7,94 sys
    

EDIT: also, My X201 is clocked at 1199 MHz (50%) for power saving reasons

~~~
dfox
On paged systems fork() is usually reasonably fast, but for CGI you do
fork()+exec() and while exec() is also reasonably fast, the stuff that the
happens in child process between it's start and entry into main() (ie. dynamic
linking, libc initialization) is somewhat on the slower side. (Not to mention
interpreter startup for interpreted languages)

------
tomcam
There are two versions, one with SQLite built in. The choice of TCL is super
interesting given its pedigree and could easily bring TCL back from its
quiescent state.

~~~
zwischenzug
I worked for the company that powered most of the world's (legitimate) online
gambling companies.

We had a C application server and used TCL as a business logic language. It
was a great fit for writing code fast and ease of maintenance.

You can hear me get a laugh when I say we use TCL in a talk I did here:

[https://www.youtube.com/watch?v=zVUPmmUU3yY](https://www.youtube.com/watch?v=zVUPmmUU3yY)

~~~
symisc_devel
Curious to know if this C application server is an open project or home
crafted closed code?

~~~
tpm
If the company in question is Openbet, it's closed source.

------
crncosta
The "everything is a string" mantra Will be back!?! The Millenial programmer
will try to comment out a line of code while the TCL interpreter Will insists
that is a validade code...

Come on guys, let some technologies dies peacefully, Ok? We don't want those
days back :)

~~~
klausnrooster
[http://antirez.com/articoli/tclmisunderstood.html](http://antirez.com/articoli/tclmisunderstood.html)

~~~
lomnakkus
I skimmed it _very_ quickly, but quite a bit of that 'defense' of Tcl seems to
be assuming that the problem with "everything is a string" is performance. It
isn't.

There are very good reasons that stringly typed programming is frowned upon
and 'performance' is very seldom one of them.

There's also seems to be a weird assumption that everthing-is-a-string means
that you don't have to think about types. It's actually the exact opposite
since now you don't have types for the compiler/runtime to help you to combine
values in well-defined ways.

(I realize that the thing was written ages ago and we/the author may have
learned a thing or two in the mean time.)

~~~
blacksqr
"What is Tcl"

[http://wiki.tcl.tk/299](http://wiki.tcl.tk/299)

~~~
lomnakkus
If you take issue with my post, then please be specific rather than throwing a
link to a big page at me.

Seriously, am I somehow supposed to divine your criticism of my post from that
link?

~~~
blacksqr
I'm sorry you interpreted my attempt to provide you with additional
information about why some people might see Tcl in a positive light as
criticism.

------
operatorequals
Our savior, save as from bloated package management, API inconsistencies and
Server-side Javascript.

Thank you!

------
nohope
I'm not a web developer but the times I tried to do some web development I
found all the things cool kids talked about overly complicated and fell back
to simple things like simple scripts on the server side and simple javascript
on the client side or even semi dynamic/static webpages.

I always found interesting how the Tcl community solve things, using simple
and powerful Tcl metaprogramming features (see beautiful examples on
wiki.tcl.tk).

I've done a couple of small business solutions in Tcl/Tk as desktop
applications. Now I feel more encouraged to try to develop new ones for the
web :-)

------
gnachman
Aolserver’s legacy lives on?

~~~
qatanah
naviserver! It's also being actively developed.

[https://bitbucket.org/naviserver/naviserver/commits/all](https://bitbucket.org/naviserver/naviserver/commits/all)

~~~
SlowBro
As an ex-AOL employee that makes me grin :-)

------
djhworld
There's a bug on the site, if you click "files" then scroll down and click one
of the links under "Further Information", you get a 404

~~~
SQLite
Thanks for reporting this. It is an interesting problem, that I'm not sure how
to solve (being yet early and I without coffee).

The README.md file is the homepage. It is intended to be displayed using the
URL
[https://wapp.tcl.tk/index.html/doc/trunk/README.md](https://wapp.tcl.tk/index.html/doc/trunk/README.md)
and the hyperlinks are relative to that URL. When you click on the File menu,
it shows the README.md file using a different URL -
[http://wapp.tcl.tk/index.html/dir?ci=tip](http://wapp.tcl.tk/index.html/dir?ci=tip)
\- and the hyperlinks don't work for that URL.

Perhaps the right solution is to rename the README.md file to something
different so that it is not displayed by default from the Files menu...

~~~
lazyjones
Perhaps a ``<base>`` tag (set to directory of the included file, i.e. that of
README.md) would suffice, since all other URLs on the page seem to be anchored
to the site's root?

------
speedplane
I get it that TCL is often the tool of choice with programmers that want to
build a simple UI that gets things done. It's easy and cross-platform.

But I have yet to see a beautiful TCL application. Web apps today can't just
work, they have to be user-friendly and familiar to a wide audience. Would
love to be proven wrong, but TCL does not seem to fit the bill.

~~~
StevePerkins
This is more or less a TCL version of Node's Express.

I'm not necessarily advocating for that... but what on earth does anyone's
choice of server-side framework have to do with the "user-friendliness" or
"familiarity" of the client-side UX?

You can serve up a bleeding edge Vue.js app from a PHP backend, or you could
serve up a bowl of jQuery spaghetti from Rust or whatever new language comes
out next week. These matters can sometimes be tangentially related, but are
largely orthogonal.

~~~
speedplane
I'm probably misreading this article. I've always known TCL as the quick-and-
dirty user interface of choice. I guess that's not the focus here.

~~~
StevePerkins
I honestly doubt you clicked the link at all before commenting, and likewise
doubt that you've actually had any first-hand exposure to Tcl in the past.

You SEEM to be referencing the "Tk" portion of Tcl/Tk. Tk is the _desktop_ GUI
framework that comes with most distributions of Tcl. But it has no apparent
relevance to this or any other Tcl-based _web_ framework.

This is kinda like dismissing a Java server-side web framework because Swing
is ugly, or dismissing C# on the web because you don't like WPF.

~~~
speedplane
Okay, happy to admit when I'm not fully informed, and this is one of those
times. I have interacted with TCL/TK and have made small programs with it, but
I have not used TCL directly in the past. In fact, did not even realize TCL
was a full language. When I read this article, given my background with
TCL/TK, I understood it to be a web framework using a weird desktop GUI...
which would be quite odd.

~~~
markroseman
Yes, when I did something like that nearly 20 years ago it was quite odd! But
turned out to be terribly useful for us at the time. (Google 'proxytk' if
you're curious)

