@dev - Why dev for Chrome is a MUST

178 views
Skip to first unread message

Mat

unread,
Apr 27, 2017, 6:36:50 AM4/27/17
to TiddlyWikiDev
For anyone developing plugins or public TW stuff, I just wanted to clarify a general premise - in case you didn't know already:

Assuming the intention is for people to use the plugin, it has to be developed with Chrome in mind:

Visitors to w3schools
2017ChromeIE/EdgeFirefoxSafariOpera
March75.1 %4.8 %14.1 %3.6 %1.0 %
Again, that is for visitors to the w3schools site - but, compared to general user stats from Wikipedia, I'd think the w3school audience probably correlates better with the TW user base. But even if we DO accept the general user stats and slice it any way you want; per device type, geographic location etc etc, as can be seen in the Wikpedia article, - and taking the trends into consideration- the conclusion is undeniable:

Chrome is the absolute most important browser we have to build for, assuming we want others to be able to use the creation. And, btw, also to avoid issue-reporting from non-Chrome users.

<:-)



PMario

unread,
Apr 27, 2017, 8:10:17 AM4/27/17
to TiddlyWikiDev
On Thursday, April 27, 2017 at 12:36:50 PM UTC+2, Mat wrote:
For anyone developing plugins or public TW stuff, I just wanted to clarify a general premise - in case you didn't know already:

Assuming the intention is for people to use the plugin, it has to be developed with Chrome in mind:

IMO that's only partially true. I read it as: "Chrome is the thing to use for everything". Or in different words: "Use a hammer if you have to deal with a screw"

I think:  We should use the best tool, for the job that needs to be done. ... Then all of the sudden, these global statistics are completely irrelevant, because the measure the wrong side of the equation.

-mario

TiddlyTweeter

unread,
Apr 27, 2017, 8:57:26 AM4/27/17
to TiddlyWikiDev
Great discussion. Very relevant.

I put it like this: I never minded that Firefox was in decline so long as it retained its flexibility. Its flexibility on add-ons was superb.

BUT, right now, its move towards WebExtensions target for November, is causing havoc, especially for add-ons that need to save to disk. Its no longer what it was.

I DO think that Chrome saving, IF it could be got to work as elegantly as TiddlyFox currently does, could help TiddlyWiki get more widely used. There has been much discussion about this. Not being a developer I don't really understand the issues on how DIFFICULT overwrite saving has become in browsers.

What I AM clear about is that to "use-TW-out-of-the-box" in a way that an ordinary user could cope with and benefit from needs simplicity. Especially when they first start. Especially on basic saving.

Best wishes
Josiah

Jel

unread,
May 30, 2017, 6:58:22 AM5/30/17
to TiddlyWikiDev
Don't forget Chrome's developing dialects like Iron, too

Jeremy Ruston

unread,
May 30, 2017, 7:15:22 AM5/30/17
to tiddly...@googlegroups.com

I DO think that Chrome saving, IF it could be got to work as elegantly as TiddlyFox currently does, could help TiddlyWiki get more widely used. There has been much discussion about this. Not being a developer I don't really understand the issues on how DIFFICULT overwrite saving has become in browsers. 

The last time I checked, it was not possible to write a Chrome Extension for TiddlyWiki that works in the same way as TiddlyFox. Chrome restricts extensions to a sandboxed portion of the file system; they don’t have access, for example, to your Dropbox folder. So, the extension would require any TiddlyWiki’s to be imported into the sandbox before they can be saved. Because the sandbox is private to the extension, the extension would have to be responsible for syncing content to the cloud to get it on other devices. I believe that TiddlyChrome is subject to these restrictions.

Given Google’s biases, the way to get the best from TiddlyWiki on Chrome is to use it over http:// instead of file://, either by using a cloud hosted provider like TiddlySpot, or a local Node.js instance. Google continue to progressively restrict operations from file:// URLs. From their perspective, the capability is a security risk; the only thing stopping Google from disabling file:// URIs altogether is the outcry from web developers. But there is no doubt in my mind that that is the way that they are going. For Google, security is the overriding concern.

That’s why Firefox is adopting the same approach to security, and banning old-school extensions that have unrestricted access to the browser innards. It’s not viable for Mozilla to knowingly be less secure than the market leading browser, and so it’s pretty much guaranteed that they will continue to follow Google down the path of (a) restricting operations from file:// URLs and (b) severely limiting the powers of browser extensions.

Luckily, there are several different ways of using TiddlyWiki:

(1) As a local file with the HTML5 compliant “download” saver (that’s the one that re-downloads the HTML file each time it is saved). Even though the user experience is lumpy, and puts quite a lot of pressure on the user, this approach is simple and reliable, and I’ve been surprised to learn that many people use it as their everyday method of using TiddlyWiki
(2) As a local file with the Firefox-specific TiddlyFox extension
(3) As a local file with a Chrome-style restricted extension (eg TiddlyChrome)
(4) Via a locally run server
(5) Via a remote, cloud-based server

For the moment, we only need to worry about (2) going away; all the other ways of saving are not threatened.

One final point, as I’ve said before, I do not think that making the single file edition easier to use is the best way to get TiddlyWiki more widely used. Working with the single file edition is inherently conceptually alien and risky for anyone raised on conventional, contemporary web services; the barriers are not just about the number of clicks. I believe that the way to get TiddlyWiki more widely used is through online implementations that avoid the user having to worry about saving.

Best wishes

Jeremy

@TiddlyTweeter

unread,
May 30, 2017, 1:55:27 PM5/30/17
to tiddly...@googlegroups.com
Some of your thoughts should get pinned.

My issue with this is not on saving per se, its on what is a TW "standalone".

Danielo's NoteSelf seems to instance a very interesting mid-place of easy saving and conventional TW authorial autonomy that makes this more rich, and interestingly, complex.

Josiah
 
Jeremy Ruston wrote ...

Arlen Beiler

unread,
May 31, 2017, 9:21:10 AM5/31/17
to tiddlywikidev
Good overview Jeremy.

Just thought I'd mention that TiddlyChrome is a Chrome App, rather than an extension, and as such is given the privilege of editting such files as the user specifically chooses using an open file dialog. 

Because apps are going to be removed from Chrome within a year or so, I have not developed it to it's full potential and instead have been focusing on writing a TiddlyServer implementation which will work around a lot of the drawbacks of the stock Tiddlywiki server, such as external file support and serving multiple data folders.

On May 30, 2017 13:55, "@TiddlyTweeter" <tiddly...@assays.tv> wrote:
Some of your thoughts should get pinned.

My issue with this is not on saving per se, its on what is a TW "standalone".

Daniello's NoteSelf seems to instance a very interesting mid-place of easy saving and conventional TW authorial autonomy that makes this more rich, and interestingly, complex.

Josiah
 
Jeremy Ruston wrote ...

I do not think that making the single file edition easier to use is the best way to get TiddlyWiki more widely used. Working with the single file edition is inherently conceptually alien and risky for anyone raised on conventional, contemporary web services; the barriers are not just about the number of clicks. I believe that the way to get TiddlyWiki more widely used is through online implementations that avoid the user having to worry about saving.

--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikidev+unsubscribe@googlegroups.com.
To post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/14297989-c4fa-47cb-8d96-59883e9a9768%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jeremy Ruston

unread,
Jun 1, 2017, 5:56:03 AM6/1/17
to tiddly...@googlegroups.com
Hi Arlen

Thanks for the clarification.

It’s a shame that Google have killed Chrome Applications; they had some neat capabilities. But it’s also a reminder that Google’s habit of discontinuing technologies and platforms is pretty dispiriting from a developers perspective…

Best wishes

Jeremy

To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikide...@googlegroups.com.

To post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.

Arlen Beiler

unread,
Jun 1, 2017, 4:17:43 PM6/1/17
to tiddlywikidev
It can be a bit disconcerting at times, that's for sure. But I have to say that I think NodeJS is probably​ going to give us a good platform to replace what we've been using up to now.

--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikidev+unsubscribe@googlegroups.com.
To post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.

@TiddlyTweeter

unread,
Jun 2, 2017, 3:07:58 PM6/2/17
to tiddly...@googlegroups.com
Ciao Arlen

I understand what you are saying but node.js is a SPECIALIST thing. Lets not lose ordinary users.

Jeremy is modest often in his future perceptions, thinking something like the "TW Popular" may have to be an online service eventually (note: wholly my interpretation, NOT his words) in the future.

I keep crapping on about NoteSelf type architecture as a possible workable way round the death of file saving whilst preserving simplicity in usage in standard situations without any special add-ons at all.

Basically the issue is whether "Local Browser Storage" is, de facto, replacing file saving for persistent apps like TW AND whether it may still be working in two years time. Something like that.

Best wishes
Josiah

Arlen Beiler wrote:
It can be a bit disconcerting at times, that's for sure. But I have to say that I think NodeJS is probably​ going to give us a good platform to replace what we've been using up to now.

Jeremy Ruston wrote:
It’s a shame that Google have killed Chrome Applications; they had some neat capabilities...
Reply all
Reply to author
Forward
0 new messages