8 ms·

Tcl/tk vs. the web

103 points by SFjulie1 11y ago

js8 11y ago
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.
- michaelwww 11y ago
  Google created Dart and is busy rewriting GWT apps in Dart [1]. Dart isn't perfect, but it does simplify the process of writing an app. [1] https://news.ycombinator.com/item?id=10865748 https://news.ycombinator.com/item?id=10865748
- tshadwell 11y ago
  I disagree. While I agree that web UI programming can undeniably be described as complex: a) JS, HTML and CSS have been designed to build more than "documents" for over 10 years. b) Contrary to the idea that these technologies lead to bad API, I see many high impact graphics toolkits moving to a CSS / HTML driven model even when the teams working on these toolkits are not majority web developers. Quick examples: GTK3 and Source 2. c) There are many Javascript frameworks that do not require deep knowledge of all three of these technologies to produce something. The vast majority of Javascript UI toolkits, for example jQuery UI aim to remove the need for in-depth knowledge of HTML and CSS to produce user interfaces. d) While I agree with you that there is no one true way to tie together these technologies, I think there are solid abstractions that tie HTML, Javascript and CSS together. I've been very excited about how terse and powerful d3 is for composing any kind of HTML/JS/CSS model.
- Pxtl 11y ago
  > 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 11y ago
    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 11y ago
      ExtJS is wicked heavy, though. And it's expensive: https://www.sencha.com/store/ https://www.sencha.com/store/
      - douche 11y ago
        Wow, I do not believe it was that pricey when we were using it.
        Pxtl 11y ago
        I'm guessing most people are just using the GPL license since AFAIK the GPL doesn't matter when you're hosting it yourself.
- mamcx 11y ago
  Is like a devolution for desktop. The best, by far, Delphi. Visual FoxPro was good too. VB meh Winforms meh * 2 WPF good, but tooooo hard After this, is a long fall from the climb. (I unsure how good is cocoa for desktops, never used it except for iOS)
skeeterbug 11y ago
>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 11y ago
  > 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.
  - tosseraccount 11y ago
    Good point. Microsoft, Google and Apple have little incentive to support a truly portable programming methodology.
  - petra 11y ago
    >> 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 ?
  - adrusi 11y ago
    Web applications get a lot less access than desktop applications do. Desktop apps get user privleges, so they can read all your files. Web apps are fully sandboxed. They can, now, access your files, but only after you click a scary banner that people are not used to seeing.
- 11y ago
AstroJetson 11y ago
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 11y ago
  ArsDigita Systems Journal was pretty interesting at the time.
  - AstroJetson 11y ago
    Sadly all the links to copies of it are dead.
lifeisstillgood 11y ago
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.
supercoder 11y ago
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.
- devil1591 11y ago
  XUL?
- tosseraccount 11y ago
  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 11y ago
    Too bad Sun screwed up with Java on the client. We could've had this 20 years ago.
    - vezzy-fnord 11y ago
      Or, speaking of Sun, something akin to NeWS: https://en.wikipedia.org/wiki/NeWS https://en.wikipedia.org/wiki/NeWS
      - icedchai 11y ago
        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.
  - SFjulie1 11y ago
    wish is downloadable for all these platforms. The reason why it was not "pushed" is SUN edited it. It was internally competing with java, like oak that seems interesting too. http://www.blinkenlights.com/classiccmp/javaorigin.html http://www.blinkenlights.com/classiccmp/javaorigin.html
deleted 11y ago
[deleted]
sloreti 11y ago
"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 11y ago
  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 11y ago
    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.
- bsder 11y ago
  The porn industry was way ahead of just about every technology for a long time. This goes back to CES and the Adult Entertainment Expo being in Vegas at the same time. For a long time, you got as good (or better) tech discussions over drinks with the porn techies than CES. This goes back to Betmax vs VHS. Laserdisc and DVD. Digital cameras. etc. The porn industry was always an early adopter. > can the rise of e-commerce, for example, be mainly attributed to porn? That's a different statement that I would answer "no" to. The rise of e-commerce was basically the credit card industry getting a piece of plastic into every single person's hand. You can't run e-commerce with cash.
- decasteve 11y ago
  Personal anecdote: I learned a lot of javascript tricks in the 1990s by using 'view source' on porn sites.
- dalke 11y ago
  Chatrooms as a concept are much older than the 1990s. I used chat rooms on the university's CDC mainframe in the late 1980s, with a system called 'confer.' People would sometimes create private rooms for online sex talk. Minitel supported chat rooms, including for adult chats ('messageries roses') in the 1980s. CompuServe an innumerable BBSes also had chat rooms in the 1980s. And the PLATO educational system had chat rooms in the 1970s. See https://en.wikipedia.org/wiki/Talkomatic https://en.wikipedia.org/wiki/Talkomatic . However, you limited this to chatrooms implemented with 'web technologies' - I can't address that specific topic.
mike_hearn 11y ago
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.
SwellJoe 11y ago
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 11y ago
  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.
brianpgordon 11y ago
> 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 11y ago
  That doesn't contradict anything stated.
bsder 11y ago
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 11y ago
  What was that transition about?
  - kevin_thibedeau 11y ago
    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.
networked 11y ago
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 11y ago
  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).
phantom_oracle 11y ago
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 11y ago
  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.
- Narishma 11y ago
  While it may be well explained, the example given is pretty bad as far as user interfaces go. It shouldn't have a 'Calculate' button, and instead just update as you type. That way there can't be any discrepancy between the two units at any time.
robertcope 11y ago
Vignette StoryServer Forever! Had some fun times writing Tcl in that system.
- AstroJetson 11y ago
  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 :-)
deleted 11y ago
[deleted]
zwetan 11y ago
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 11y ago
  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-toujours-raison.pdf http://inventin.lautre.net/livres/Schopenhauer-L-art-d-avoir...
awthistory 11y ago
> 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 11y ago
  He meant the dynamic layout model which was pioneered by Tk and adopted by AWT, GTK+, Qt, and others.
  - SFjulie1 11y ago
    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.
Pxtl 11y ago
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.
marcoperaza 11y ago
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-examples/kate/kate.html 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.
coulix 11y ago
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.
jrapdx3 11y ago
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.
nickpsecurity 11y ago
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 11y ago
  The ECMAScript 2015 spechttp://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 11y ago
    Here's the archived version of the project: https://web.archive.org/web/19990224200116/http://caesar.ics.uci.edu/juice/intro.html https://web.archive.org/web/19990224200116/http://caesar.ics... 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. :)
eggy 11y ago
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.

103 points by SFjulie1 11y ago

js8 11y ago

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.

michaelwww 11y ago
Google created Dart and is busy rewriting GWT apps in Dart [1]. Dart isn't perfect, but it does simplify the process of writing an app. [1] https://news.ycombinator.com/item?id=10865748 https://news.ycombinator.com/item?id=10865748
tshadwell 11y ago
I disagree. While I agree that web UI programming can undeniably be described as complex: a) JS, HTML and CSS have been designed to build more than "documents" for over 10 years. b) Contrary to the idea that these technologies lead to bad API, I see many high impact graphics toolkits moving to a CSS / HTML driven model even when the teams working on these toolkits are not majority web developers. Quick examples: GTK3 and Source 2. c) There are many Javascript frameworks that do not require deep knowledge of all three of these technologies to produce something. The vast majority of Javascript UI toolkits, for example jQuery UI aim to remove the need for in-depth knowledge of HTML and CSS to produce user interfaces. d) While I agree with you that there is no one true way to tie together these technologies, I think there are solid abstractions that tie HTML, Javascript and CSS together. I've been very excited about how terse and powerful d3 is for composing any kind of HTML/JS/CSS model.
Pxtl 11y ago
> 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 11y ago
  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 11y ago
    ExtJS is wicked heavy, though. And it's expensive: https://www.sencha.com/store/ https://www.sencha.com/store/
    - douche 11y ago
      Wow, I do not believe it was that pricey when we were using it.
      - Pxtl 11y ago
        I'm guessing most people are just using the GPL license since AFAIK the GPL doesn't matter when you're hosting it yourself.
mamcx 11y ago
Is like a devolution for desktop. The best, by far, Delphi. Visual FoxPro was good too. VB meh Winforms meh * 2 WPF good, but tooooo hard After this, is a long fall from the climb. (I unsure how good is cocoa for desktops, never used it except for iOS)

skeeterbug 11y ago

>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 11y ago
> 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.
- tosseraccount 11y ago
  Good point. Microsoft, Google and Apple have little incentive to support a truly portable programming methodology.
- petra 11y ago
  >> 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 ?
- adrusi 11y ago
  Web applications get a lot less access than desktop applications do. Desktop apps get user privleges, so they can read all your files. Web apps are fully sandboxed. They can, now, access your files, but only after you click a scary banner that people are not used to seeing.
11y ago

AstroJetson 11y ago

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 11y ago
ArsDigita Systems Journal was pretty interesting at the time.
- AstroJetson 11y ago
  Sadly all the links to copies of it are dead.

lifeisstillgood 11y ago

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.

supercoder 11y ago

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.

devil1591 11y ago
XUL?
tosseraccount 11y ago
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 11y ago
  Too bad Sun screwed up with Java on the client. We could've had this 20 years ago.
  - vezzy-fnord 11y ago
    Or, speaking of Sun, something akin to NeWS: https://en.wikipedia.org/wiki/NeWS https://en.wikipedia.org/wiki/NeWS
    - icedchai 11y ago
      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.
- SFjulie1 11y ago
  wish is downloadable for all these platforms. The reason why it was not "pushed" is SUN edited it. It was internally competing with java, like oak that seems interesting too. http://www.blinkenlights.com/classiccmp/javaorigin.html http://www.blinkenlights.com/classiccmp/javaorigin.html

deleted 11y ago

[deleted]

sloreti 11y ago

"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 11y ago
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 11y ago
  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.
bsder 11y ago
The porn industry was way ahead of just about every technology for a long time. This goes back to CES and the Adult Entertainment Expo being in Vegas at the same time. For a long time, you got as good (or better) tech discussions over drinks with the porn techies than CES. This goes back to Betmax vs VHS. Laserdisc and DVD. Digital cameras. etc. The porn industry was always an early adopter. > can the rise of e-commerce, for example, be mainly attributed to porn? That's a different statement that I would answer "no" to. The rise of e-commerce was basically the credit card industry getting a piece of plastic into every single person's hand. You can't run e-commerce with cash.
decasteve 11y ago
Personal anecdote: I learned a lot of javascript tricks in the 1990s by using 'view source' on porn sites.
dalke 11y ago
Chatrooms as a concept are much older than the 1990s. I used chat rooms on the university's CDC mainframe in the late 1980s, with a system called 'confer.' People would sometimes create private rooms for online sex talk. Minitel supported chat rooms, including for adult chats ('messageries roses') in the 1980s. CompuServe an innumerable BBSes also had chat rooms in the 1980s. And the PLATO educational system had chat rooms in the 1970s. See https://en.wikipedia.org/wiki/Talkomatic https://en.wikipedia.org/wiki/Talkomatic . However, you limited this to chatrooms implemented with 'web technologies' - I can't address that specific topic.

mike_hearn 11y ago

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.

SwellJoe 11y ago

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 11y ago
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.

brianpgordon 11y ago

> 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 11y ago
That doesn't contradict anything stated.

bsder 11y ago

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 11y ago
What was that transition about?
- kevin_thibedeau 11y ago
  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.

networked 11y ago

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 11y ago
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).

phantom_oracle 11y ago

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 11y ago
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.
Narishma 11y ago
While it may be well explained, the example given is pretty bad as far as user interfaces go. It shouldn't have a 'Calculate' button, and instead just update as you type. That way there can't be any discrepancy between the two units at any time.

robertcope 11y ago

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

AstroJetson 11y ago
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 :-)

deleted 11y ago

[deleted]

zwetan 11y ago

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 11y ago
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-toujours-raison.pdf http://inventin.lautre.net/livres/Schopenhauer-L-art-d-avoir...

awthistory 11y ago

> 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 11y ago
He meant the dynamic layout model which was pioneered by Tk and adopted by AWT, GTK+, Qt, and others.
- SFjulie1 11y ago
  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.

Pxtl 11y ago

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.

marcoperaza 11y ago

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-examples/kate/kate.html 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.

coulix 11y ago

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.

jrapdx3 11y ago

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.

nickpsecurity 11y ago

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 11y ago
The ECMAScript 2015 spechttp://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 11y ago
  Here's the archived version of the project: https://web.archive.org/web/19990224200116/http://caesar.ics.uci.edu/juice/intro.html https://web.archive.org/web/19990224200116/http://caesar.ics... 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. :)

eggy 11y ago

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.