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.
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.
> 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.
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.
>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.
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.
>> 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 ?
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.
Your session in your OS is already protected by credentials (passwords, tokens).
The illusion of security given by inputing and multiplying passwords might not beat having a central point of authentication handled by the OS. EDIT: and you have system accountability for free.
User sessions and applications are to be already limited by the OS why redo it?
And like it or not a browser is a millions sloc application that have access to everything potentially. You just trust mozilla, google, apple to not access everything. But have you audited their codebase?
Depends on your system. Linux had SELinux / AppArmor / general LSM for years. Android uses different user for each app. Windows is just starting to catch up with sandboxes in the latest version.
Since this is about Tcl, there is a SafeTcl subset that was specifically designed for running untrusted code when there was hope that it might become a standard web scripting language. It eliminates all commands that can alter system resources and is a truly safe sandbox. You can still use it today by creating isolated sub-interpreters with an option to use the safe subset.
You mean instead of being able to download and run something natively at my convenience, I have to run it on (barf) JavaScript in the browser? I have to submit to being tracked everywhere I go online, and send my data to a central "cloud" where advertisers can profit from it freely without paying me royalties?
That's not the point. 90%+ of the webpages I visit are essentially static documents. They can easily be treated as data, not code; even the UI description could be omitted and reasonably reconstructed from the actual page content.
This webpage? It consists of a title and a link to an article, followed by a series of comment objects. Each comment contains some text, an associated author, a timestamp, and possibly a set of child comments.
This exact arrangement of data can be found all across the web. If you take any blog article, it consists of this same layout, only instead of a link to the article, you have a bunch of text and/or pictures.
It arguably took more work to design a product (the web browser) that can parse html, apply CSS styling, parse and execute Javascript, and tie all those pieces together with the DOM than it would have been to just have webservers pass a loosely annotated version of the page contents to the browser and let the browser decide how to render and interact with the content on its own accord.
The point is, running an "app" on the web is largely BS. If you think your blog, news site, or forum is sufficiently different from the thousands of others out there that it warrants an entirely new application (as opposed to just different styling), then you're full of yourself.
And if we had taken that simpler route, I wouldn't have to spend days designing a trivial blog site. Websites wouldn't all be so jarringly different (which they largely are, and unnecessarily so). I could get straight to writing my content, because browser defaults would actually be sane enough to do the dirty work for me. And the resulting UI would be more accomodating to the user than anything I could whip up with "modern" web technologies because the browser has access to the user's [language, color, contrast, font-size] preferences. Not to mention how much more accessible it would be to the visually (or otherwise) impaired.
You are simply asking to go back to the web in the 90's. Time travel is not the answer. Improvements in the present time are needed to fix present problems.
After all, we keep reinventing LISP and it is from the 1950s.
"Put it in the browser" is a strange thing to do. A browser isn't really a VM for running applications; it's a document renderer. Coupling a browser with an operating system is also a strange thing to do. Yet these all occupied people's minds for a long time.
Roughly only 40% of my computer use is on the Web at all. And much of that in on fora that could use a transport other than HTTP.
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.
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.
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.
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.
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.
> Thing is, HTML is a really fantastic and powerful way of describing documents.
Meh. Postscript (and PDF, for that matter) do a better job describing the appearance of a document: you can place things exactly where you want them on the page. SGML does a better job describing the semantic meaning of the page (though arguably no one does it well): a <p> isn't really very descriptive.
As you mention, HTML is lousy at UIs. HTML tries to do too many things, and ends up doing all of them poorly.
HTML is a technology that was stretched too far in the wrong way. When Tim Barners-Lee invented HTML the idea was to describe simple documents semantically, and even embedded images were just an extension of the original idea. When the web became a commercial success, engineers tried to make HTML fit every conceivable need, including making it a UI description language, which it is not. The result is the mess of technologies we have nowadays. It is not a sane system. And still, several people try to defend it and push the envelop even further away from its original intent without exploring alternative technologies.
"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?
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.
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.
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.
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,...
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.
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.
There is precisely zero reason to believe this. If you target developers first, you'll get systems that suit developers needs (see: Unix). Quit using trite phrases like "Basic Economics" as an unsupported justification until you learn something about the topic.
Self-fulfilling prophecy: "Real people" are using web applications at higher rates because of programmers inevitably using the web as their main platform, creating a self-sustaining feedback loop. But, what the herd can adopt, it can also destroy.
FWIW I'm sure people who live in jurisdictions with subpar connectivity would appreciate a renaissance of desktop applications.
Do you honestly believe the success of web applications is merely an accident and not a reflection of how much better they fit our world?
Admittedly, many of the benefits of the web, like storage in the cloud and online collaboration, could be replicated with traditional installable applications, but they mostly weren't. And, the lack of "installation" is a big deal. Many people are utterly helpless with computers and would be terrified of installing everything...and maybe should be. Viruses and malware have proven very difficult to defeat in installable applications, while on the web the risk of poor security is usually concentrated on the developer (or the company the developer works for) rather than the consumer.
Further, low bandwidth is a reason to use web apps over installables in a lot of cases, and not the other way around as you suggest. Downloading Office on a slow/expensive link would be horrible. Using Google Docs, not so bad. I work on slow internet most of the time (I travel full-time, and use 3G/4G internet, sometimes with weak connectivity and expensive data); I save my "ooh, I want to download this new game/app" moments for when I'm somewhere with free/fast wifi. But, I still do lots of work on the web, and I don't find GMail/Inbox problematic at all on this slow link. Of course "no Internet" is different from "slow/expensive" Internet, but without Internet, you're limited to packaged software purchased at brick and mortar stores, which is not a very wise target market for developers making new stuff, in the general case.
The web's lack of "installation" is countervailed by its ad-hoc persistence methods like local storage, cookies, cache and sessions, as well as its forms of authentication in relation thereof. You can hang yourself on the web just as easily, perhaps even more so, and I have seen it happen many times. The web also has the intrinsic problem of unpredictability and unaccountability. Entire layouts can be replaced by developers instantaneously on unwitting users.
Most people would not download Office, of course, but use a friend or acquaintance's pre-recorded media. Actually even if it came to torrenting it, it wouldn't be significant of a load.
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.
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.
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.
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).
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
> 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.
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.
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 :-)
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 ?
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.
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.
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.
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.
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 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.
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. :)
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.
82 comments
[ 4.3 ms ] story [ 130 ms ] threadThe 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.
[1] https://news.ycombinator.com/item?id=10865748
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.
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.
And it's expensive:
https://www.sencha.com/store/
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)
>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.
And why not? 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.
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 ?
The illusion of security given by inputing and multiplying passwords might not beat having a central point of authentication handled by the OS. EDIT: and you have system accountability for free.
User sessions and applications are to be already limited by the OS why redo it?
And like it or not a browser is a millions sloc application that have access to everything potentially. You just trust mozilla, google, apple to not access everything. But have you audited their codebase?
If your OS is not a toy that should not happen.
You mean instead of being able to download and run something natively at my convenience, I have to run it on (barf) JavaScript in the browser? I have to submit to being tracked everywhere I go online, and send my data to a central "cloud" where advertisers can profit from it freely without paying me royalties?
No fucking thanks.
This webpage? It consists of a title and a link to an article, followed by a series of comment objects. Each comment contains some text, an associated author, a timestamp, and possibly a set of child comments.
This exact arrangement of data can be found all across the web. If you take any blog article, it consists of this same layout, only instead of a link to the article, you have a bunch of text and/or pictures.
It arguably took more work to design a product (the web browser) that can parse html, apply CSS styling, parse and execute Javascript, and tie all those pieces together with the DOM than it would have been to just have webservers pass a loosely annotated version of the page contents to the browser and let the browser decide how to render and interact with the content on its own accord.
The point is, running an "app" on the web is largely BS. If you think your blog, news site, or forum is sufficiently different from the thousands of others out there that it warrants an entirely new application (as opposed to just different styling), then you're full of yourself.
And if we had taken that simpler route, I wouldn't have to spend days designing a trivial blog site. Websites wouldn't all be so jarringly different (which they largely are, and unnecessarily so). I could get straight to writing my content, because browser defaults would actually be sane enough to do the dirty work for me. And the resulting UI would be more accomodating to the user than anything I could whip up with "modern" web technologies because the browser has access to the user's [language, color, contrast, font-size] preferences. Not to mention how much more accessible it would be to the visually (or otherwise) impaired.
After all, we keep reinventing LISP and it is from the 1950s.
"Put it in the browser" is a strange thing to do. A browser isn't really a VM for running applications; it's a document renderer. Coupling a browser with an operating system is also a strange thing to do. Yet these all occupied people's minds for a long time.
Roughly only 40% of my computer use is on the Web at all. And much of that in on fora that could use a transport other than HTTP.
Applications are not really documents.
It was pretty cool to read "Philip and Alex's Guide to Web Publishing", he had done lots of the same things we had.
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 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.
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.embarcadero.com/products/rad-studio/firemonkey
Meh. Postscript (and PDF, for that matter) do a better job describing the appearance of a document: you can place things exactly where you want them on the page. SGML does a better job describing the semantic meaning of the page (though arguably no one does it well): a <p> isn't really very descriptive.
As you mention, HTML is lousy at UIs. HTML tries to do too many things, and ends up doing all of them poorly.
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?
Chatrooms were around much earlier. Perhaps he means on a website?
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.
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 .
However, you limited this to chatrooms implemented with 'web technologies' - I can't address that specific topic.
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,...
It probably already exists, but I don't know what it is. Something that completely hides all the CSS ugliness
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.
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.
FWIW I'm sure people who live in jurisdictions with subpar connectivity would appreciate a renaissance of desktop applications.
Admittedly, many of the benefits of the web, like storage in the cloud and online collaboration, could be replicated with traditional installable applications, but they mostly weren't. And, the lack of "installation" is a big deal. Many people are utterly helpless with computers and would be terrified of installing everything...and maybe should be. Viruses and malware have proven very difficult to defeat in installable applications, while on the web the risk of poor security is usually concentrated on the developer (or the company the developer works for) rather than the consumer.
Further, low bandwidth is a reason to use web apps over installables in a lot of cases, and not the other way around as you suggest. Downloading Office on a slow/expensive link would be horrible. Using Google Docs, not so bad. I work on slow internet most of the time (I travel full-time, and use 3G/4G internet, sometimes with weak connectivity and expensive data); I save my "ooh, I want to download this new game/app" moments for when I'm somewhere with free/fast wifi. But, I still do lots of work on the web, and I don't find GMail/Inbox problematic at all on this slow link. Of course "no Internet" is different from "slow/expensive" Internet, but without Internet, you're limited to packaged software purchased at brick and mortar stores, which is not a very wise target market for developers making new stuff, in the general case.
Most people would not download Office, of course, but use a friend or acquaintance's pre-recorded media. Actually even if it came to torrenting it, it wouldn't be significant of a load.
Hmm. See http://www.joelonsoftware.com/articles/Unicode.html
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.
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).
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:
Desktop apps are dead, long live the desktop app!> 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.
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 :)
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...
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.
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.
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.
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.
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.
Another better road not traveled...
https://web.archive.org/web/19990224200116/http://caesar.ics...
Found this accidentally in the progress:
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. :)