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

Very simple and well done, I'm surprised how simple the code to generate the DAG is.

I will use it when I have a chance.

I really like the "How to menu", I may recommend to do it a little more prominent on first usages or show me once that it's there.

Congrats!


I second this, I have basically no feeling for it other than zooming in a the README gif


Which is super slow. The first 10 seconds or so are just slowly traversing an auto complete menu.


https://en.wikipedia.org/wiki/Mpemba_effect

This is also an interesting related read, basically hot water my in some circumstance freeze faster that the colder one.

It's even in the related articles from quanta now that I see.


Given the content in the Quanta Magazine article, I would have assumed the explanation was straightforward: the hotter the water is, the more the molecules inside are bouncing around randomly, and therefore more likely to end up randomly entering a configuration that triggers nucleation in a given period of time than the same water at a lower temperature. But I don't even see that possibility discussed in the Wikipedia article. It's such a simple explanation that I therefore also assume it's wrong for some reason, but I'm curious why it's wrong.


We can test to see what freezes faster: cold still water, cold stirred water, or hot water.


This take is completely ridiculous, Google is absolutely not to be trusted in many of this fickle experiments it does and it will hurt them, but putting GCP, a paid system with a track record that powers so many important businesses is just bending the metaphor to a point where it makes no sense.

That said, that's what they get for doing this kind of thing I guess.


Congrats on the launch!!


I 100% know it's a preference/style kind of thing, and I know the React/Node isn't perfect and comes with it's downfalls, but I whenever I have to code in anything other, I just miss the visual/mental model aspect of having your tsx code basically identical to your actual html.

The mental load of going from this to

    func main() {
     component := Page{
      Children: []Component{
       Div{
        Children: []Component{
         Button{Name: "Test button"},
        },
       },
      },
     }
to this

  <Page>
    <div>
      <Button> Test button</Button>
    </div>
  </Page>`
or going from this:

  const main = () => (
    <Page>
      <div>
        <Button> Test button</Button>
      </div>
    </Page>
  )
To, well... case in point, exactly the same thing is just so nice.


Reminds me of https://github.com/8byt/gox which I bookmarked when working with Go but never got around to using.


fair enough, but you're also downplaying/omitting the huge dependency cost of React, both server side and client side. so pick your poison.

you're basically saying "I want server side code without having to actually code anything". of course nothing is going to beat react, its an impossible ask


Maybe it’s me that’s numb, but holy crap people are jumpy and making such a big deal, reading into an ad as if the whole of society’s problems could be decomposed from it. Shitty ad? Probably? Move on.


I love this style of projects, OSS project for a very particular issue.

I keep thinking what can I do in the Typescript/Next.js/React ecosystem that's very useful to a technical niche but I haven't had the inspiration yet.


For anyone reading this since its pretty high, it's one of those cases of really high HN bias, that actually got to me.

I'm not blaming OP, the question seems innocent enough, but I had this bias and some others myself until I used Tailwind for an actual project and have never looked back, and most of the criticism that appears in HN is just misunderstood concepts and harsh sounding soundbites.

I distrust HN's general sentiment on stuff more (if there is such a thing but you know what I mean), I check for myself.

Regarding tailwind specifically, it's the modern way of "just css" which goes amazingly well with having the component abstraction level.

You don't abstract your css, you keep it all in base level, you abstract components, in this particular case you would go to your button component and change all of the application's button at once.


Thanks for explaining, that makes sense. And yes, my question was innocent. I am not a frontend dev, I used to do some CSS and vanilla JS back in the day. Thanks for taking the time to explain it to me!


Creating a component out of everything always sounds good in theory but falls apart in practice. There's always that oddball element that doesn't quite work as a component, and then you end up with a component and a bunch of the outliers that you need to remember to manually update.


This looks very interesting, but I have two questions.

1) Did I understand this correctly, oversimplifying, instead of going api.slack.com/users I go nango.com/slack/users

If I did it leads to question 2) since I assume this won't have feature parity 100% of the times, what's my escape hatch when I need a feature that's available in an api and not in your service, if worse comes to worse, can I still easily access the original api easily?


1) That's right!

2) You can write your own integration scripts, in code, consuming any endpoint from the external API, so you are not limited to what Nango pre-builds (details: https://docs.nango.dev/understand/concepts/scripts).

But you can also access the original API through the proxy, which will inject credentials, log requests, help you with pagination (details: https://docs.nango.dev/understand/concepts/proxy).


Nice idea.

So to recap:

1) Nango supplies easier-use-to-use wrappers over a host of common APIs, making the most common operations simpler. Nango generally handles auth, logging, pagination.

2) Nango is extensible through custom scripts when your use case falls outside the common ones.

Question 1) Nango provides some consistency to the APIs in its wrapper so, to some extent, you are learning the "nango way" vs hundreds of bespoke ways?

Question 2) How do you handle API churn with hundreds of APIs supported? On any given day, there's got to be a decent chance of something changing that breaks you?


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

Search: