• 2 Posts
  • 30 Comments
Joined 1 year ago
cake
Cake day: July 1st, 2023

help-circle





  • Probably not. Having actually played with making a WYSIWYG editor as a learning project markdown is too simplistic for the formatting needs of any non-trivial text editing, as a serialized storage format.

    You almost always end up back with your own data structure that you serialize into something like XML for storage. Or you end up supporting HTML or non-spec compliant syntax in your markdown.

    And if you care about performance, you’re not actually working with XML, HTML, or Markdown in memory. You’re working with a data structure that you have to serialize/deserialize from your storage format. This is where markdown becomes a bit more tedious since it’s not as easy to work with in this manner, and you end up with a weird parsing layer in-between the markdown and your runtime data structures.

    The commenter that’s downvoted is more correct than not IMHO (Also why are we downloading discussions??). Markdown is ill suited for “most WYSIWYG needs”. It tends to get augmented with XML or custom non-spec compliant syntax. The spec poorly supports layout (columns, image & media positioning, sizing…etc) and styling (font color, size, family, backgrounds…etc)


  • There are markup languages for this purpose. And you store the rich text as normal text in that markup language. For the most part.

    It’s typically an XML or XML-like language, or bb-codes. MS Word for example uses XML to store the markup data for the rich text.

    Simpler and more limited text needs tend to use markdown these days, like Lemmy, or most text fields on GitHub.

    There’s no need to include complex technology stacks into it!

    Now the real hard part is the rendering engine for WYSIWYG. That’s a nightmare.


  • The ecosystem is really it, C# as a language isn’t the best, objectively Typescript is a much more developer friendly and globally type safe (at design time) language. It’s far more versatile than C# in that regard, to the point where there is almost no comparison.

    But holy hell the .Net ecosystem is light-years ahead, it’s so incredibly consistent across major versions, is extremely high quality, has consistent and well considered design advancements, and is absolutely bloody fast. Tie that in with first party frameworks that cover most of all major needs, and it all works together so smoothly, at least for web dev.




  • This is a weird take given that the majority of projects relevant to this article are massive projects with hundreds or thousands of developers working on them, over time periods that can measure in decades.

    Pretending those don’t exist and imagining fantasy scenarios where all large projects are made up of small modular pieces (while conveniently making no mention to all of the new problems this raises in practice).

    Replace functions replace files and rewrite modules, that’s expected and healthy for any project. This article is referring to the tendency for programmers to believe that an entire project should be scrapped and rewritten from scratch. Which seems to have nothing to do with your comment…?










  • C# on non-Windows is not impossible, but it’s going to require effort infeasible for school projects like that one.

    You mean winforms (The windows specific UI) on non-Windows? Otherwise this is incredibly misleading, and plain wrong.

    C# in non windows is the norm, the default even, these days. I build, compile, and run, my C# applications in linux , and have been for the last 5+ years.



  • The follow on. Lots and LOTS of unrelated changes can be a symptom of an immature codebase/product, simply a new endeavor.

    If it’s a greenfield project, in order to move fast you don’t want to gold plate or over predictive future. This often means you run into misc design blockers constantly. Which often necessitate refactors & improvements along the way. Depending on the team this can be broken out into the refactor, then the feature, and reviewed back-to-back. This does have it’s downsides though, as the scope of the design may become obfuscated and may lead to ineffective code review.

    Ofc mature codebases don’t often suffer from the same issues, and most of the foundational problems are solved. And patterns have been well established.

    /ramble