9 ms·

Human Technology: Text Files

134 points by boris_m 5y ago

christiangenco 5y ago
Preaching to the choir! I'd be surprised to find anyone on HN with an argument against writing your blog/book in markdown with vim. Now what I'd be interested in seeing is an argument for traditional publishers or WordPress users to switch to this sort of stack.
- cyber_kinetist 5y ago
  If there was a decent WYSIWYG editor (like Typora) bundled with Pandoc with a myriad of customizable export options, included with a bunch of high-quality themes and templates, while also having a one-click service to upload to a server for static serving, then I don’t see why not. Maybe the technology stack is not the problem, it’s the presentation of it that makes non-tech people gawk at the complexity. Though the biggest problem with this stack is that everything breaks down when you’re doing anything serious with images or layouting.
  - mynameismon 5y ago
    I think the larger part of the problem is exactly what the author seems to miss: even using Jeykll is scary for non-technical users, let alone git. (Try getting your grandfather to restore his accidently deleted posts)
  - scary-size 5y ago
    That's what I experienced building a static site generator for my dad. You would just dump markdown into a dropbox folder. A cron job would poll from dropbox and generate the website. But even markdown is too daunting for a non-techie. Non-technical users are probably not used to write "code"/"mark-up" and have a good grasp at what's coming out on the other side. The visual aspect, a sort of preview, is missing. There are a lot of options to preview markdown. That's just another hurdle, another tool they might have to learn. It's all just so loosely integrated, even I have a hard time putting it together. Might be fun for us to fiddle around, but it isn't if you just want to put your content out there. I've started to work on an alternative: Desktop app, with a block based editor (text, images, headings nothing more). Shows a local preview of your site. Outputs static assets and/or uploads directly to Vercel for hosting. Few knobs to fiddle around.
    - SllX 5y ago
      Why not a WYSIWYG HTML editor? At the end of the day Markdown is just an intermediary shorthand for the eventual output, originally HTML; and HTML is actually standardized. If you’re not going to use the Markdown syntax, then wouldn’t an HTML editor that hides all the HTML do the job?
      - cyber_kinetist 5y ago
        Actually, you’re right. The only thing people actually need is a good WYSIWYG editor; the format is probably uninteresting to the end user. Though there is a case to be made for using an open, well-documented format (whether it be Markdown or HTML or something else), since without this openness third-party developers would have trouble in developing and customizing their own exporters. Well, if you’re suggesting HTML (or XML) for that job, then maybe it’s time to resurrect XLST instead of using Pandoc… (https://en.m.wikipedia.org/wiki/XSLT https://en.m.wikipedia.org/wiki/XSLT)
      - scary-size 5y ago
        There would still be a lot of moving parts on the table. What to do with all these HTML files? How do I link them together? How do I get those files to a hosting provider? Where do I handle global styling? For the content creating itself a WYSIWYG editor would be fine, but there's more to the process. I'm also guilty of the builder mentality. It's just a fun project to work on and it benefits at least on other person :)
  - trasz 5y ago
    How would content created with WYSIWYG editor work (and look decent) on any device other than it was created for, eg a phone?
- matkoniecz 5y ago
  I expect that for book writing content may be doable in markdown, but real book will require more advanced format. LaTeX? I am not going to argue against vim but I would argue against being forced or expected to use it.
  - boris_m 5y ago
    You can have the content in markdown and then go through LaTeX for additional stuff (title page, headers and footers etc.)
- eternityforest 5y ago
  I don't think there is much of an argument. CMSes work and they do a ton of other stuff besides edit text that people want. And they can be cloud managed with no manual setup. Their black box point and click model is great for division of labor. Although, GitHub is a pretty great publishing platform for open source texts, but that's a whole platform that just happens to have text files at the core. Running your own site... is kinda unpleasant. DokuWiki is a pretty good compromise with most of the benefits of straight text.
- YEwSdObPQT 5y ago
  > Preaching to the choir! I'd be surprised to find anyone on HN with an argument against writing your blog/book in markdown with vim. Time. Wordpress for the most part is WYSIWYG. With any of these static site generators I have to learn the conventions, work out how to install and edit themes and generally there is a lot of faffing. > Now what I'd be interested in seeing is an argument for traditional publishers or WordPress users to switch to this sort of stack. There isn't one. It doesn't scale. There is a reason why companies typically use some sort of CMS system. It isn't just ease of editing. You can control when, where and who can publish content to the site. You can localise content. You can version control content. You can have stakeholders review content before it is made public. Doing that with vim, git and a static site generator and some bash scripts is a faff and will frustrate non-techie people that just wanna copy and paste content from Word.
ynac 5y ago
There's nothing wrong with just using plain text - without these fancy fangled markdowners. Not for every one, but a plain text website IS fully WYSIWYG and the load times - look out!
- sharikous 5y ago
  Yep. The only reason I use Markdown is for math equations (and yes I am aware of unicode math but it'snot enough). It's nice to see them rendered. Alas, not all Markdown editors have good equation support. And most of them behave horribly with RTL texts...
dmje 5y ago
HN seems often incapable of thinking about how audiences and use cases differ. I'm personally a huge fan of using MD for my stuff. I'm a recent convert, but am finding it works brilliantly for my use case which is idea capture, presentations, etc. Obsidian is my tool of choice. I've written a parser in php which converts this markdown into html ready for web publishing. All good. But. I also work with 50+ clients who want to manage their own websites. And they want to manage their websites easily, effectively and visually. They want things to look beautiful. They have audiences that they need to engage with content that is not just words but images, video, timelines, maps, iiif manifests, audio, sliders and much more. This is a different audience. To ask my clients to "just boot up a jekyll instance and commit your content to GitHub" is the most wildly hilarious thing to expect of an editorially focused non-technical set of individuals. Yes, plain text works beautifully for simple blogs, documentation, notes and more. But there is huge value in thinking about audience, about design, about engagement which goes beyond just a simple "text is right, wordpress is wrong" argument. Then what seems to happen in geek circles is that all that "wonderful simplicity" is drowned by an absolutely insane set of tools to actually publish. Yes, you've got plain text files but if your stack then has some cli/npm/jamstack/js/gulp/brew horror attached to it, with a truly questionable maintainability problem attached to each and every one of those tools, how simple now? Really the point is: different strokes for different folks. You can't make a stunning coffee table book in plain text. Much as you might hate it, InDesign is your tool of choice. And that's ok. (Also, he's just plain wrong about not being able to get his content out of wordpress. There's a solid and very well supported XML export format for all wordpress instances, even wordpress.com...)
- quanticle 5y ago
  Came here to post a similar comment. From the perspective of the user, a Blogger or Wordpress site is far simpler than writing Markdown (in vim, no less!), generating the site, checking it into git, and uploading/pushing to the web server. Arguing that vim + markdown + static site generator is simpler, and therefore superior to a content management system or blog engine is like arguing that a dirt bike is simpler, and therefore superior to a car. Yes, mechanically, a motorcycle is far simpler than car. But simplicity of implementation leads to complexity of operation, and it's no surprise that most people prefer cars or SUVs for their daily commute, even though the innards of a car are tremendously more complicated than the innards of a dirt bike.
sgtnoodle 5y ago
I recently needed to start pumping out complex diagrams for work, so I spent a few hours learning mermaid, realized it couldn't output to SVG, and then spent another hour learning graphviz. Now I can barf out ugly but functional, version controlled diagrams of arbitrary complexity. While I normally use openSCAD when modelling objects for 3D printing, I recently fired up the web version of SketchUp and knocked out some curtain rod bracket stiffeners in about 15 minutes. Visual point-and-click tools are great for learning, and continue to be useful for simple, ephemeral things that don't need to be better than arbitrary. As soon as you reach a high level of complexity, or need to iterate on and optimize something, having the text based description language seems to become orders of magnitude more productive.
- jcun4128 5y ago
  I love SketchUp unfortunately it seems to not be maintained. At least the free one lags on a gaming computer. So at some point I have to drop time to learn something like F360. Just sucks when you know something really well and can just model things/no learning curve.
  - dagw 5y ago
    SketchUp itself is under active development, however they've stopped offering a free version of the desktop application and only offer a stripped down web version.
    - jcun4128 5y ago
      I see. The only other thing is I primarily use it for 3D printing stuff and since it's a surface vs. parametric sometimes something that looks solid is not. I have started using a checker for edges/faces but it's funny when I don't pay attention to a slicer and there's a chunk missing on the print. Anyway yeah mostly the pain now is 2017 version if you rotate a view it lags. But yeah sounds like need to pay for it.
- eternityforest 5y ago
  I suspect 3D CAD is one area where GUI will always win. As far as I know big companies and militaries and cities and all the rest use GUI. A small subset of people with an impeccable ability to work with 3d stuff in their mind might be more productive in code... till they have to collaborate with others who can't compute a chain of 3 rotations mentally.
trabant00 5y ago
I tried to write my documentation, CV, presentations, etc in markdown for a few years. It's ok I guess but I was forever dissatisfied with the result presentation. Finally made the jump to latex and I feel cheated for believing it is too complex and not touching it for all those years. For example https://latex-beamer.com/ https://latex-beamer.com/ for presentations is extremely simple, you can be productive with it in 2-3 hours. Give latex a try, forget markup languages.
- twobitshifter 5y ago
  I had a similar problem with my markdown CV. The layout was never quite right and it was a lot of iterating to get even that far. I ended up just using pages, which I hardly know, but could get to do what I wanted.
pkdpic 5y ago
> you should always use the weakest technology capable of solving your problem I knew there was a reason I got on HN at one in the morning. Pointless night redeemed. Also duh I guess, Im just stupid.
tommyage 5y ago
If you use latex as your input, you benefit from a nicer layout and have the option to handout pdf's to content maintainers in a professional format.
- twobitshifter 5y ago
  Pandoc can output the same professional pdfs.
- approxim8ion 5y ago
  LaTeX is terrible for writing in flow though per my understanding. Too much markup language.
Veen 5y ago
As a copywriter and technical writer who has to deliver content in docx files with custom styles for each client, Pandoc is a life saver. I can write in Markdown and run a script that outputs a (more or less) correctly formatted docx file and drop it in an email or upload to Google Drive. But the fact that I have to do that reveals the limitations of the plain text everywhere approach. My clients don't want markdown and they wouldn't know what to do with it. They want Word and its revision and editing capabilities, and they'd almost certainly fire me if I insisted they used Git instead.
- wildmanx 5y ago
  I've wondered about this many times -- your conversion is a one-way street, right? Let's say you have your source material in MD stored in Git, convert it to docx and send it to your client. They use Word to make annotations and revisions and send it back to you. Now what? How do you get this back into MD and your Git repo? Of course you can do this by hand, but that's terrible work. It certainly is worse than staying in the Word ecosystem and flying with it. Not that I'm advocating this, but I don't see how "backporting" their proposed changes into some local Git branch in MD scales. So, I'm curious about your solution to this.
  - deleted 5y ago
    [deleted]
  - leephillips 5y ago
    I’m in the same boat, often, and there is no solution. I do the original writing with Pandoc/Markdown, but I’ve resigned myself to working in the client’s format for subsequent revisions. If a revision requires a lot of new content, I write that again in Pandoc/Markdown and paste in the converted result.
  - marcosdumay 5y ago
    Oh, the Word "mark changes, annotate and pass away" model of change control doesn't work when everybody is using Word either. It's basically deeply flawed, and once somebody decides to go through that road, your best bet is to read the annotations and redo them manually on the original document. That works about as well if your original is in Word or any other format.
throwamon 5y ago
> you should always use the weakest technology capable of solving your problem Wrong, you should always use the technology capable of solving your problem that's also the least amount of work. Very often that's a technology that solves a more general problem, of which yours is but one. And very often it has UX that normal people actually understand.
cracrecry 5y ago
The first thing that I see again and again here is using the term "Marketing" wrongly: Marketing is not sales, marketing is not Advertising. Although usually the "Marketing guys" also handle sales and Advertising, marketing is the study of markets, discovering the desires and needs of the people, it is not about how to force people to buy what they don't want or need. Good Marketing people do not sell you something that you don't need or want, but they know much better than you do what you need or want because they have studied that and they are good at it. Most times they don't even sell, they create and design a product or service because they know it is necessary before it exists. A great product or service for the right market like Pong the original game, the first desktop laser printer or the Iphone sells itself with little effort. People like software developers overvalue what they create for the company and undervalue the work of other disciplines. In fact every department tends to do that with other departments. I am an expert on Tex and LaTex, emacs and Vim, Lisp, and C derivative language programming and Unix systems although I am now entrepreneur. To say that using those technologies is simpler is forgetting all the time that you invested learning those technologies. In my case, decades. You know when you need to teach someone a technology like Markdown, you enter the rabbit hole of having to teach them to use Vim, or even installing a webserver so they can see in a beautiful way instead of ugly text, or even installing a Linux on a raspbery pi, and apt-get, and sudo and ls...
unfocussed_mike 5y ago
While I share some of his enthusiasm (albeit not particularly for markdown tools), I'd observe that considering the rich content produced by the editor, Wordpress.com content is pretty exportable as WXR, and once into a self-hosted WP install is _very_ exportable; there are all sorts of tools to get at WP content in different ways.
zokier 5y ago
Plain text is a mirage, in practice it is not super well defined. I find it funny that we have here lauding the simplicity of plain text while there is right before this a thread about CR/LF. Practically you are always going to reach beyond just simple printable characters, and the moment you do so you fall into a pit of complexity one way or another. Regarding Markdown, using * for instead of is not significantly simpler conceptually. Indeed I'd argue parsing (or rendering) markdown is not simpler than doing so for equivalent html. That is to say that markdown does not provide any level of abstraction over html, instead it is merely a syntatic transformation.
- bradstewart 5y ago
 For the purposes of this article, the author seems to treat writing Markdown and HTML files as equivalent--both are plaintext. > And similar is the case with simple static HTML websites - a simple static page is better than all publishing platforms that can ever be created. The content in both of those formats can be read by anything that can read text, in contrast to something like Wordpess which requires a database and large application stack to view its content.
- AnIdiotOnTheNet 5y ago
 Even for printable characters complexity increases significantly as soon as you permit anything other than ASCII latin text.
Brajeshwar 5y ago
I got out of WordPress after about 18 years with it. I wrote about it at https://brajeshwar.com/2021/brajeshwar.com-2021/ https://brajeshwar.com/2021/brajeshwar.com-2021/ However, when I suggest blogs for other people, the default is WordPress. I'm still navigating and learning the ideal, simplified, pattern with text files without the need to rely on any further complex tools.
eternityforest 5y ago
I don't really ever consider simplicity when choosing tech. I consider standardization. If a text file is the standard, I'll use that unless there's a reason to do otherwise. If a million line framework is the standard, I'll start my search there. Text files don't scale that well. Just try changing one value in a megabytes file. There's no tools for that really. You'll probably spam the disk with a megabyte of data every time. SQLite is about as easy as text, and scales way better. And it already exists. All the complexity is not your problem. They don't even accept contributions. I'm generally biased towards do it all systems if there's no major performance or development time penalty. Complicated tech can be one size fits all and refined over the years. Simple tech encourages ad hoc solutions, pushing the complicated part into YOUR project instead of in an open standard with thousands of devs.
- selestify 5y ago
  Similar to how Flask apps often end up becoming just as complicated as Django once the app grows beyond a certain size. Except that now you don't have the benefit of standardization that Django provides, because you reimplemented everything in a custom way.
- trasz 5y ago
  Problem is, eventually you will have to debug stuff. That's when simple solutions start making difference.
  - eternityforest 5y ago
    I'm not so sure about that. Complex solutions are mostly prebuilt, and used by thousands. When any one person solves an issue, that's usually the end of it, so it gets more reliable over time. Even Windows seems to have gotten better. Simple solutions still have a nontrivial amount of code(Otherwise the whole project would just be "use this turnkey app"), but the code is original. It's probably still going to need debugging.
    - trasz 5y ago
YEwSdObPQT 5y ago
One of the problems with text files and the philosophy of chaining little tools together to do something is that what usually happens is a rube gold-berg machine of little dependencies you have to manage to keep things working. I could spend time working out how Jekyll works, writing a script to deploy the changes and managing changes with git. Alternatively I could just spin up a wordpress instance on a VPS in minutes and start publishing content. Sometimes the "unix" way isn't the simplest way. Sometimes having a product that already built for that task that is paid for is simpler and a better use of your time. I like git, markdown files and pandoc for docs and might even use hugo for really simple sites and use some bash / powershell / batch scripts. However if you work with anyone than yourself you will have to document how it works otherwise they will most likely be clueless as to what you have done. Even in dev circles. Most "dark matter" developers are reluctant of using a command line and only learn what they need to learn to get by. Many just do everything in the IDE and are completely lost outside it.
- bodge5000 5y ago
  I do agree with the author, that you should use the simplest tools you can get away with, but (text-files + jekyll + this + that) isnt just text files, as you say its a precarious stack no less complex than some software package or whatever. I guess if you do just want the truly simplest tool for a website, html is probably better than text files, even if it is a bit less ergonomic to write with
  - YEwSdObPQT 5y ago
    > I do agree with the author, that you should use the simplest tools you can get away with, but (text-files + jekyll + this + that) isnt just text files, as you say its a precarious stack no less complex than some software package or whatever. They are advocating for sellotaping tools together to build a workflow near the end of the article. > I guess if you do just want the truly simplest tool for a website, html is probably better than text files, even if it is a bit less ergonomic to write with Writing HTML when you are trying to write content is pretty painful. Way back in the distant past I used to charge about £100 a HTML page. I ended up learning Perl (and later PHP) so I wouldn't have to write HTML.
smm11 5y ago
My concern is nearly 40 years of writing, that I want to live on long after I've gone just in case anyone cares about it. Plain text files.
axiosgunnar 5y ago
> And similar is the case with simple static HTML websites - a simple static page is better than all publishing platforms that can ever be created. ?
joseph8th 5y ago
Like the author, I also enjoy making things out of plain text. I'm perhaps less evangelical, but after all they are a Vim user, so... ;) My own flow occurs entirely in Emacs, where I write in Org Mode, then build and deploy to GH Pages using Nikola. No more command-line steps for me! And no inferior new-fangled plain-text format: good ole Org Mode stands the test of time.
Jenda_ 5y ago
I don't like these "simple" formats because of non-obvious escaping and overloading too many "common" characters, which is even context sensitive (in HTML, it's just three characters anywhere, & → &, < → <, > → >, and maybe " → " if you use attributes). Even in the provided article, there are many such constructs: - we learn that we need to escape === and --- and ```, but I assume only when it's on a line alone, which seems OK as you probably won't write a paragraph that contains only ``` - then we learn we also need to escape * (e.g. to write 2*2=4), anywhere in the text, but I guess not inside ``` block, so we now need context instead of "find and replace". The escaping mechanism is not mentioned, but hopefully the world has settled on \*, except for dokuwiki which uses %% or whatever - and you need to escape [ and ] (everywhere or only inside link?) - How do you do a link or emphasis inside ```? In some MD flavors, it's outright impossible. (e.g. I need to emphasize something in a pasted code, or I'd like to make a function call clickable as "go to definition/documentation"). In HTML you can use most tags, such as and <a>, inside <pre>

134 points by boris_m 5y ago

Preaching to the choir! I'd be surprised to find anyone on HN with an argument against writing your blog/book in markdown with vim. Now what I'd be interested in seeing is an argument for traditional publishers or WordPress users to switch to this sort of stack.

cyber_kinetist 5y ago
If there was a decent WYSIWYG editor (like Typora) bundled with Pandoc with a myriad of customizable export options, included with a bunch of high-quality themes and templates, while also having a one-click service to upload to a server for static serving, then I don’t see why not. Maybe the technology stack is not the problem, it’s the presentation of it that makes non-tech people gawk at the complexity. Though the biggest problem with this stack is that everything breaks down when you’re doing anything serious with images or layouting.
- mynameismon 5y ago
  I think the larger part of the problem is exactly what the author seems to miss: even using Jeykll is scary for non-technical users, let alone git. (Try getting your grandfather to restore his accidently deleted posts)
- scary-size 5y ago
  That's what I experienced building a static site generator for my dad. You would just dump markdown into a dropbox folder. A cron job would poll from dropbox and generate the website. But even markdown is too daunting for a non-techie. Non-technical users are probably not used to write "code"/"mark-up" and have a good grasp at what's coming out on the other side. The visual aspect, a sort of preview, is missing. There are a lot of options to preview markdown. That's just another hurdle, another tool they might have to learn. It's all just so loosely integrated, even I have a hard time putting it together. Might be fun for us to fiddle around, but it isn't if you just want to put your content out there. I've started to work on an alternative: Desktop app, with a block based editor (text, images, headings nothing more). Shows a local preview of your site. Outputs static assets and/or uploads directly to Vercel for hosting. Few knobs to fiddle around.
  - SllX 5y ago
    Why not a WYSIWYG HTML editor? At the end of the day Markdown is just an intermediary shorthand for the eventual output, originally HTML; and HTML is actually standardized. If you’re not going to use the Markdown syntax, then wouldn’t an HTML editor that hides all the HTML do the job?
    - cyber_kinetist 5y ago
      Actually, you’re right. The only thing people actually need is a good WYSIWYG editor; the format is probably uninteresting to the end user. Though there is a case to be made for using an open, well-documented format (whether it be Markdown or HTML or something else), since without this openness third-party developers would have trouble in developing and customizing their own exporters. Well, if you’re suggesting HTML (or XML) for that job, then maybe it’s time to resurrect XLST instead of using Pandoc… (https://en.m.wikipedia.org/wiki/XSLT https://en.m.wikipedia.org/wiki/XSLT)
    - scary-size 5y ago
      There would still be a lot of moving parts on the table. What to do with all these HTML files? How do I link them together? How do I get those files to a hosting provider? Where do I handle global styling? For the content creating itself a WYSIWYG editor would be fine, but there's more to the process. I'm also guilty of the builder mentality. It's just a fun project to work on and it benefits at least on other person :)
- trasz 5y ago
  How would content created with WYSIWYG editor work (and look decent) on any device other than it was created for, eg a phone?
matkoniecz 5y ago
I expect that for book writing content may be doable in markdown, but real book will require more advanced format. LaTeX? I am not going to argue against vim but I would argue against being forced or expected to use it.
- boris_m 5y ago
  You can have the content in markdown and then go through LaTeX for additional stuff (title page, headers and footers etc.)
eternityforest 5y ago
I don't think there is much of an argument. CMSes work and they do a ton of other stuff besides edit text that people want. And they can be cloud managed with no manual setup. Their black box point and click model is great for division of labor. Although, GitHub is a pretty great publishing platform for open source texts, but that's a whole platform that just happens to have text files at the core. Running your own site... is kinda unpleasant. DokuWiki is a pretty good compromise with most of the benefits of straight text.
YEwSdObPQT 5y ago
> Preaching to the choir! I'd be surprised to find anyone on HN with an argument against writing your blog/book in markdown with vim. Time. Wordpress for the most part is WYSIWYG. With any of these static site generators I have to learn the conventions, work out how to install and edit themes and generally there is a lot of faffing. > Now what I'd be interested in seeing is an argument for traditional publishers or WordPress users to switch to this sort of stack. There isn't one. It doesn't scale. There is a reason why companies typically use some sort of CMS system. It isn't just ease of editing. You can control when, where and who can publish content to the site. You can localise content. You can version control content. You can have stakeholders review content before it is made public. Doing that with vim, git and a static site generator and some bash scripts is a faff and will frustrate non-techie people that just wanna copy and paste content from Word.

ynac 5y ago

There's nothing wrong with just using plain text - without these fancy fangled markdowners. Not for every one, but a plain text website IS fully WYSIWYG and the load times - look out!

sharikous 5y ago
Yep. The only reason I use Markdown is for math equations (and yes I am aware of unicode math but it'snot enough). It's nice to see them rendered. Alas, not all Markdown editors have good equation support. And most of them behave horribly with RTL texts...

dmje 5y ago

HN seems often incapable of thinking about how audiences and use cases differ. I'm personally a huge fan of using MD for my stuff. I'm a recent convert, but am finding it works brilliantly for my use case which is idea capture, presentations, etc. Obsidian is my tool of choice. I've written a parser in php which converts this markdown into html ready for web publishing. All good. But. I also work with 50+ clients who want to manage their own websites. And they want to manage their websites easily, effectively and visually. They want things to look beautiful. They have audiences that they need to engage with content that is not just words but images, video, timelines, maps, iiif manifests, audio, sliders and much more. This is a different audience. To ask my clients to "just boot up a jekyll instance and commit your content to GitHub" is the most wildly hilarious thing to expect of an editorially focused non-technical set of individuals. Yes, plain text works beautifully for simple blogs, documentation, notes and more. But there is huge value in thinking about audience, about design, about engagement which goes beyond just a simple "text is right, wordpress is wrong" argument. Then what seems to happen in geek circles is that all that "wonderful simplicity" is drowned by an absolutely insane set of tools to actually publish. Yes, you've got plain text files but if your stack then has some cli/npm/jamstack/js/gulp/brew horror attached to it, with a truly questionable maintainability problem attached to each and every one of those tools, how simple now? Really the point is: different strokes for different folks. You can't make a stunning coffee table book in plain text. Much as you might hate it, InDesign is your tool of choice. And that's ok. (Also, he's just plain wrong about not being able to get his content out of wordpress. There's a solid and very well supported XML export format for all wordpress instances, even wordpress.com...)

quanticle 5y ago
Came here to post a similar comment. From the perspective of the user, a Blogger or Wordpress site is far simpler than writing Markdown (in vim, no less!), generating the site, checking it into git, and uploading/pushing to the web server. Arguing that vim + markdown + static site generator is simpler, and therefore superior to a content management system or blog engine is like arguing that a dirt bike is simpler, and therefore superior to a car. Yes, mechanically, a motorcycle is far simpler than car. But simplicity of implementation leads to complexity of operation, and it's no surprise that most people prefer cars or SUVs for their daily commute, even though the innards of a car are tremendously more complicated than the innards of a dirt bike.

sgtnoodle 5y ago

I recently needed to start pumping out complex diagrams for work, so I spent a few hours learning mermaid, realized it couldn't output to SVG, and then spent another hour learning graphviz. Now I can barf out ugly but functional, version controlled diagrams of arbitrary complexity. While I normally use openSCAD when modelling objects for 3D printing, I recently fired up the web version of SketchUp and knocked out some curtain rod bracket stiffeners in about 15 minutes. Visual point-and-click tools are great for learning, and continue to be useful for simple, ephemeral things that don't need to be better than arbitrary. As soon as you reach a high level of complexity, or need to iterate on and optimize something, having the text based description language seems to become orders of magnitude more productive.

jcun4128 5y ago
I love SketchUp unfortunately it seems to not be maintained. At least the free one lags on a gaming computer. So at some point I have to drop time to learn something like F360. Just sucks when you know something really well and can just model things/no learning curve.
- dagw 5y ago
  SketchUp itself is under active development, however they've stopped offering a free version of the desktop application and only offer a stripped down web version.
  - jcun4128 5y ago
    I see. The only other thing is I primarily use it for 3D printing stuff and since it's a surface vs. parametric sometimes something that looks solid is not. I have started using a checker for edges/faces but it's funny when I don't pay attention to a slicer and there's a chunk missing on the print. Anyway yeah mostly the pain now is 2017 version if you rotate a view it lags. But yeah sounds like need to pay for it.
eternityforest 5y ago
I suspect 3D CAD is one area where GUI will always win. As far as I know big companies and militaries and cities and all the rest use GUI. A small subset of people with an impeccable ability to work with 3d stuff in their mind might be more productive in code... till they have to collaborate with others who can't compute a chain of 3 rotations mentally.

trabant00 5y ago

I tried to write my documentation, CV, presentations, etc in markdown for a few years. It's ok I guess but I was forever dissatisfied with the result presentation. Finally made the jump to latex and I feel cheated for believing it is too complex and not touching it for all those years. For example https://latex-beamer.com/ https://latex-beamer.com/ for presentations is extremely simple, you can be productive with it in 2-3 hours. Give latex a try, forget markup languages.

twobitshifter 5y ago
I had a similar problem with my markdown CV. The layout was never quite right and it was a lot of iterating to get even that far. I ended up just using pages, which I hardly know, but could get to do what I wanted.

pkdpic 5y ago

> you should always use the weakest technology capable of solving your problem I knew there was a reason I got on HN at one in the morning. Pointless night redeemed. Also duh I guess, Im just stupid.

tommyage 5y ago

If you use latex as your input, you benefit from a nicer layout and have the option to handout pdf's to content maintainers in a professional format.

twobitshifter 5y ago
Pandoc can output the same professional pdfs.
approxim8ion 5y ago
LaTeX is terrible for writing in flow though per my understanding. Too much markup language.

Veen 5y ago

As a copywriter and technical writer who has to deliver content in docx files with custom styles for each client, Pandoc is a life saver. I can write in Markdown and run a script that outputs a (more or less) correctly formatted docx file and drop it in an email or upload to Google Drive. But the fact that I have to do that reveals the limitations of the plain text everywhere approach. My clients don't want markdown and they wouldn't know what to do with it. They want Word and its revision and editing capabilities, and they'd almost certainly fire me if I insisted they used Git instead.

wildmanx 5y ago
I've wondered about this many times -- your conversion is a one-way street, right? Let's say you have your source material in MD stored in Git, convert it to docx and send it to your client. They use Word to make annotations and revisions and send it back to you. Now what? How do you get this back into MD and your Git repo? Of course you can do this by hand, but that's terrible work. It certainly is worse than staying in the Word ecosystem and flying with it. Not that I'm advocating this, but I don't see how "backporting" their proposed changes into some local Git branch in MD scales. So, I'm curious about your solution to this.
- deleted 5y ago
  [deleted]
- leephillips 5y ago
  I’m in the same boat, often, and there is no solution. I do the original writing with Pandoc/Markdown, but I’ve resigned myself to working in the client’s format for subsequent revisions. If a revision requires a lot of new content, I write that again in Pandoc/Markdown and paste in the converted result.
- marcosdumay 5y ago
  Oh, the Word "mark changes, annotate and pass away" model of change control doesn't work when everybody is using Word either. It's basically deeply flawed, and once somebody decides to go through that road, your best bet is to read the annotations and redo them manually on the original document. That works about as well if your original is in Word or any other format.

throwamon 5y ago

> you should always use the weakest technology capable of solving your problem Wrong, you should always use the technology capable of solving your problem that's also the least amount of work. Very often that's a technology that solves a more general problem, of which yours is but one. And very often it has UX that normal people actually understand.

cracrecry 5y ago

The first thing that I see again and again here is using the term "Marketing" wrongly: Marketing is not sales, marketing is not Advertising. Although usually the "Marketing guys" also handle sales and Advertising, marketing is the study of markets, discovering the desires and needs of the people, it is not about how to force people to buy what they don't want or need. Good Marketing people do not sell you something that you don't need or want, but they know much better than you do what you need or want because they have studied that and they are good at it. Most times they don't even sell, they create and design a product or service because they know it is necessary before it exists. A great product or service for the right market like Pong the original game, the first desktop laser printer or the Iphone sells itself with little effort. People like software developers overvalue what they create for the company and undervalue the work of other disciplines. In fact every department tends to do that with other departments. I am an expert on Tex and LaTex, emacs and Vim, Lisp, and C derivative language programming and Unix systems although I am now entrepreneur. To say that using those technologies is simpler is forgetting all the time that you invested learning those technologies. In my case, decades. You know when you need to teach someone a technology like Markdown, you enter the rabbit hole of having to teach them to use Vim, or even installing a webserver so they can see in a beautiful way instead of ugly text, or even installing a Linux on a raspbery pi, and apt-get, and sudo and ls...

unfocussed_mike 5y ago

While I share some of his enthusiasm (albeit not particularly for markdown tools), I'd observe that considering the rich content produced by the editor, Wordpress.com content is pretty exportable as WXR, and once into a self-hosted WP install is _very_ exportable; there are all sorts of tools to get at WP content in different ways.

zokier 5y ago

Plain text is a mirage, in practice it is not super well defined. I find it funny that we have here lauding the simplicity of plain text while there is right before this a thread about CR/LF. Practically you are always going to reach beyond just simple printable characters, and the moment you do so you fall into a pit of complexity one way or another. Regarding Markdown, using * for instead of is not significantly simpler conceptually. Indeed I'd argue parsing (or rendering) markdown is not simpler than doing so for equivalent html. That is to say that markdown does not provide any level of abstraction over html, instead it is merely a syntatic transformation.

bradstewart 5y ago
For the purposes of this article, the author seems to treat writing Markdown and HTML files as equivalent--both are plaintext. > And similar is the case with simple static HTML websites - a simple static page is better than all publishing platforms that can ever be created. The content in both of those formats can be read by anything that can read text, in contrast to something like Wordpess which requires a database and large application stack to view its content.
AnIdiotOnTheNet 5y ago
Even for printable characters complexity increases significantly as soon as you permit anything other than ASCII latin text.

Brajeshwar 5y ago

I got out of WordPress after about 18 years with it. I wrote about it at https://brajeshwar.com/2021/brajeshwar.com-2021/ https://brajeshwar.com/2021/brajeshwar.com-2021/ However, when I suggest blogs for other people, the default is WordPress. I'm still navigating and learning the ideal, simplified, pattern with text files without the need to rely on any further complex tools.

eternityforest 5y ago

I don't really ever consider simplicity when choosing tech. I consider standardization. If a text file is the standard, I'll use that unless there's a reason to do otherwise. If a million line framework is the standard, I'll start my search there. Text files don't scale that well. Just try changing one value in a megabytes file. There's no tools for that really. You'll probably spam the disk with a megabyte of data every time. SQLite is about as easy as text, and scales way better. And it already exists. All the complexity is not your problem. They don't even accept contributions. I'm generally biased towards do it all systems if there's no major performance or development time penalty. Complicated tech can be one size fits all and refined over the years. Simple tech encourages ad hoc solutions, pushing the complicated part into YOUR project instead of in an open standard with thousands of devs.

selestify 5y ago
Similar to how Flask apps often end up becoming just as complicated as Django once the app grows beyond a certain size. Except that now you don't have the benefit of standardization that Django provides, because you reimplemented everything in a custom way.
trasz 5y ago
Problem is, eventually you will have to debug stuff. That's when simple solutions start making difference.
- eternityforest 5y ago
  I'm not so sure about that. Complex solutions are mostly prebuilt, and used by thousands. When any one person solves an issue, that's usually the end of it, so it gets more reliable over time. Even Windows seems to have gotten better. Simple solutions still have a nontrivial amount of code(Otherwise the whole project would just be "use this turnkey app"), but the code is original. It's probably still going to need debugging.
  - trasz 5y ago

YEwSdObPQT 5y ago

One of the problems with text files and the philosophy of chaining little tools together to do something is that what usually happens is a rube gold-berg machine of little dependencies you have to manage to keep things working. I could spend time working out how Jekyll works, writing a script to deploy the changes and managing changes with git. Alternatively I could just spin up a wordpress instance on a VPS in minutes and start publishing content. Sometimes the "unix" way isn't the simplest way. Sometimes having a product that already built for that task that is paid for is simpler and a better use of your time. I like git, markdown files and pandoc for docs and might even use hugo for really simple sites and use some bash / powershell / batch scripts. However if you work with anyone than yourself you will have to document how it works otherwise they will most likely be clueless as to what you have done. Even in dev circles. Most "dark matter" developers are reluctant of using a command line and only learn what they need to learn to get by. Many just do everything in the IDE and are completely lost outside it.

bodge5000 5y ago
I do agree with the author, that you should use the simplest tools you can get away with, but (text-files + jekyll + this + that) isnt just text files, as you say its a precarious stack no less complex than some software package or whatever. I guess if you do just want the truly simplest tool for a website, html is probably better than text files, even if it is a bit less ergonomic to write with
- YEwSdObPQT 5y ago
  > I do agree with the author, that you should use the simplest tools you can get away with, but (text-files + jekyll + this + that) isnt just text files, as you say its a precarious stack no less complex than some software package or whatever. They are advocating for sellotaping tools together to build a workflow near the end of the article. > I guess if you do just want the truly simplest tool for a website, html is probably better than text files, even if it is a bit less ergonomic to write with Writing HTML when you are trying to write content is pretty painful. Way back in the distant past I used to charge about £100 a HTML page. I ended up learning Perl (and later PHP) so I wouldn't have to write HTML.

smm11 5y ago

My concern is nearly 40 years of writing, that I want to live on long after I've gone just in case anyone cares about it. Plain text files.

axiosgunnar 5y ago

> And similar is the case with simple static HTML websites - a simple static page is better than all publishing platforms that can ever be created. ?

joseph8th 5y ago

Like the author, I also enjoy making things out of plain text. I'm perhaps less evangelical, but after all they are a Vim user, so... ;) My own flow occurs entirely in Emacs, where I write in Org Mode, then build and deploy to GH Pages using Nikola. No more command-line steps for me! And no inferior new-fangled plain-text format: good ole Org Mode stands the test of time.

Jenda_ 5y ago

I don't like these "simple" formats because of non-obvious escaping and overloading too many "common" characters, which is even context sensitive (in HTML, it's just three characters anywhere, & → &, < → <, > → >, and maybe " → " if you use attributes). Even in the provided article, there are many such constructs: - we learn that we need to escape === and --- and ```, but I assume only when it's on a line alone, which seems OK as you probably won't write a paragraph that contains only ``` - then we learn we also need to escape * (e.g. to write 2*2=4), anywhere in the text, but I guess not inside ``` block, so we now need context instead of "find and replace". The escaping mechanism is not mentioned, but hopefully the world has settled on \*, except for dokuwiki which uses %% or whatever - and you need to escape [ and ] (everywhere or only inside link?) - How do you do a link or emphasis inside ```? In some MD flavors, it's outright impossible. (e.g. I need to emphasize something in a pasted code, or I'd like to make a function call clickable as "go to definition/documentation"). In HTML you can use most tags, such as and <a>, inside <pre>