Just to clarify some of the background to TiddlyWiki's approach to JavaScript, the DOM etc.
The way that TiddlyWiki works is very simple: it is a pipeline for processing wikitext into the DOM, and from there into static HTML. That's the single process at the heat of all the complexity one sees with TiddlyWiki. The entire user interface is written in wikitext. The advantage of this approach flow from it's consistency: there's one thing to learn about TiddlyWiki's core, and it applies to everything that TiddlyWiki does. The reason is that the same processing pipeline is used in multiple situations to solve the problems that TiddlyWiki is tackling: * generating the interactive user interface in the browser in an efficient manner * generating static HTML representations of tiddlers, and other representations such as JSON * generating standalone TiddlyWiki HTML files, both on the server and when saving in the browser * processing CSS stylesheets as wikitext so that macros can be used for SASS-like handling of repetitive features like browser prefixes The price we pay is that a certain old-fashioned style of writing HTML and JavaScript apps isn't directly compatible. The reason is that in old-style apps the application state is maintained in the DOM. It's a convenient way of writing code, but over the years developers have found that it isn't sufficient for the kind of apps they want to write. The newer wave of frameworks like Angular use the same technique as TiddlyWiki: they maintain all the application state in JavaScript memory (which is much faster to access than the DOM), and generate and update a DOM representation as required. When a portion of the DOM is regenerated, any state stored in that part of the DOM is lost. A controversial point is that TiddlyWiki goes further than acknowledging that old-style JavaScript-in-HTML features don't work properly: it actually attempts to strip out executable JavaScript from wikitext content, and prevent its execution. We do this because part of the vision of TiddlyWiki is for people exchanging and sharing content. Because TiddlyWiki is frequently used for personal data that one doesn't necessarily want to publish, we need to ensure that people can trust that the act of viewing, say, a comment from another user won't inadvertently exfiltrate their personal data. Having said all of that, there are a couple of ways in which old-style JS can be mixed with JavaScript: * create a tiddler with the type text/html containing an ordinary HTML file with JavaScript. The HTML content will display in an iframe, and can be interacted with normally. Getting information out of the HTML content and back into the TiddlyWiki isn't particularly convenient beyond cutting and pasting it. Also, some navigation actions can trigger a refresh of the tiddler containing the iframe, causing the content to be reset (as if the browser reload button had been clicked) * a JS module can add a private DIV to the DOM above TiddlyWiki's main container DIV, and then the JS module can manage that DIV however it needs to: for example, it might make the DIV position: fixed to overlay the page, and then use CSS to hide and show it. This approach hasn't been explored much, but I suspect that a fairly simple core update would make it cleanly implementable in a plugin Best wishes Jeremy On Thu, Aug 27, 2015 at 9:29 AM, D John <[email protected]> wrote: > Dude, > > Calm down. I was not bashing Tiddlywiki. > > And I still don't see the non-sense situation you saw. Not being able to > run plain JS is a handicap. Having to learn a new language subset is good > only for programmers who want brag about learning it in no time. Not for > me. See the difference ? > > You learnt it in one year and found it is easy? Awesome. > Good for You. Now move along with it please.. > > Do you mind if I clarify my concerns ? > > -- > Rainbow > ചുരുക്കി പറഞ്ഞാൽ നിന്റെ കഴപ്പ് മാറിയോ > > On Thursday, August 27, 2015 at 11:49:22 AM UTC+4, Danielo Rodríguez wrote: >> >> >> >> El miércoles, 26 de agosto de 2015, 8:26:08 (UTC+2), D John escribió: >>> >>> >>> But tiddly on iOS is a greater idea. It is a lot of fun for programmers >>> to RTFM and learn a new scripting language subset. >>> >>> [...] >>> >>> From a content creator's perspective, it is a handicap Tiddlywiki cannot >>> run Plain old javascript content. May be the Missing manual will >>> demonstrate the Tiddly-way of integrating interactive HTML content (d3.js, >>> createjs.js...) into Tiddlywiki wikis ? >>> >> >> Can you see the non-sense situation those two sentences create? First you >> say that would be fun to learn a new language subset. And just two lines >> after you say that not being able to run plain JavaScript is a handicap. >> Really? Tw is one of the most permissive frameworks I saw. You can run as >> arbitrary JavaScript as you want as long as you wrap it on a plugin or on a >> macro. What do you mean with plain javascript? Objects? functions ? >> closures ? all that is available on tw. Or maybe you mean the JS from the >> ninety's where you do all those horrible document.innerHtml or >> onClick=alert() ? Have you tried to compare TW with any other framework? >> React native for example ? >> >> I started TW more than a year ago, and it was hard to start programming, >> but once you get the basics, is as easy as any "good old plain" JavaScript. >> > -- Jeremy Ruston mailto:[email protected] -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/tiddlywiki. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/CAPKKYJbRYVkKeEC9t4ZtaN0LzZXNTSX2DjQqjHRveAqGwUk%3DYA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
