
Tcl/tk vs. the web - SFjulie1
http://beauty-of-imagination.blogspot.com/2016/01/tcltk-vs-web-we-should-abandon-web.html
======
Pxtl
Yeah, I remember in 2000ish doing our first "real-life software application"
in my undergrad. Just a simple desktop UI for Amazon.

Everybody else used Java because that's all they knew, and it killed them. 3
man teams and they couldn't make it work.

I used Python with TkInter and it was a breeze. Not quite as easy as VB6
(Microsoft doesn't get enough credit for stealing Delphi's good ideas), but
they'd specifically said I couldn't use that. I had only 1 teammate and he
spent his whole time working on Amazon interface code - sending/receiving XML
and getting them into useful python objects.

Later on in my carreer I learned Web stacks and my brain hurt... but that
might be because I started with the horrible abomination of ASP.Net webforms.

HTML+CSS+Javascript only manages to be a functional application framework
thanks to the weight of the _entire computing industry_. The _trillions(?)_
spent on this bullcrap is just silly. The wrong platform won because it was
the lowest common denominator - everybody already had a browser.

------
js8
Web UI programming is complex compared to _anything_ , I mean any GUI toolkit
from the late 90s (my favorite is Qt).

The problem is that the people who design JS frameworks insist that you have
to be able to use JS, HTML, CSS. This leads to bad API, you reuse something
that was designed for documents for applications, and no one really knows how
to map these different things properly.

GWT could have been a viable route, but it sadly didn't catch on that much.

~~~
Pxtl
> The problem is that the people who design JS frameworks insist that you have
> to be able to use JS, HTML, CSS. This leads to bad API, you reuse something
> that was designed for documents for applications, and no one really knows
> how to map these different things properly.

ExtJS. An old, mature JS framework designed for desktop-style apps on the
browser. ExtJS code doesn't look like web code at all - no mentions of DOM and
styling and stuff like that. All about widgets and data-binding, like making a
desktop app. It's not perfect - being almost as old as JQuery, it has some
flaws that would have been avoided in newer frameworks. But it's there and I
use it professionally.

The problem, of course, is "why does our webapp look like a desktop
application but with non-native widgets?"

Now everybody _expects_ the web to be all designer-y. Even for a line-of-
business app. It's on the web, it should look webby.

~~~
douche
ExtJS is wicked heavy, though. We used it for a while (they have a really
slick table component) but it was such a world unto itself, plus being like
10MB with all the required themeing and images, that we bailed and went to a
jQuery-based component instead.

~~~
qohen
_ExtJS is wicked heavy, though._

And it's expensive:

[https://www.sencha.com/store/](https://www.sencha.com/store/)

~~~
douche
Wow, I do not believe it was that pricey when we were using it.

~~~
Pxtl
I'm guessing most people are just using the GPL license since AFAIK the GPL
doesn't matter when you're hosting it yourself.

------
jrapdx3
Highly unusual seeing the _3rd_ article on HN about Tcl/Tk in the last few
days. Ordinarily it's been pretty much a neglected language which is kind of a
shame because it can be highly capable and adaptable.

Like the author, I learned Tcl/Tk back in the '90s. I needed to have certain
tools for running my business and there weren't affordable off-the-shelf apps
available. Especially so for Linux which we were starting to use. There were
adequate C GUI libs at the time, but writing, for example, a networked
scheduling app in C was a complex, daunting task.

Then I discovered Tcl/Tk, I was amazed how relatively simple it was to create
the UI, connect the logic and maintain the "separation of concerns" between
them. Also the Tcl event loop model made writing network backend database,
server and client interaction fairly straightforward. Client/server
connections were made persistent, sort of reminiscent of the websocket
protocol.

I guess these experiences echo the article's idea, that Tcl/Tk anticipated
some of the facilities the "web stack" is trying to provide near 20 years
later. We know Tcl doesn't have the appeal of other languages, perhaps many
consider Tcl to be "weird", and it may well be. However, a case could be made
that the thousands of extant web frameworks and other current-day "tooling"
are no less peculiar, and certainly don't offer the versatility and staying
power that Tcl/Tk has shown.

Of course we can't undo history, but I've often wondered how the web would
look today if way back when Tcl had been chosen as the browser language. Maybe
what the author of the article was trying to do was ask that sort of question.

------
SwellJoe
I've got nothing against Tcl/Tk. I built my current company's first website
with OpenACS and AOLServer, and everything was built in Tcl. I have no major
complaints about the language or about Tk (I've also built some trinkets with
Python+Tk and Perl+Tk over the years). But...that ship has sailed, about 15
years ago.

And, I can't argue with the "JavaScript burnout" problem. I'm currently trying
to sort out the front end for our UI rewrite, considering things like React.
There's an incredible wordsoup of jargon and new tools to learn, no
established best practices (we're in the wild west phase of web UI
development, with a thousand competing and occasionally interacting
technologies), and no unified way to build a user interface in
HTML+JavaScript.

I mean, I can understand someone looking at how bloody simple it is to put a
window with a widget on the screen with Tcl/Tk (or almost any other reasonable
UI toolkit, for that matter), vs. the huge pile of crud one has to install and
poke at to do the same for a browser in a modern way (i.e. without reloading
the page every time something changes state, for example), and throwing their
hands in the air and saying, "Fuck this! I'm going back to...whatever I was
using before." Things have gotten so baroque in the web development space, it
can seem impossible to look at a new project and have any clue what's going on
(because you have to know all of the frameworks and libraries and transpilers
it uses, the tooling it uses like Webpack, SASS/LESS, etc., plus the basics of
HTML5, CSS, and JavaScript).

And, obviously, I can't tell anyone not to give up on the web and build
traditional desktop applications. But, if you want your software to be _used_
by real people, it's almost always going to need to be on the web. And, that
will become more true over time, rather than less true.

I find desktop apps charming, but even my stubbornness has run its course. I
haven't started seriously using a new desktop application in maybe five years
(Mixxx DJ software is the most recent thing I can think of). Even for things
that a desktop app ought to do better...like email, there are now better web
applications for the task, and I find myself using the web more than the
desktop programs for almost everything.

~~~
amelius
The problem is that W3C insists to make the web simple for everybody, instead
of useful for experienced developers.

This is the wrong approach, imho, because when you target developers first,
basic economics tells us that they will do the work for you to make the web
simple for everybody else.

~~~
kevin_thibedeau
And so they went with a language without so much as a standard string API.

------
networked
Tcl is a functional programming language in the sense that every value in Tcl
is an immutable string (the legacy arrays excluded) and as a result you are
able and encouraged to build Tcl applications mostly out of pure functions.
Where mutability comes into the picture is through the state maintained by Tcl
extensions written in C, such as SQLite, TclCurl, TclOO (the standard object
system) and Tk (the GUI toolkit). You might use the same immutable strings as
handles for the objects maintained by these extensions but the internal state
of the objects is mutated. Besides that mutability there is (immutable string-
based) state in the form of global/namespace-local variables that you can
reassign.

~~~
SFjulie1
Ok, I was a tad lacking of precision.

 _Tk_ not tcl because it is event driven relies heavily on a mutable called
time/clock.

And there also always states every time you do asynchronuous to handle the
status of things (connection, ....). And since you can manipulate them, you
have to deal with states. And you cannot "snapshot them". Basically modern web
is just using browsers like an asynchronous GUI it was my thesis. And indeed,
in other contexts tcl can map to functional paradigm.

I really don't care in fact of FP. At one point it is like monads, string
theory & a lot of very interesting theories that are very enjoyable to learn
but for which the cognitive burden to respect the purity of the theory
outweigh for my pooor brain in real life application.

It reminds me of my teachers being pissed when I could solve their problem
faster with an easier personal ways when I could use my tools. And even more
pissed when I was framed to use their tools and failing. They thought I was
doing it on purpose like other kids ... to shame them publicly. No I must be
kuku.

What protects the international conventions on Intellectual Property anyway?
The originality of the way of solving a problem.

So I always thought that making myself my own tools and thinking was a
necessary risk in order to be truly innovative one day.

That is also why I dropped the consulting bullshit to test my theories in the
grunt job.

I also do a lot of other stuff like testing my greatfathers ratio of KNOP in
fertilizer, music, knitting, cycling 50km/h in the city, cider, bread,
emulsions (béarnaise, béchamel, vinaigrette...) to challenge my knowledge.

Stuff that must work. And I pride myself in some successes. (at the price of a
lot of failures).

------
nickpsecurity
I counter with the example of Juice Oberon project. Oberon is type-safe,
memory-safe, compiles insanely fast, and executes fast. Juice turned it into a
Java and JS substitute. Sent compressed AST's to reduce bandwith, too. Adding
macro's and 4GL-like commands for browser-specific stuff would have way better
results than Tcl.

Another better road not traveled...

~~~
cylinder714
The ECMAScript 2015 spec[http://www.ecma-
international.org/ecma-262/6.0/index.html](http://www.ecma-
international.org/ecma-262/6.0/index.html)) runs 566 pages, whereas the
Oberon-07 spec
([http://people.inf.ethz.ch/wirth/Oberon/index.html](http://people.inf.ethz.ch/wirth/Oberon/index.html))
is _16-1 /2 pages_. Yes, I'm interested.

~~~
nickpsecurity
Here's the archived version of the project:

[https://web.archive.org/web/19990224200116/http://caesar.ics...](https://web.archive.org/web/19990224200116/http://caesar.ics.uci.edu/juice/intro.html)

Found this accidentally in the progress:

[https://github.com/berkus/Juice](https://github.com/berkus/Juice)

Feel free to dig in to see if it's the actual source or whatever. However, it
was an academic prototype thrown together. I won't expect much. I'm
envisioning pro's from Mozilla etc putting a tenth of effort into it they put
into Javascript. The results would've been native speed while quite safe. :)

------
sloreti
"Porn industry in the 1990s invented : chatrooms, e-commerce with visa card,
dynamic contents...."

Can someone knowledgable of the history of the web confirm this? I assumed the
industry played a major role in the development of some web technologies, but
can the rise of e-commerce, for example, be mainly attributed to porn?

~~~
mixmastamyk
They were an early pioneer, yes, inventor is probably too strong a word.

Chatrooms were around much earlier. Perhaps he means on a website?

~~~
SFjulie1
on a web site indeed. I saw the first "private chatrooms" in 1998 based on
ugly PHP/js hacks. And it was the pornmaster who showed to me how to do them.

------
phantom_oracle
I just looked at the TkDocs, and wow! it is reasonably sane and one should be
able to immediately understand the code in their language of choice:

[http://www.tkdocs.com/tutorial/firstexample.html](http://www.tkdocs.com/tutorial/firstexample.html)

Desktop apps, especially the Linux-kind, feel very retro. You know you're
appealing/building apps for a very niche subset of humanity, but that someone
on the internet, somewhere, will say:

    
    
       Wow! I can't believe there is a Linux desktop app for this! I just installed Linux and cannot believe how simple it is or how many options I have
    

Desktop apps are dead, long live the desktop app!

~~~
wallacoloo
I just can't figure this one out.

> I just looked at the TkDocs, and wow! it is reasonably sane and one should
> be able to immediately understand the code in their language of choice.

This statement seems serious, and reasonable enough. On the one hand, the
pencil-drawn UI schematics are completely out of place and not very helpful.
On the other hand, the Tk examples _are_ given in 4 languages, and do seem
pretty reasonable.

But everything else in your post seems sarcastic. And then finally,

> Desktop apps are dead, long live the desktop app!

I'm hopelessly lost. I feel like I'm back in English class doing one of those
convoluted assignments wherein I'm told to analyse the author's intent,
symbolism, and the meaning behind their motifs, etc. Those assignments always
kicked my ass.

------
brianpgordon
> By default, strings have no bytes ordering problems. They are portable.

Hmm. See
[http://www.joelonsoftware.com/articles/Unicode.html](http://www.joelonsoftware.com/articles/Unicode.html)

~~~
ori_b
That doesn't contradict anything stated.

------
bsder
Tcl also went through a gigantically wrenching transition (from Tcl 7 to Tcl
8) right at the time when the web was undergoing its exponential growth.

In addition, the explosion of memory and CPU made the design choices of Tcl
look suboptimal. It is no coincidence that the languages which most people are
using now (Javascript, Python, Ruby, etc.) made very different design
tradeoffs than the ones that preceded this era.

~~~
vram22
What was that transition about?

~~~
kevin_thibedeau
Changing the core to a byte code interpreter that uses objects rather than
strings everywhere as well as adding Unicode support plus porting some of the
extensions used for Tk into the mainline Tcl interpreter.

------
AstroJetson
Back in the late 90's we built a pretty comprehensive financial site based on
a TCL server. All the pages were backed by TCL code that we could pull out of
a database on the fly. It was based on the work done around AOL server at the
time.

It was pretty cool to read "Philip and Alex's Guide to Web Publishing", he had
done lots of the same things we had.

~~~
philippeback
ArsDigita Systems Journal was pretty interesting at the time.

~~~
AstroJetson
Sadly all the links to copies of it are dead.

------
zwetan
well .. all this come as pretty smug with a tad of superiority complex.

Not surprised here, I'm French and saw that quite a lot from a crowd who think
because they learned programming "the scientific way", anyone else is a hack
or an amateur at best.

Man got so much disdain ...

"I had to deal with poorly coded rewrite of ..."

"Because of hype and stupid sysadmins ..."

"because in the 2000 good coders were hard to find"

"You cannot self teach it yourself."

"one man armies self taught and not software engineers"

"less expensive to hire self taught programmers than students that had loans
to pay"

Do I understand all that right ?

best innovation on the web come from the porn industry ? self taught
programming is bad, java engineers are bad, sysadmins are stupids and everyone
should move to TCL/TK ?

some people really do have an enormous ego :)

~~~
SFjulie1
Indeed. :P

But it is not my ego that is big, it is my life. Being bankrupted, scamed into
weired business practices, fired for using CSS in a web app because CSS stands
for Cross Site Scripting while I just shown that letting the user store non
stripped HTML in a web page for a "highly sensitive" application was weired
forges the ego.

Btw, I am self taught mostly. I come from a physic university. But, I did have
important lessons (heap, stacks, linked lists, FIFO, LIFO, ana num, matrices
and LU...), and more importantly I have been mentored and have learn by
apprenticeship mostly and not in the real "academic" process.

Not every thing can be taught by yourself. And the school might not be best
place to learn computer programming. But we sure do need the others to
improve. My ego leaves a lot of room for the others because I need the others
too.

Simple no?

By the way, what you did is called an adhominem arguments according to
Schopenhauer.

I guess it is on Gutenberg project. A must read.

[http://inventin.lautre.net/livres/Schopenhauer-L-art-d-
avoir...](http://inventin.lautre.net/livres/Schopenhauer-L-art-d-avoir-
toujours-raison.pdf)

------
awthistory
> Java awt is a descendant of Tk (oak).

That's not accurate. Tk did predate Java by a few years and Tk was fairly well
known in the X-Windows/Suns/Unix workstation circles so it may have had a
slight influence but AWT never shared any code with Tk.

~~~
kevin_thibedeau
He meant the dynamic layout model which was pioneered by Tk and adopted by
AWT, GTK+, Qt, and others.

~~~
SFjulie1
Dont try to save me, he got me. He as a point. In fact thank you for saying
exactly what I meant I feel relieved : you also have a point.

How is it possible you are both right? I made a shortcut that was incorrect.

That is the reason why I often include myself in the idiots I am denouncing.
Because I make mistakes too.

------
mike_hearn
TCL/TK wasn't an especially pleasant toolkit for users or developers, although
compared to the HTML5 stack building a house out of matchsticks will seem
convenient and pleasant. There were much better toolkits even back then:
Delphi's component library was my favourite.

IMHO the web is one of the biggest downgrades to app development that has ever
happened, in so many ways. And what's really sad is that so many developers
joined the industry since around 2000 that it feels like the majority of
programmers have never written anything _but_ web apps, they literally have
never used a professional, well designed UI toolkit! The closest many people
have got to that is doing mobile development.

One project I occasionally daydream about doing (if/when I get spare time
again), is trying again to make Java applets work, with the following fairly
major changes:

1) No browser dependencies beyond a URL handler. The 'app browser' would
register some sort of app:// URL handler and that's the only way to invoke
apps from the browser.

2) Core app browser uses the same auto-update tech as Chrome. Silent,
invisible, in the background, continuous.

3) Old cruft like AWT that exposes huge amounts of native code (i.e.
exploitable code) would be removed. Sooooo many Java exploits boiled down to
exploiting native libraries shipped along side the JVM, but these days you can
do most stuff without needing support from C/C++ libraries.

4) App code is compressed, reordered to be streamable and then app servers
stream everything via HTTP/2 with server push. The average web page is now 2mb
in size so with some careful design you could make apps written in this way
start faster than actual web apps can, especially as you'd remove a lot of
overhead that's useful for documents but not so much for apps.

5) Apps would also update themselves in the same way as Chrome does. You could
mark apps as "check for update on every launch" but if you don't, apps will
start even when offline.

6) There'd be a universal, reference app server that accepts sandboxed app
uploads and provides access to a few useful services like a Postgres. By
default it'd let anyone upload any app to any server. Again, the server would
update in exactly the same way as Chrome (no apt-get required).

7) Things like CSS would be replaced by type safe DSLs that compile down to
bytecode.

There are a bunch of other improvements I'd like to put into my ideal app
platform, but I can't list them all here.

The above might sound completely crazy given Java's track record of exploits,
but you have to consider a few things.

One is that HotSpot got a LOT more secure in recent years due to heavy
investment in security. When the last zero day was discovered (a bug in a
Microsoft DLL shipped for AWT), over two and a half years had passed between
that and the previous zero day. Java has reached the same point that browsers
have: the security bugs are almost all being discovered by whitehats.
Unfortunately browser makers had decided to kill off applets entirely by this
point and users had learned to hate them, partly because of the obnoxious
update process on Windows (Ask Toolbars and such). But the underlying core
tech isn't actually that bad anymore. Compare the list of CVEs between HotSpot
and Firefox and it doesn't look so different.

Another reason for Java's poor reputation is that it historically exposed far
more functionality to applets than HTML did to web pages. But the HTML5 effort
has been changing this and by now, the modern web platform exposes a vast and
rapidly increasing surface area to web pages. Massive new chunks of
functionality like video chat or OpenGL can appear almost overnight, it seems.
But all of this stuff is implemented in C++ and suffers the usual litany of
bugs associated with that language. Whereas the trend in the Java world has
been the opposite: new functionality is often mostly or entirely implemented
in Java itself, and so cannot be buffer-overflowed or double-freed.

Finally, the Java team are still making major architectural improvements that
should reduce security holes even further, in particular, the Jigsaw effort
supposedly would have avoided about a third of all the security bugs in Java
in recent years.

Given that any large app platform that supports mobile code will have security
bugs, I feel it's really more about how you manage them than a simple "web
rocks, java sucks" world view. And the advantage of using a platform actually
designed for apps instead of documents should be obvious.

~~~
Roboprog
Maybe a library that works like "AWT for Javascript"???

It probably already exists, but I don't know what it is. Something that
completely hides all the CSS ugliness

------
lifeisstillgood
tl;dr why aren't we running tk instead of browsers and viewing web pages on
top of a sane display canvas?

I think there is a point but mostly, I cannot imagine how we could have got
here differently. Maybe pmarca could have written a quick tcl script and
solved everything but ... Nah.

They tried a long time to not give a real canvas on top of a web browser, for
perfectly good reasons. By the time html5 demanded a real canvas, well JS had
won and everyone else was also ran.

------
skeeterbug
>But why are we using web in the first place?

>Because of hype and stupid sysadmins that blocked everything but HTTP
protocol (Deep Packet Inspection might block TCP:80 because people are scared
it could be an SSH server with tunneling enabled on the other side).

So we are required to install an app locally for everything and give access to
our entire system? No thanks.

~~~
js8
> So we are required to install an app locally for everything and give access
> to our entire system?

And why not? [https://xkcd.com/1200/](https://xkcd.com/1200/)

The truth is, for systems with just one typical user, it doesn't matter that
much whether applications have root access or not.

Look at Android or iOS applications - they install locally yet can access the
internet without much hassle. There is no excuse this cannot be done on the
desktop, too. The only real obstacle to that is insistence of various
companies to own the platform.

~~~
petra
>> is insistence of various companies to own the platform.

Well , not everything in tech is 100% determined by powerful companies. For
example python don't owe it's success to powerful friends. It was mostly
bottoms-up.

So maybe there's a strategy that could succseed in creating a better app
platform , just using developer support ?

------
eggy
I specifically started playing with Elm for this reason. It eventually becomes
HTML, JavaScript and CSS. I have not made anything big with it, but it does
allow you to hook into the usual JS suspects. The 'Time-traveling' debugger
and FRP capabilities make it a lot of fun, and keep you insulated from the
HTML-JS-CSS soup.

------
robertcope
Vignette StoryServer Forever! Had some fun times writing Tcl in that system.

~~~
AstroJetson
Yikes I had forgotten all about StoryServer. What a mess that was. The system
level API's were written by someone that was a C programmer, trying to get TCL
to cleanly talk was a real bear. Glad RobertCope you have better memories than
I do :-)

------
marcoperaza
The web is controlled by players who have shifting agendas. There's always at
least one player that wants to advance the web, because they are doing poorly
in the native OS market (or some portion of it). There's always at least one
other that wants to keep web technology stagnant, because they are doing well
in the native OS market. These players switch roles as the market evolves. The
power in the web is that once you have a critical mass of content that
requires a certain feature, browser makers have very strong incentives to
support that feature, and very strong disincentives to not support it (such as
undermining their market share, and thus control over future web evolution).
Which means that progress is pretty much monotonic, but also very path-
dependent. Hence why the technology is often such an awkward fit for its
current uses. It also means that the web api will always lag behind the
richest native apis, but that's how all technology works, and must work if
there is to be progress; the cutting-edge is always non-standard
experimentation.

In terms of controlling presentation, WebAssembly, HTML canvas, and WebGL are
conspiring to bust the monopoly of the Javascript/HTML/DOM model. Look at
this: [http://vps2.etotheipiplusone.com:30176/redmine/emscripten-
qt...](http://vps2.etotheipiplusone.com:30176/redmine/emscripten-qt-
examples/kate/kate.html) (takes a while to load, worked on Chrome for me
despite warning). It's a full blown Qt app running in the web browser. There's
obviously a lot of kinks to sort out, like the massive loading times, but it's
not that far from being viable.

WebAssembly and the ecosystem that will grow around it (to some extent, this
already happened with asm.js and Emscripten) are game-changers for the web
because they shift the burden, i.e. developing for an inferior platform
designed by a committee full of bad-faith actors, from every single app
developer to the compiler and core-library developers. Of course, this will
lead to inefficiencies like drawing with Qt inside a VM inside a web browser
that's itself drawn using Qt. And so smart browser vendors will figure out how
to optimize, thus some web apps will work much better on their browsers. This
will force the less-eager browser vendors to improve the performance too. And
so the cycle continues... This is actually exactly how WebAssembly came about
in the first place. Asm.js provided a solution that worked on all browsers by
brutally and inefficiently repurposing existing technology, but that could be
heavily optimized by enlightened browsers. One browser vendor gained a
temporary advantage by doing this, and thus forced everyone else's hands. A
binary format was just the next step.

I suspect that this dynamic is a general phenomenon that causes technology to
naturally trend toward standardization and therefore openness.

------
coulix
Granted the current state of JS is a bit of a joke. That said spend a week or
two on understanding web components, virtual dom, immutable.js, webpack, babel
and its plugins and you are good to go.

------
supercoder
Thing is, HTML is a really fantastic and powerful way of describing documents.

But it's absolutely terrible at describing UIs.

I know it'll never happen, but if we had a layer created specifically to deal
with UI then the web could have a chance at becoming a great software
platform.

~~~
tosseraccount
No one has solved the lean,powerful, portable GUI API problem. It'd be nice to
write a program that can distributed as a single file for the target OS: iOS,
Android, Linux, Windows, OSX, DOM. Though not very powerful and very slow,
javascript is pretty easy.

~~~
icedchai
Too bad Sun screwed up with Java on the client. We could've had this 20 years
ago.

~~~
vezzy-fnord
Or, speaking of Sun, something akin to NeWS:
[https://en.wikipedia.org/wiki/NeWS](https://en.wikipedia.org/wiki/NeWS)

~~~
icedchai
NeWS looks interesting, though unfortunately a little before my time. My first
experience with SunOS was SunOS 4.x on a Sun-3 (3/60, I think?) in the early
90's, and by that time everything was X-based, I believe.

