I’m already well versed in Ember and am looking for a useful Ember app to try and rewrite in Elm as a way to learn Elm. Discourse is a very advanced Ember app, and I’m sure there’s plenty of things that we could all learn from attempting to rewrite the project in elm. But who out there would seriously consider using it instead of the main Ember Discourse?
I’m sure as things were learned during this rewrite, there’s lower level components that would need to be rebuilt in Elm. I’m sure this could take quite a while. I think it’d be worth it, but discourse might simply be too big of an app. It might be better to do it with something smaller and simpler, like hospitalrun.io.
Elm is an amazing language, it would be my first choice for doing a frontend project. It leads to very fast (especially compared to Ember), very maintainable code. It’s beginner friendly and a all around a terrific choice.
However, a tremendous number of hours have been poured into writing the current code base and a tremendous number of hours would have to be poured into a rewrite from scratch which makes the project nor feasible or desirable.
However it is possible to introduce Elm gradually into a code base, starting with converting pain points (for instance, slow parts) but I doubt it would align with the project’s priority.
So, I’m at the stage of trying to become an advocate, trying to pick a small but good sort of hobby project. I need something more substantial than a widget but certainly not larger than discourse.
Working on discourse would essentially be working on an ember->elm upgrade path, which I think would be pretty cool, and get a lot of attention and involvement. I am very interested in collaborating/engaging with others, as opposed to making something alone.
I posted here because I had a good feeling someone would respond!
I know you’re at least somewhat -in-cheek, but it’s important for anyone spectating to note that the migration away from Wasabi wasn’t a rewrite – as the second of your links makes clear, migrating from Wasabi to C# involved writing a Wasabi-to-C# translator, which is an entirely different thing to a ground-up rewrite.
Every time I participated in a full rewrite it was a fail of medium to large proportions.
At my first job (ChaosMusic) we had a CDNOW like clone, we decided that at one point Microsoft Commerce Server was a mess and started doing this gigantic rewrite. The company eventually ran out of money before we managed to launch it. It was so cool, the UI was so much better, etc… But … launching it was impossible and eventually the company ran out of money, I left, and the rewrite was “lost” somehow which was fitting.
At my second job (Altiris, later on acquired by Symantec) they decided to rewrite the flagship product “Notification Server” between version 6 and 7. It was an insane engineering effort. I ran the “sustained engineering” team. Which was in charge of fixing bugs and supporting the actual product we were selling. More than half of the engineering team was sequestered away writing wonderful new bugs and a magical new platform that was going to solve all our pains we had with 6.
Needless to say this was a phenomenal failure of gigantic proportions, NS7 is now mostly dead, partly cause symantec killed it and partly cause it sucked.
So yeah…
#There is not going to be any rewriting of Discourse in X
Not going to happen, not on my watch.
Instead, we solve the problems our customers have, and build new components that make our life better introducing new tech as we need it.
We already have 3 JS rendering methods for various use cases, I do not see us adding a 4th any time soon.
We are like sailors who on the open sea must reconstruct their ship but are never able to start afresh from the bottom. Where a beam is taken away a new one must at once be put there, and for this the rest of the ship is used as support. In this way, by using the old beams and driftwood the ship can be shaped entirely anew, but only by gradual reconstruction.
I also worked on two rewrites in my previous jobs and both failed miserably… The only way I see a rewrite could work is when you are extracting one feature from your product and creating a new one based on that. There’s no way it’ll work if you want to keep (a large portion of) the same features/bugs.
I’ve had people tell me “You should rewrite the backend of Discourse in X” and really I just hear it as “I have no idea how complicated Discourse actually is”
Which I think is a compliment really! Sure it just looks like you’re just typing text in a box and hitting submit, but behind the scenes we’re doing a lot of work based on that input
I’m not so against rewrites if you define them as “building the same software over again after learning their mistakes” In a way Discourse is a rewrite of VBulletin for example!
Offtopic:
… or if you have software written in a technology where the runtime will cease to exist sooner or later. I’m currently facing that problem with a web application where the frontend was developed with Adobe/Apache Flex.
I can understand the excitement when discovering a new language. It’s only natural for a developer to want to start writing code using it.
But I see two major hurdles when it comes to rewriting Discourse.
The first is the undertaking would require a thorough understanding of Discourse code.
I may be a statistical outlier, but I have been looking and tinkering with Discourse code for about two and a half years and I still only consider myself to be approaching literate level, not advanced.
The second is the undertaking would require expert knowledge of the other language so that existing code could be successfully swapped out to it.
Then one needs to weigh the costs.
Are the advantages the other language has to offer really worth the time and effort?
I am familiar with several languages and I have found that each has both stronger and weaker aspects. That is, the choice of language often depends on what you primarily want to do more efficiently and what inefficiencies you are willing to accept.
All that said, I’ve been thinking of where I might try to rewrite Discourse if I was interested in doing so.
AFAIK most code “touches” a lot of other code and the task would not be simple.
I’m guessing maybe the Admin -> Backup might be the most “isolated” code.but would still be a chore.
-in-cheek, but it’s important for anyone spectating to note that the migration away from Wasabi wasn’t a rewrite – as the second of your links makes clear, migrating from Wasabi to C# involved writing a Wasabi-to-C# translator, which is an entirely different thing to a ground-up rewrite.