Hacker News new | past | comments | ask | show | jobs | submit | djanowski's comments login

I'm surprised such an in-depth article doesn't even mention promises. Upcoming async/await (already available via transpilation) will make error handling in Node sane again.


That's a good first step.

However, flow is more than knowing what you're working on.

Maybe there are techniques to not lose that state of mind so easily?


I happened to be reading The Design of Everyday Things at the same time as Understanding Air France 447. It was surprising to see how the concepts explained in the book by Don Norman applied perfectly to explain the errors made by the pilots -- even though airplanes are not everyday things.


Can you fix the typo in the title?


Thank you!


\o/ Thank you!


Yes, you're right that most frontend developers already rely on Node for various tasks.

This would be most helpful for those who still haven't introduced Node as a dependency and trying hard to get away without it :)

In any case, as I mentioned in another comment, the fact that one can write a minimal preprocessor in ~30 LOC could be useful to start a conversation about the current state of the art regarding frontend development.


That's awesome. Let's keep in touch :)


Both Less and Sass implement features that I consider anti-patterns: nesting, @extend, etc. Sure, you can ignore them, but there's a lot of code in the tool to support that. The code needs maintenance and puts the barrier of entry higher for those wanting to contribute to it. Also, these are first-class features of the tool, they can't be disabled explicitly. So you'd need code reviews and other artifacts to make sure no programmer/designer ever tries to use them. Finally, why would you choose a tool that does 20x what you need, if there's an alternative that does just what you need? (As stated in other comments, I don't mean my solution is what will replace all preprocessors. PostCSS looks like a more modular approach and it allows you to effectively cherry-pick the features you need by means of plugins.)

Also, easy != simple. The fact that a tool is easy to install (after having installed another mega-dependency) shouldn't count as an advantage, in my opinion.


Nesting is the only reason I wish to use any of these preprocessors to be honest. I don't understand how people write plain css when things like less/sass exist. Writing and maintaining css selectors is a nightmare, but it's so simple and intuitive to just nest things inside parents.


I was going to say. How the heck is nesting an anti-pattern? It is SO useful for CSS. It should have been standard years ago. Variables are helpful too.


I don't think you read the top section of the README. It clearly says that I was first looking to write a simpler CSS preprocessor, and then came across M4.

I'm not saying the tool I wrote will replace all preprocessors. My point is: I wrote one with just enough features in around 30 LOC. Can we use that to start a discussion around the current state of the art regarding frontend tooling? Or software in general?


Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: