yeah I have been using it for testing other plugins lately. You can just watch the video I made if you are in a rush or install it locally and play with the code. I didnt open source the tiptap version I started working on. I also worked on fixing the draft system. I think the rules about how many drafts one can have and where just feel arbitrary. So users can have as much new topic drafts as they want.
But as I said, I probably wont finish it unless I am really really bored haha
If there is no financial incentive I just wont care enough.
I also thought about this. I was working on a discourse-monero integration so that I can sell early access to git repos (also looked into integrating discourse and something like gitea or gitlab). But I am not sure if there is really a âcrowdâ to put the crowd into the âcrowdfundingâ. It seems like the only people paying for discourse have a business relationship with the company behind discourse.
Tiptap isnât really a comparable example though because itâs just using markdown shortcuts to convert to HTML (AFAIK). You canât then edit formatting that already exists using markdown (because the syntax does not display). So you can go one direction but not the other. And to me any WYSIWYG editor solution for Discourse that doesnât render to markdown in the output is a non-starter. That fundamentally breaks core compatibility and locks you in to the particular editor plugin youâve chosen. I guess if Tiptap could output to markdown the approach would be fine.
The point of showing Typora as an example is that they fairly elegantly harmonize WYSIWYG with markdown. It seems that for some, like @Jagster , an ability to keep the existing behavior and not âjumpâ between preview and syntax would be desirable. But I do think the Typora approach is preferable and more intuitive for many other people.
Thatâs exciting to hear! I would definitely be interested in this.
Agreed! I think/hope this will be improved in core in the future.
While I donât think youâre quite right that the âonlyâ people paying for Discourse have a business relationship with CDCK (Communiteq would probably have things to say about that ), I do agree that for an open source project Discourse has a community somewhat lacking in âcommunity spiritâ or âopennessâ or something. I canât quite put my finger on it, but things definitely work differently here than in many other open source projects, even ones run by commercial entities. I am hopeful that true crowdfunding efforts and community-own/driven plugin (or even changes to core) can happen one day. I would especially like to see this around theme development for more advanced layouts and changes, as Iâve mentioned before: Relative lack of themes - am I missing something?
I explained my position on this before. Markdown is a crutch and we need to get rid of it.
It does not. If somebody really wants to convert html back to markdown they can do it and migrate back. Look at the migrationscripts and write your own. not a big deal.
fair point.
The main issue is: everything not written in react is just a sunk cost at this point. Anyone who is serious about having a career in frontend development or even someone who just wants to do something that has an impact will avoid anything that is not react.
So there needs to be a financial incentive that counteracts this. The developer experience is also not very good. It is not really fun to work with this codebase. So the only reason why I would continue to work on this stuff when I am really bored is because I spent so much time on it already and got used to it.
Crowd funding imho would work easier for ppl whom are not big businesses running discourse. There are a few community contributed plugins and Theme/theme components.
Non big businesses often do not have large pools of funds to invest individually. But organise interest a community funded project can have equal or even a larger pool.
Just a matter of figuring out how to apply. Whethet using something like Donate, Patreon etcâŠ
And yes I think your vision to modernize and make the editor very user friendly is very appealing for the masses.
I disagree and I use markdown allll over the place and am glad it exists and is widely supported.
Interesting to hear this. Iâm not a dev myself so I donât know what itâs like to work with the Discourse codebase. I hope your experience is not the norm, though I also recognize its validity and importance.
Would this be better pharsed as anybody whom wants the most job opportunities in front-end should learn react?
Iâve been using non react frameworks in production for over a decade from small projects to large ones, form green field to legacy ones. Iâve used react in a couple of prototypes and toy projects to see how it works. The company Iâm with currently employs good JavaScript developers regardless of expertise in a particular framework.
This risks going wildly off topic but deserves discussion somewhere.
I think regardless of immediately obvious market value itâs good to learn a variety of languages and frameworks if the opportunity arises because there is always some generally applicable approach to learn. Also it may be the gateway to learn stuff indirectly. I recently learnt Go in order to deliver a project on a completely different platform and it reminded me of the benefits of simplicity and speed. I also learned a lot more about building a good API. Had I not made the effort to learn Golang I would not have had that experience.
Ember is unforgiving but apparently well designed? The challenge with working on Discourse is that you are also faced with a large bespoke platform that you need to learn to navigate around. The approaches of self-reliant reverse engineering (in lieu of detailed documentation) you develop when doing that will benefit you on completely different domains.
Iâd argue learning a major platform or two is more important than learning a specific framework. For example, is it more important to learn Wordpress than to focus on learning PHP?
So I donât think learning different platforms and their individual tech stacks should be in any way an issue. Then comes the professional networking that comes with that. The combination of all of that experience will put you in good stead for your career.
The main issue I see here is the conflict between open source and funding. CDCK themselves proved that building a sustainable business around open source is achievable. We have to get quite sophisticated in order to make it pay and deliver value.
It is the responsibility of the whole community to support those who are driving the ecosystem forward. I would suggest that this also starts with the community monetising their own platforms so they can afford to contribute. And many have: I am very grateful for the work Iâve been funded to do by the most aspiring and hard working business people that frequent here.
The thing is: if someone is starting out now or is still early in their career they will learn and focus on react. Focusing on a technology is like making a bet and betting a career on anything that is not react right now in the frontend is a bad choice. The only legitimate alternative might be vue, but it is definitely not ember.
I would say the number of people with a career focused on ember has probably peaked a while ago.
do you see a huge influx of people wanting to learn ember and the discourse codebase?
I donât. Its a sign that this is legacy software. That has reached the peak of its potential. There is no huge influx of people wanting to use it or work on it. Even after the increase in work from home and use of remote collaboration software. People rather use Zoom and discord.
thats what I mean by developer experience.
This is a good point. Discourse is mostly a product: a self hosted community/support forum for a slightly nerdy audience. It will never be much more than that because that is where its funding is coming from. So most decisions will be made to appease this audience.
To bring this back on topic. Replacing the markdown composer means making this software less nerdy. So it means a division from the audience it is geared towards.
It is not easy to get out of this local minimum.
so once a piece of software has found its audience a reflexive feedback loop starts that leads to more features that appease this audience, while the usability for other groups is neglected more and more.
We have about 1k active users in our forum and a fair portion of users in 50+ age bracket who all get along well with markdown and we never had any complaints.
My takeaway: If a bunch of stoners can move up the markdown learning curve, anyone can.
There are 3.5 million cannabis smokers in Germany. 84% of all Germans are pro legalization. So I think there is much room to grow for your forum. The current user base and its potential user base is off by orders of magnitude. It is not enough to work towards this goal by making small improvements or modifications.
Changes that placate the current user base might even inhibit its growth.
Changes are always tradeoffs. Something that might make life more convenient for a power user will put off a new user. At some point the barrier is so high, that new registrations dry up and the forum slowly decays.
You have a point there. We might wanna try to survey (ex)-members to identify what their reasons were to leave our forum. Maybe some of them in fact got overwhelmed by the markdown editor.
Yeah, this is absolutely representative of some points Iâve tried to make before about the echo chamber of both Meta itself and CDCKâs existing paying customers. Obviously you want to make your existing customers happy, but itâs also clear that thereâs a much larger overall market for âcommunity/discussion platformsâ that is being served by a bunch of other players, some of which are definitely doing things that help them get a sale instead of Discourse. One of those things may well be WYSIWYG, but itâs just part of a broader issue in my view. Overall design and theming is another, which I mentioned already above, but bears repeating in this separate context: Relative lack of themes - am I missing something?
very good point. This is just the tip of the iceberg. There are many things that could be improved. For example the idiosyncratic rules on how much drafts you are allowed to have. I first thought it is just a bug, but it is actually intended as it is.
I also try to address that.
So does it completed? If not, please, be so kind and describe known issues and what-to-do at first topic, so the custom Discourse communities admins can easily make a decision to use it or not.
Donât give up just yet! I think I can speak for many other users here when I say that this #plugin would be an absolute breakthrough for Discourse and change everything, especially in certain use cases. I highly encourage you to continue and finish the last mile.
Could you elaborate on that? I might have a need for that, so Iâm very interested in what you have to say. You have my full attention nowâŠ
I thought more about this. I think it is not a good idea to replace the composer. Because it means there will always be a struggle to keep up with the current changes in discourse and I dont want to spend so much time maintaining it.
I will take the knowledge that I gathered from this and build something that works alongside the discourse UI instead of replacing it.
yes, actually I have taken a close look already and I will use it. They even integrate excalidraw into the editor. It is amazing. I joined their discord channel a while ago to discuss an issue related to image upload. Currently their example for excalidraw embeds the images as SVG which is a security concern and needs to be changed. So there are some small details that need to be taken care off.
But compared to ckeditor or tiptap it will be much easier to use. To also give a short update on this topic in general:
As said before, modifying the discourse frontend when it comes to something major like this is not a good idea.That is why it is a much better route to implement this functionality as part of an addition to the traditional interface, instead of trying to replace it. The knowledge gained from the work here so far will be used here:
while it is geared towards a web3 usecase and will contain some web3 features, there is no necessity to use those.
So it will be possible to use this plugin to create categories that have a lexical editor. This also means there is much less risk to try this. Because the experiment will be limited to only part of the site.
I am currently still busy with the work on cryptocurrency subscriptions for discourse. Once this is done I will focus again on moving this forward.
), I do agree that for an open source project Discourse has a community somewhat lacking in âcommunity spiritâ or âopennessâ or something. I canât quite put my finger on it, but things definitely work differently here than in many other open source projects, even ones run by commercial entities. I am hopeful that true crowdfunding efforts and community-own/driven plugin (or even changes to core) can happen one day. I would especially like to see this around theme development for more advanced layouts and changes, as Iâve mentioned before: 
