LeoJS needs to be its own thing

[Inspired Mars]

I’ve watched the progress of “LeoJS” with interest.

What has resulted is something new that deserves to be seen as such.

The millions of people that use Visual Studio Code have no idea what Leo is.

But to understand what this extension is about they will at some point encounter two confusing concepts:

• That “Leo” also refers to another product, namely a desktop app written in python. They should never have to know about this, let alone be left with a lingering feeling that they will need to invest time to figure out what this is, what they are missing out on (nothing) if they don’t understand it. The website, docs and tutorials are poor and look dated. Tying these products at the hip by name is strapping the legacy onto millions of users that will never need it.
• The “JS” will similarly alienate all those who very reasonably assume means that this is a tool for JavaScript users. Do you see how confusing this naming is? It is a footgun from the very start.

This new product needs to have its own wings and direction and need not be forever bound to being backward compatible with a product used by a handful of people (in comparison to the potential market).

Therefore, strongly suggest renaming the product completely to avoid all references to Leo (except as an Import feature). Also use a different file extension for new files but support existing .leo files without fuss. And have a website, one that is modern and simple, together with well produced videos on YouTube,

It is early enough that this change can be made with minimal fuss. Later will be much harder.

My 2 cents. 

[Edward K. Ream]

On Friday, July 5, 2024 at 10:24:42 AM UTC-5 Inspired Mars wrote:

The millions of people that use Visual Studio Code have no idea what Leo is.

LeoJS will educate them :-)

Edward

[Inspired Mars]

(From the other discussion thread that emerged from this one):

Ed wrote:

>Leo isn't an idea, it's a Python program.

That perfectly summarizes why the new product needs to be its own thing with its own name and destiny.

There are zero dependencies between it and Leo.

Do you now see how freeing it is to completely separate the two?

IMHO, the legacy app ought to be retired as soon as possible. 

Seems no reason to have two disparate code bases doing the same thing.

In any case new users ought to be spared the cognitive overload of this (to them) weird clone.

[Thomas Passin]

You aren't considering the benefits of custom Python code in adding functionality. I have several Leo-hosted apps I use all the time.  To recreate them in LeoJS, I would have to learn how to do equivalent things in ts/js and VS Code.  I'm not against learning new things but I've already done that once with PyQt and Python.  Now I want to use them, not reinvent them.  I'm sure many others are in the same position.

If you are using LeoJs without writing code for it, then sure, it's great!

The two code bases are sure to diverge in time.  It always happens.

[Thomas Passin]

I wrote "code bases".  I actually meant "APIs", and I was thinking along the lines of "capabilities"..

[Karthik Suresh]

On Saturday, July 6, 2024 at 11:32:16 AM UTC+1 Inspired Mars wrote:

>Leo isn't an idea, it's a Python program.

IMHO, the legacy app ought to be retired as soon as possible. 

There are some of us that have used the "legacy app" for decades and have no intention of joining the vscode millions.

[Edward K. Ream]

On Sat, Jul 6, 2024 at 5:32 AM Inspired Mars <inspir...@gmail.com> wrote:

> Do you now see how freeing it is to completely separate the two?

No.

> IMHO, the legacy app ought to be retired as soon as possible. 

This isn't going to happen.

Edward

[Inspired Mars]

This thread was about freeing “LeoJS”, but it looks like I waded into an area that didn’t seem controversial at all.

Namely, that the new product was built to replace the old. 

All the past announcements made clear that it was a matter of when, not if: 

These are from memory, not verbatim quotes, but should be close enough.

- LeoJS is the future of Leo

- Such and such is the “final release” of Leo

- The Visual Studio Code team has far far greater resources for building user interfaces

Etc.

And I suggested (and suggest) that sooner is better than later for reasons given.

Now it’s being stated that “this isn’t going to happen”. Well exactly what is being planned then?

If there were ever a time for coy dismissive one liners, that time is long past.

Why create FUD on this project?

Why build up all this excitement and have sweat poured into building a replacement and then not believe in it enough to stand solidly behind it?

Make it make sense.

[Edward K. Ream]

On Sat, Jul 6, 2024 at 8:14 AM Inspired Mars <inspir...@gmail.com> wrote:

This thread was about freeing “LeoJS”, but it looks like I waded into an area that didn’t seem controversial at all.

Namely, that the new product was built to replace the old. 

All the past announcements made clear that it was a matter of when, not if: 

These are from memory, not verbatim quotes, but should be close enough.

- LeoJS is the future of Leo

- Such and such is the “final release” of Leo

- The Visual Studio Code team has far far greater resources for building user interfaces

Etc.

And I suggested (and suggest) that sooner is better than later for reasons given.

Now it’s being stated that “this isn’t going to happen”. Well exactly what is being planned then?

If there were ever a time for coy dismissive one liners, that time is long past.

Why create FUD on this project?

Why build up all this excitement and have sweat poured into building a replacement and then not believe in it enough to stand solidly behind it?

Make it make sense.

I do not wish to discuss these issues further.

Edward

[Inspired Mars]

Have to admit, the “further” had me stumped, but remembered:

From Alice In Wonderland:

“Take some more tea," the March Hare said to Alice, very earnestly.
"I've had nothing yet," Alice replied in an offended tone, "so I can't take more."
"You mean you can't take less," said the Hatter: "it's very easy to take more than nothing."
"Nobody asked your opinion," said Alice.”

[Miles Fidelman]

Silly observation - but...

LeoJS looks awfully interesting, but nowhere on the github site is a simple "click here" link to download and run it as a webapp.  There's the code, the video, but nothing that says "click here" (as there is with, say TiddlyWiki).  Or am I missing something

Miles Fidelman


Inspired Mars wrote:

--
You received this message because you are subscribed to the Google Groups "leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/fc83cae1-870e-4679-90e9-ecd185ccbb4dn%40googlegroups.com.

-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

Theory is when you know everything but nothing works. 
Practice is when everything works but no one knows why. 
In our lab, theory and practice are combined: 
nothing works and no one knows why.  ... unknown

[Félix]

Thank you Miles Fidelman for that observation : It is not silly at all!! You are right, although it is the first thing I show in the 'LeoJs features' video, it should be the first (or almost first) thing i write about at the top of the documentation!!

thanks again for that!

-----

Thanks for your post inspired Mars, your point of view is direct and refreshing, I really appreciate your blunt honesty.

> I’ve watched the progress of “LeoJS” with interest.
> What has resulted is something new that deserves to be seen as such.

Thank you for your interest and appreciation of this project!

>The millions of people that use Visual Studio Code have no idea what Leo is.

You're right about this! I hope to make the concept of 'outline editor' more popular and something that people see as a useful tool that is distinct and complementary to a typical text-editor or programming-IDE.

>But to understand what this extension is about they will at some point encounter two confusing concepts:

> 1- That “Leo” also refers to another product, (...) Tying these products at the hip by name is strapping the legacy onto millions of users that will never need it.

This is a good point, and I will admit that the 'out of the gate' description of LeoJS in the readme is all laid out in the forefront to be the 'javascript implementation of Leo as a vscode plugin', the goal being to get the Leo user-base's attention and interest, in trying out LeoJS, being a 100% compatible Leo equivalent. (except for being scriptable in JavaScript instead of python)

This approach leaves to be desired in getting a non-Leo user's attention and interest. You're right about that. Thank you for having me ponder and consider seriously that specific aspect.

> 2- The “JS” will similarly alienate all those who very reasonably assume means that this is a tool for JavaScript users. Do you see how confusing this naming is? It is a footgun from the very start.

I don't see it necessarily as bad as you seem to infer it. The preceding point I just addressed, that of presenting LeoJS with a comprehensive list of its features, instead of the actual "it is the javascript implementation of Leo" would dispel out of the gate that misconception. (You are also right in that the github page, i.e. the readme, should be modified in that manner, and also, that a dedicated webpage should go also even further in that direction.

I have bought and setup both domain names "felixworkshop.com" and "philengine.com" for that specific purpose. (for now containing a mirror of my github personal webpage)

To be clear: I think the 'JS' suffix may indeed incite someone to think it's a javascript library or tool... but an improved 'readme' documentation along with a dedicated website that showcases Leo's features instead of focusing on how much it is a faithful and compatible implementation of Leo itself would greatly diffuse that misconception, and remove the confusion about having to go to the old website to learn about its usage and features.

> Therefore, strongly suggest renaming the product completely to avoid all references to Leo

I'll gonna disagree with you here ;)  I don't think this would be needed after implementing what I just stated in the paragraphs above.

> Also use a different file extension for new files but support existing .leo files without fuss.

I'm with you on that one: and indeed, LeoJS has an alternative file format, namely '.leojs' which is a simple JSON equivalent of the xml '.leo' format. I intend to make it the default format when saving a new Leo document in the soon to be released version 1.0. (Note: The .leojs file format is also already supported by Leo itself)

> (...) together with well produced videos on YouTube, (...)

I've recently released two youtube videos that explain both the basics of using Leo, and some other various usage of Leo from within VSCode.

https://www.youtube.com/watch?v=j0eo7SlnnSY
https://www.youtube.com/watch?v=M_mKXSbVGdE

Please feel free to critique the 'well produced' aspect of those videos. haha! ;) I hope you and other users of this forum continue to post straightforward messages without restraint like yours.

Félix

[Thomas Passin]

On Sunday, July 7, 2024 at 12:08:49 AM UTC-4 Félix wrote:

Thank you Miles Fidelman for that observation : It is not silly at all!! You are right, although it is the first thing I show in the 'LeoJs features' video, it should be the first (or almost first) thing i write about at the top of the documentation!!

...

 

>But to understand what this extension is about they will at some point encounter two confusing concepts:
> 1- That “Leo” also refers to another product, (...) Tying these products at the hip by name is strapping the legacy onto millions of users that will never need it.

This is a good point, and I will admit that the 'out of the gate' description of LeoJS in the readme is all laid out in the forefront to be the 'javascript implementation of Leo as a vscode plugin', the goal being to get the Leo user-base's attention and interest, in trying out LeoJS, being a 100% compatible Leo equivalent. (except for being scriptable in JavaScript instead of python)

I think that a helpful approach could be along these lines:

LeoJS is a combined outliner and code editor based on the principles evolved over many years for the Leo Editor.  LeoJS is highly compatible with the Leo Editor at the file and internal API levels.  In this way existing Leo Editor users can use LeoJS and continue to work as they always have, and new users can get the benefits of running in a VS Code or browser host. The combination of outliner and code editor together provides unexpected and remarkably useful benefits.

[Miles Fidelman]

Ok... but it sure would be lot more attractive as a stand-alone app, not a plug-in, and not tied to VS-code.

Again, TiddlyWiki seems the model.  In fact... a Leo plug-infor TiddlyWiki would seem a natural!

Miles

Thomas Passin wrote:

--
You received this message because you are subscribed to the Google Groups "leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/58c481ef-9ec2-4ce7-aa36-2114a5ac2a5an%40googlegroups.com.

[Thomas Passin]

On Sunday, July 7, 2024 at 12:04:27 PM UTC-4 mfid...@meetinghouse.net wrote:

Ok... but it sure would be lot more attractive as a stand-alone app, not a plug-in, and not tied to VS-code.

Yes I would like that too. And have it disengaged from node.js.  But you can't write all that stuff yourself ... Running in a browser, that would be fine with me but for the matter of accessing the local file system.

 

Again, TiddlyWiki seems the model.  In fact... a Leo plug-infor TiddlyWiki would seem a natural!

I've tried TW at least three times over the years.  At first I think it's wonderful, then little by little I learn again that it's not quite what I want.  Quite an achievement, though.