Show HN: ClarifyJs – Overcoming Limits of JavaScript Method Chaining
1–10 of 18 posts
Re: Show HN: ClarifyJs – Overcoming Limits of JavaScript Method Chaining
#2Yet another layer to go through when debugging. Wonderful! /s
Re: Show HN: ClarifyJs – Overcoming Limits of JavaScript Method Chaining
#3Could see this work nicely for testing :) Does make it a bit tricky to reason about code if the execution order is not clear
Re: Show HN: ClarifyJs – Overcoming Limits of JavaScript Method Chaining
#4If it meets the guidelines, this might make a good 'Show HN'. Show HN guidelines: https://news.ycombinator.com/showhn.html
Re: Show HN: ClarifyJs – Overcoming Limits of JavaScript Method Chaining
#5If it meets the guidelines, this might make a good 'Show HN'. Show HN guidelines: https://news.ycombinator.com/showhn.html
Thanks! We've updated the title, which we're happy to revert if the submitter objects.
Re: Show HN: ClarifyJs – Overcoming Limits of JavaScript Method Chaining
#6Interesting intellectually but I’d say the problem it’s trying to solve as illustrated in its readme is just poor application design.
Streams, events, etc have all solved this problem without repurposing existing syntax to “fix” a round peg by making it square.
Clever though.
Re: Show HN: ClarifyJs – Overcoming Limits of JavaScript Method Chaining
#7The example with the message could just be msg('hello everyone').to( list).except('John').send().then... where send() returns a promise. That is, the message creates an object that is getting modified until it hits the send method and then it is done.
Maybe it is just a too simple example to get a point across, but I would want to see an example where this would not work.
Re: Show HN: ClarifyJs – Overcoming Limits of JavaScript Method Chaining
#8Yet another layer to go through when debugging. Wonderful! /s
I don't know why you're being fight clubed, this is a serious concern.
The places where this comes in handy are already prime candidates for bug hiding locations. Adding this in might remove some of those, but if the cost is that debugging what remains is significantly more difficult, then is it really worth it?
Re: Show HN: ClarifyJs – Overcoming Limits of JavaScript Method Chaining
#9The example with the message could just be msg('hello everyone').to( list).except('John').send().then... where send() returns a promise. That is, the message creates an object that is getting modified until it hits the send method and then it is done. Maybe it is just a too simple example to get a point across, but I would want to see an example where this would not work.
Agreed. The builder pattern is well established and useful, and is a lot simpler to understand (and less bug prone) than what is being proposed here.
Re: Show HN: ClarifyJs – Overcoming Limits of JavaScript Method Chaining
#10The example with the message could just be msg('hello everyone').to( list).except('John').send().then... where send() returns a promise. That is, the message creates an object that is getting modified until it hits the send method and then it is done. Maybe it is just a too simple example to get a point across, but I would want to see an example where this would not work.
My impression is the goal of this library is to make it a little cleaner than the builder pattern because you don't need the `.send()` at the end. Arguably, it's nice to make the syntax a little more concise if the library is there to hide all of the complicated details from you.
That said, I get uneasy when reading code like the example
send('hello everyone!').to('friends').except('john');