Tcl/tk vs. the web

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.

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.

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.

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.

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.

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

"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?

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

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!

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

Hmm. See http://www.joelonsoftware.com/articles/Unicode.html

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.

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.

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

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

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.

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.

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

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.

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

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... (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.

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.

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.