In the spirit of Open Dialogue - Avoiding the - Yet another Plugin?

Folks,
I have a long held view that is often reinforced in these forums, so rather than only embed it in my responses to this thread Equivalent of an array of objects - #3 by TW_Tones I thought I would start a seperate Topic for discussion.

Please don’t think I am talking about you, I am not. I subscribe to the concept of Egoless programming - Wikipedia so please take my words with this in mind.

I do not code in JavaScript, I always try to use TiddlyWiki native solutions first, If I can’t do it in tiddlywiki, I consider TiddlyWiki in need of enhancement or fix to the core. That is I only revert to Javascript as a temporary solution, and ideally only to fill a gap, on the path to improving the core.

  • In my view needing to write a Javascript solution is often a failure, either in my skills or tiddlywiki features, with notable exceptions such as introducing a whole library of features.
  • With all due respect to our contributors with JavaScript skills, I hold the view that many quickly revert to JavaScript when they would be better, contributing to filling gaps in the TiddlyWiki core. Which is unfortunate because core modifications often require JavaScript coders.
    • When someone has spent hours making a JavaScript solution you try telling them it can already be done in standard tiddlywiki, or only 10% of what they did could have being added to allow 100% of the solution, for everyone going forward and without the - Yet another Plugin :nerd_face:
  • If you know JavaScript but not know the tiddlywiki core please consider learning about it because you can make much more substantive contributions. Please also consider asking our contributors who do know the core.

Do you see this occurring yourself, do you find it easier to use your JavaScript skills than develop tiddlywiki skills, do you find the need to solve problems by knowing the right plugin a problem, do you disagree with me?

  • I would appreciate your views, all in the spirit of developing TiddlyWiki.
1 Like

I agree with you on using the native idioms of TW before falling back to the JavaScript option.

Though, I can highlight a few issues which I believe make a certain segment of users quit TW widgets and prefer JS.

  1. JS has far more resources to learn than TW syntax.
  2. JS knowledge is transferable to other projects. If I learn TW, it is not going to help me anywhere else outside TW.
  3. JS has better tools for development. TW does not even have a syntax highlighter for its markup

If TW had been designed to use any mainstream language like Lua or JS for its plugins, the percentage of contributions would have been higher. Because then users would not have the obstacle of TW syntax to start hacking the TW.

At the same time, I admire the brilliance of Jeremy and the core contributors to building this intricate system of widgets.

Personally, I have settled to learn TW at my pace and try solving the problem in TW before regressing to JS. But I empathize with why someone would prefer JS over TW.

Also, I remember some heated arguments on this in Google Forums around five years ago.

5 Likes

I am happy to have open dialogue.

But I am having trouble reconciling egoless programming with calling plugin usage YAP, YAP which, at least to my non-native-speaker eye, is a direct reference to the negatively connotated word yap.

I am awful at writing long form so I’ll use bullet points. Here are some arguments why I find using JS or plugins can be a good choice:

  • Not every plugin uses JS. And using JS does not require plugins.
  • Time is a finite resource.
    • Installing a plugin that works and is maintained by someone takes less time than having to write the functionality yourself.
    • It’s faster to do certain things in JS than in WikiText (in terms of time spent on development).
    • Using someone else’s solution won’t reinvent the wheel.
  • Performance is a finite resource.
    • Solutions written in JS will generally be faster than identical solutions written in WikiText because they skip the parsing steps.
    • Solutions written in JS can be simpler than identical solutions written in WikiText because JS is mutable and more expressive.
  • Not everyone wants to be a power user.
    • Not everyone is interested in deep understanding of everything TW has to offer.
    • Handling edge cases of a functionality you wrote yourself can be difficult.
  • Not everything is possible without JS.
    • Not every functionality gap you can cover bridge with JS is a good candidate for a core change.
    • Making a change to core is much bigger time and effort investment than bridging the gap with JS and time is a finite resource.
    • A merged change still takes time before it is released.
    • Not everyone wants to take the time and effort to go through this process or is skilled enough to provide good enough code or believes in themselves to do so.
  • Plugins are self-contained.
    • While you can’t avoid mixing content with logic in any non-trivial TiddlyWiki, the more you can compartmentalize and hide away the easier the whole thing is to grasp and understand and the easier it is to find non-content stuff when you need it.
    • It is handy to have a functionality as a plugin you can just drop in and it works.
5 Likes

Thanks for your thoughts @Maurycy.

I will give a more comprehensive response later but for the record is YAP in this case is Yet another Plugin, and goes directly to the point I am making. This is actually a common use “meme” see Yet another - Wikipedia Sure I have used a a little flourish in using this YAP to suggest its repeated use has its disadvantages, its relationship to dogs yapping is somewhat co-incidental in so far as it is used as a metaphor, I think it only emphasises my point.

Many of your arguments have validity but then is tiddlywiki "yet another JavaScript platform? I do not think so.

I have not said or implied anything like that.

I am bad with subtle social cues. I think it is a veiled insult. I’ll go with whatever the community decides, if my yapping is bothersome I’ll limit myself to only mentioning plugins in a single dedicated thread.

1 Like

As a native speaker, I also found the repeated use of ‘YAP’ dismissive even if that was not the intent, and furthermore I think it confuses what I understood to be the point of the OP. @Maurycy’s points were all very clear and well-articulated, but I’d especially like to highlight his first point:

@TW_Tones If you’re primarily interested in discussing the relative merits of Javascript vs. wikitext solutions, I think you might get more of the engagement you’re looking for if you restructure your title and OP to remove the focus on plugins, which are just a standard (and convenient!) distribution mechanism.

I also found the tone of the OP problematic. It explicitly criticises the behaviour of others, which I find unnecessarily confrontational. It wouldn’t be hard to rephrase the OP to be positive.

To quote from our community code of conduct:

Our discussions are in English. It is not the first language of many people in the community, nor do we all share the same cultural background and reference points. So we take care to use language that is clear and unambigous, and avoid cultural references or jokes that will not be widely understood.

That’s where the “YAP, YAP, YAP” formulation in the OP could have been improved.

2 Likes

I don’t think I failed to emphasise its not about plugins themselves but JavaScript solutions. Here I quote myself to show the emphasis was clear.

I hope the conversation can address these serious points

1 Like

I am, although a long-time user of TW (since 2004 or 2005, I’m pretty sure), I am still a novice at anything more than doing the basics. And although I consider myself a sophisticated JavaScript user, I’ve never reached for JS doing it.

Maybe I’ll come to feel that as I get to know the community and the intricacies of TW better, but that seems an overreach. Most users of almost any system, and I’m sure that includes TW, are casual users. They use it as I did for years as mostly a note-taking application or some such. But if they want to go further, they can do what I’m doing now: trying to write a fairly complex wiki taking advantage of many more TW features, and trying to learn them as they go. Or they can try to find plugins and other tools that help them through their very specific problems. But once they start trying to do a bit more, they may well turn to the tools they know well, and if that’s JS, then it wouldn’t be surprising if they use it first. That’s not a failure of theirs; it’s logical to proceed with what you know. And it’s not a failure of TW or its community, except in how difficult it might be to find the information that would make it easy for them to do otherwise.

I hope to get knowledgeable enough one day to try this. I’m quite sure my JavaScript skills are up to snuff (I sometimes teach classed on advanced JS.) But I’m not even close yet with TiddlyWiki. I need to understand what it does and how to use it before I look at that.

All this is to note that I’m not ready to contribute to core, and while I haven’t yet reached for lower-level JS techniques to achieve a current goal, it could happen, and I don’t think I would feel at all that either I or TW had failed.

In the thread that seems to have inspired this, I brought up passing arrays of objects to a macro simply as a parallel that I would expect most developers to understand. I was not at all looking to code this in JS.


BTW, as a native English speaker, I didn’t have any reaction to “yap” in earlier versions of the message or its title. I’ve used a number of YA* tools over the years, and I understood it from the first mention of “Yet Another Plugin”.

2 Likes

That’s the part you choose to emphasize (i.e. those words are bold). It is a hostile point, and it begs for hostility in return.

That screams “it is a failure to write Javascript in TiddlyWiki, in all circumstances.” I reject that wholeheartedly.

It seems TiddlyWiki syntax is your hammer, and everything is a nail. You’ve repeated this never-javascript-and-only-TiddlyWiki-Syntax many times before. It isn’t helpful, it is getting pushy, and it is getting annoyingly old.

And it is bunk. Folk should use TiddlyWiki as they see fit, learn what they want to learn when they want to learn it, learn what they do want to learn at their own pace while leveraging the skills they already have, and they should not have to learn what they don’t want to learn if they want to stick with leveraging the skills they have (and the resources available)

Also total bunk: needing to write a javascript solution is sometimes/often/whatever a failure in TiddlyWiki features.

I don’t want TiddlyWiki core to have every feature available under the sun to eliminate the need for some things that are better done in javascript as a standalone macro or plugin. Don’t junk up TiddlyWiki with stuff that may only be used 20% of the time. 80-20 rule, please !

I want TiddlyWiki core to stay light and agile. Everything else should be a plugin. Or a repository of javascript solutions by those who are good at that kind of thing. (Not everything needs to be a plugin, does it?)

Use your right tool for the job.

2 Likes

That is you reaction to the use of the word failure not mine.

I did not say that. Please read the content and understand it before you flame. I suspect you are reacting because of other replies.

@Charlie_Veniot
You do not know what you are talking about if you are talking about what I said.

I am sure what I am trying to say in this Topic is something I belive based on more than decade with tiddlywiki and a perspective that understands what less technical people face using tiddlywiki. Although I am always happy to revise a position based on reasonable feedback but few of you have replied in a substantive way to my argument, or few have even tried to understand it.

Few have asked what did you mean by something?, they have just said I am wrong.

Just look at my contributions and kindness toward people in this community and ask yourself if it does any good to attack a regular and prolific contributor with such vitriol.

1 Like

That’s a very good conclusion. I agree with it. Users tend to use what they know, because it seems to be easier and faster. For “me” as the only user of that work it probably is …

IMO Tony is right too. If you know JS it may be faster for you. But the solution is “hardcoded” in a way that cannot be easily changed by others. TiddlyWiki WikiText is designed to be editable and reusable by ordinary users. That is an advantage.

Which leads us to the next conclusion …

… There can never be enough documentation. But documentation is a community effort.

I don’t want to derail this thread, so I’ll add a link to a “to be written thread”, which will link to some resources here at Talk, how users can contribute to the TW docs.

5 Likes

Tony has always been one of the most cooperative and active contributors to this community. When I was test-driving TW around 5-6 years ago, his detailed guides to my beginner questions on Google Groups were a big reason for convincing me to make TW my notes app. I said to myself, “Wow, TW has a helpful community. It is worth investing time in. If I get stuck, someone from here will definitely help me.”

We must judge a person as a sum of his past contributions rather than a single post.

JS vs. TW

I have noticed this issue more than often leads to unnecessary friction in the community. I don’t know what the reason is and why people feel so strongly one way or the other. But this “JS vs. TW” tag of war undercurrent is always there.

I felt it in the Google Groups, too, from more than one member and in both directions.

Curse of Open Source

More often than not, open source projects form internal factions, which turn into zealots, and then bitter fights break between them.

I have seen it in heated debates on Vim vs. Emacs, Vim vs. NeoVim, Vim plugins vs. native commands, Gnome vs. KDE, GNU vs. Linux, etc.

To outsiders, these bitter debates would seem frivolous. But these quarrels erode the community. There is a reason why “this is the year of Linux desktop” never materialized.


Agree. The syntax documentation is complete, IMO. What we need are use-case based tutorials. For example, “List tiddlers you created on a certain date.” This tutorial will teach a bit about filters and ListWidget. I have some plans for tutorials, but first I need to learn TW. :smiley:


Another problem I have is that the investment in TW is not transferable to any other project. Investment in TW will only help you in customizing TW. This is not true for other tools that support Lua, Python, or JS plugins.

What are your thoughts on this?

1 Like

I think that’s not the case. TiddlyWiki brought me to HTML, CSS and JavaScript.

I did know and used several other programming languages for my professional carrier. I did programming and teaching in Assembler, C, Pascal, Ladder-Logic and other IEC61131 automation languages.

So JavaScript was “just an other c-like” language, with an interesting twist [1]. It was developed for the Web and now browsers dominate the world.

I didn’t have any relation to HTML and CSS prior to stumbling upon TiddlyWiki. So TiddlyWiki brought me to the web. …

Not as a consumer … but a creator. … And from my point of view that’s one of the superpowers of TiddlyWiki, that it can do that.

I think there is no other system, which can be used as a UI rapid prototyping system, where the same code can be used for a production system. That’s a huge thing.

About: rapid prototyping

The purpose of a prototype is to allow users of the software to evaluate developers’ proposals for the design of the eventual product by actually trying them out, rather than having to interpret and evaluate the design based on descriptions.

Just think about the Stroll project. It takes on Roamresearch, which is a big company. But @DaveGifford repetedly “calls” himself a “non programmer”. … Think about that. … IMO that’s fantastic.

There is problably more, but that’s my thoughts for the moment.

[1] I know that’s a long video, but it’s the “history of the web”. Which I had been part of as a consumer since NetScape and then FireFox.

4 Likes

I believe the problem here is not the opinion, but the attitude towards us who write Javascript.

Here’s one example that seems condescending and actually hurt my feelings:

Promoting WikiText is good, and I appreciate that @TW_Tones has taken the time to teach me a lot.

But how can it be good to downplay and belittle community efforts for being in Javascript?

4 Likes

I didn’t even know how to write a macro in Tiddlywiki until a year or two after Saq and I did Stroll. :slight_smile:

1 Like

This is an interesting take. I learned more about this community.

It makes me think my problem with TW widgets/macro/filter is more personal than a general one. I have learned and worked professionally in several languages and frameworks, including JS and its several frameworks. I now have fatigue and perhaps unconsciously resist learning new syntax/frameworks unless the payoff is good enough.

Thanks for the video. I will watch it entirely, but the parts I saw were illuminating.

Yeah. I agree. Regrettably, OP could have phrased it better in this thread and the one you linked, which would not have caused strife and, given the appearance of factionalism.

In the spirit of egoless programming, egoless programming is a terrible idea.

In a setting like tiddlywiki where there are very large differences in comfort and experience of the contributors, it just serves to create a toxic environment for the less experienced and more vulnerable members.
If you need an example, if someone were to look at the code for Bob – which is a personal project that I am rather invested in – and say ‘why did you do it this way? It is stupid’, it would have no real effect on me. I am established in my career and know enough about what I am doing to either know that it is indeed a terrible idea and should be fixed and it is that way because I haven’t fixed it yet, or to know that it isn’t a reasonable criticism and be able to explain why.
If someone said that to me about something I made 15 years ago it would have been a completely different situation. I wasn’t experienced enough to know if the criticism was warranted or not, I wouldn’t know how to explain one way or the other, I would have just been discouraged and due to factors that have absolutely nothing to do with coding or tiddlywiki I would not have had the ability to deal with that sort of toxicity so I would have just left.

If someone has to put up with hostile environments in their daily life, they have far less energy left over to address attacks, despite the attacks being prefaced with ‘it isn’t anything personal, it is just about the code’. And yes, it is an attack, it may not have malice behind it, but the intent behind it doesn’t really matter to the one it is directed at. Trying to deny that it is an attack just invalidates the person affected by it and shows a complete lack of respect for them as a person.

In a situation where there is no hierarchy, everyone is in a secure position, and everyone has a similar level of proficiency, a very careful version of egoless programming can work. Some of my projects are with close friends who I have known for well over a decade and everyone is experienced, and for those projects everyone is very harsh in their critiques, but the difference between the social and development aspects of our interactions are well understood. For a group like the tiddlywiki community, there isn’t really a difference between the social and development aspects of most relationships. In every instance where I have seen egoless programming in public projects, it has been used as something for people in secure positions to hide behind while harassing people in less secure/less knowledgeable positions. Even if that were not the case, if you look at the 10 commandments of egoless coding they are all things that require a lot of experience. For example, how can you ‘be kind to the coder, not to the code’ if you aren’t an experienced coder? Or ‘Treat people who know less than you with respect, deference, and patience’? While ‘punch up, not down’ is a good general rule in life there isn’t a way to judge which one is which here. Status and position is a very complex subject and someone who is proficient in coding isn’t necessarily in a secure position otherwise and, as much as we may wish they were, different aspects of life are not independent. Like I said in my example above, things completely unrelated to tiddlywiki do matter.
Despite the efforts of everyone involved, there is a hierarchy here. Criticism from me on most things would have much less of an impact on a conversation than the same criticism from Mario or Jeremy.



To directly address the points in the original post, they seem to be almost exclusively opinions about aesthetics. Making a value judgement about if a javascript plugin or a wikitext plugin is a ‘more substantive contribution’ seems to be based solely on opinion.
And for me, in both an aesthetic and technical way, the core should not do everything. TiddlyWiki has an amazingly flexible plugin system so the core can, in principle, be extended however a person wants. Anticipating all of the potential extensions and adding them to the core would just make the core bloated and difficult to work with.



As a post script about the egoless programming, the following quotes demonstrate some of my problems with egoless coding:

responding to someone not interpreting what you say the way you want it to be interpreted as though it is necessarily a failure on their part because they don’t understand what you meant and then interpreting it as a personal attack seems at odds with the ‘you are not your code’ aspect of egoless programming, although in this case it would be ‘you are not your explanation’.

2 Likes

I’m a career software engineer with 20 years of experience in multiple languages all across the board: C/C++, Python, C#, JavaScript, Lua, etc. I feel that I’ve been an active TW user since April of 2021 (that’s the created date of my first tiddler from when I decided to go all in from Roam Research and Notion, found by looking in [all[tiddlers]!is[system]sort[created]limit[10]]) but I definitely still feel like a beginner in learning the idioms of TW and this community. Just letting you know where I’m coming from!

I’ve seen a lot of programmers that write SQL like they write imperative code: they code against the grain, so to speak. “How would I solve this in my programming language?” vs. “How do I tell the database what I want via SQL?” Subtly different.

I do that when writing TW “code”. A lot. However, the only time I’ve reached for JavaScript so far is when I made a personal plugin that puts a tiddler in edit mode if I triple-click it; if there’s a way to do that in “pure” TW please let me know!

All the other little systems I’ve made for myself (project management and todos, tracking who I’ve lent books to, an embarrassing implementation of Soren’s reference explorer, etc) have been in TW alone. I enjoy the intellectual game of figuring out if TW can do what I want “out-of-the-box”. And it’s delightful that the answer, so often, is a resounding yes.

Are we counting CSS customizations? HTML? What about scripts that we use to do things with our wikis besides edit them in browsers? I’ve used ag and sed from the command-line to make mass-scale edits to my wiki (running in Node locally on my desktop). I know about the Commander plugin, but I’m honestly faster with the command-line tools for certain things.

I have yet to consider making a pull request against core at all. Again, I feel that I’ve a lot to learn culturally first and I don’t feel that I’m done exploring what can and can’t be done in TW.


That said, I agree with some of the other respondents on this thread – communication in a mixed experience level community is hard (via text, no less!) and it’s probably best to accept feedback in the spirit in which it’s given. If someone is saying, “That communication seems dismissive or harsh,” then arguing back why they’re wrong probably sends the wrong message. :slight_smile:

1 Like