Hacker News Reader

Comment by phpnode | Hacker News Reader

Here's a PR that fixes this issue - https://github.com/threepointone/markdown-in-js/pull/2

Note that local identifiers (such as vars) mask the import identifier so it will be easy to create a false positive.

It seems like you're looking to find something to complain about. Yes, you generally have to be careful about variable collisions. That is in no way specific to this module and, frankly, is something any competent programmer should be aware of.

It is specific to this project, in that it will rewrite your code to mean something other than what you intended it to mean.

I'm not being critical of this project, I'm being critical of the all too common practice these days of installing a dozen or more Babel plugins to fix every problem that exists, and thus creating your own one-off language that will be unreadable in 6 months.

Babel has become the new hammer in front-end development. Everything looks like a nail.

I really don't see where you're getting that from. How on earth does it "rewrite your code to mean something other than what you intended it to mean?" I explicitly included the "markdown" identifier. What on earth could I have meant otherwise?

How is:

   import markdown from 'markdown-in-js';

   const MyMarkdown = markdown`#Headline`;

any less clear than:

   import markdown from 'markdown-function-tool';

   const MyMarkdown = markdown('#Headline');

It's totally explicit and actually allows compile-time validation. I really don't understand your objection.

This will not be "unreadable in 6 months" any more than JSX or GraphQL are. Since I have plenty of projects that are over 6 months old using those techniques, I'm quite confident they work fine. It's not like there's any magic or implicit references going on.

Because if you do:

   import markdown from 'markdown-in-js';

   var markdown = function() { }

   var foo = markdown` #Header ... `;

It will incorrectly rewrite this template literal. And while they could potentially fill this hole, it doesn't change the fact this is unreadable code; there's nothing from the code that signifies it will be converted into some function calls the way that JSX or GraphQL at least have some visual signifiers.

JSX and GraphQL, I'm not a fan of either, but are at least real projects with standards texts written for. This is not a criticism of this project, but the practice of installing a bunch of AST transforms to save you a couple of keystrokes creates code that reads as 1 thing, but compiles to something much different.

If you don't recognize how changing your code to mean something different based on an AST is essentially creating a one-off language, I don't know how to help you.

> It will incorrectly rewrite this template literal.

That is a bug and should be fixed.

I'm not sure what visual signifiers that GraphQL has which this doesn't.

It's a fairly clear pattern of what's going on. I really don't see what is "unreadable" about it.

It's a leaky abstraction. The point is to make your code do something other than what you described it as doing (because it will do it "better"). That's what makes it unreadable; hiding behavior from code decreases readability.

I'm not that familiar with GraphQL, but as far as I can tell it doesn't depend on AST transforms. It seems to be a DSL that uses tagged templates. There's nothing wrong with DSLs.

Yes, I noted that in the PR. It's easy to fix it, why don't you try?

As noted above, I think the practice of installing a bunch of Babel plugins is the wrong approach to this problem. If you want to avoid parsing markdown in the client, then pre-compile it using one of the million markdown compilers that exist.

merged and published, thanks!

Reply on news.ycombinator.com