Tired of the annual "what do you want for Christmas?" group text chaos? We built WeDo to fix that.
It's a multi-party gift registry where families and friend groups each get their own wish list, but can see and claim items from everyone else's lists. The key feature: when you claim something, the recipient can't see who claimed it or that it was bought—preserving the surprise.
Perfect for holidays, birthdays, or any group gift-giving situation. No more duplicate gifts, no more "I already bought that," and no more awkward spreadsheets.
Features:
- Easy login/invite with passwordless auth (magic links)
- Paste any URL and it auto-fetches the product title
- Race-condition protection so two people can't claim the same item
- Mobile-friendly for shopping on the go
Built with Next.js 16, Prisma, PostgreSQL, and Supabase. Open source and self-hostable.
With the holidays around the corner, we're using it ourselves and figured others might find it useful. Would love feedback from the HN community!
There hasn't been an update to the content here in a little over a year. The owners of the website accept contributions and I'm pretty sure most articles were voluntarily created and edited afterward. [email protected] seems to be accepting contributions to the content that has yet to be added.
It seems that chrome doesn't work at all for me? Any ideas? Everything else seems to be working fine...but not chrome.
The application just doesn't seem to register (the icon remains that of the last app recognized). No amount of focusing Ghostnote, then Chrome, then Ghostnote, changing tabs, or restarting Chrome seem to do any good either.
This is why "the fold" should never be a hard number. You can still design for a larger portion of the initial viewport with percentage based "folds" (along with content).
No problem, man. It's a shame that HN doesn't have two-way binding on these comment forms. I have a hard time visualizing what my comment will look like. Hope it looks good!
The usefulness of two-way binding is utterly boundless. Simply an amazing pattern that any and every one should implement at least once in their programming career.
Those companies are investing in that framework. It's currently in the form of a bunch of drafts on W3C. Web components and the shadow DOM are a few that embody what you're talking about.
I completely agree that with the right candidate this could be great -- however, that can be applied to almost any area of knowledge.
I've been fed up lately with all the wrong people learning to program for the sake of learning to program. While I do agree with the fact that it's a very important skill, I also think that physics, mathematics, and so many other ones are too. If I came across a program like this for "serious mathematics" or "astrophysics" that was promising job placement after 12 weeks, I'd call the same.
You should learn something if you genuinely want to learn it, not because you think you'll make money, or if it's really means to an end. I feel that these "learn to program in a matter of weeks" type programs just encourage this behavior in too many people (and also attract them).
12 weeks is hardly enough for foundational programming knowledge -- and cramming more hours into a day may have more negative effects than positive. Above everything else, everyone learns differently and turning education into a sub-par web programmer farm will certainly impede on others' quality of learning.
If this instead went the route of hiring a one-on-one tutor (with an indefinite period of service) I think I'd have higher hopes. I have no doubts that you'll have some bright guys come through your program, but I can guarantee there's going to be a whole lot more of 'em with the wrong mentality -- which will be to their detriment, and possibly yours.
As for your friend JP, no, I do not think this will make his future worse.
I shed tears for the companies that hire the "graduates" of this "start to finish plan."
I don't care how good of an instructor you are, you cannot make a programmer remotely efficient in HTML5 (primarily the countless APIs involved), CSS3, AND JavaScript in only 12 weeks.
I don't know how that job placement is going to work -- but unless these learners start as interns, I don't know how beneficial this would be for them.
There's "jumping into the deep end" and then there's "jumping into the Atlantic." I get a sense of the latter with this program.
What's the deal with these posts? First the one from Facebook and now this one?
If it's too hard for you to differentiate between a scroll and a touch, there's about 210923423234 libraries out there that can make that differentiation for you.
Is it just me, or did a lot of this come off as "why can't everything be done for me?"
The fact is, performance can never be ubiquitous, because there's always going to be many manufacturers with many different devices -- that while all implementing the same standards, handle things differently.
This problem is alleviated by the age-old web term "graceful degradation," and when done right, can be exactly that -- graceful. That's too hard though, right?
Developing front-end for the web is hard, and developing for the front-end of the web WELL is much harder. I always hated Facebook's app because it wreaked of shoddiness and flaunted it's lack of thoughtful development.
I can't help but feel that they went and hired a bunch of brilliant programmers that had zero experience developing for the web. Developing a front-end web app can be (and often is) a horrifying thing to any developer, because the environment is so volatile (and really, unlike any other development environment).
I'm extremely disappointed in Facebook because had they done things right, it could have been an awesome thing. Instead, they released a shitty hybrid app that was doing everything wrong, and then gave up and wrote this whiny and semi-ridiculous list of what they want because "things are just too darn hard."
The best possible way? Well, that's not true at all. In fact, that was even faster* than whatever method this article was talking about (genDom).
Either way, my point wasn't to say 'just toss it all over to jQuery!' My point was, if you think this technique is cool, you're probably using jQuery and you could've been doing this for years. Years!
Anyhow, this is a huge deflection from what I was really trying to convey. Basically, I don't think this (the 'sugared dom' method from the article) is solving anything. HTML should define your markup and JS should just be filling in the blanks (and not creating them).
*Please note that I do realize my DOM creation was particularly minimal (however, hardly differing from the 'sugared dom' test mentioned in the article) and is hardly a sufficient test. Really, I just wanted to show that you'd have to be doing a ridiculous amount of DOM manipulation to see any significant drop in performance.
This is, in my opinion, even worse than writing straight HTML in JavaScript. Before I get into anything, I just want to point out that with jQuery, you can do the same thing:
I'm not one to condone the over-use of the bloated jQuery, but in this case I sure would.
Anyways, my biggest gripe with this whole thing is the fact that writing any markup in your JS, or anywhere other than an HTML file, is just plain ugly. Beyond that, it's a pain to manage, and totally screws up the whole "separation of duties" paradigm that the web community seems to be quickly forgetting as of late.
Keep your markup where it should be, in your HTML files, because as we all know, HTML is XML and XML is meant to give semantic meaning to data. JavaScript should be a means of transport for data to its relevant structure, not means of giving visual structure to data. Leave that to the HTML and CSS.
Even templating doesn't do it for me 100% of the time and there are better ways. I'm a heavy believer in separation of duties, and any JS programmer should be too. Every time I come across any heavy-handed DOM manipulation in JS I cringe.
As for this article, there's 523637483723526334632 other libraries/frameworks/micro-frameworks that do this same thing, and if you're going to do it, just use what you're already probably using: jQuery. You're probably already abusing it anyways.
Any half decent programmer uses algorithms everyday without even knowing it. Algorithm is just another word that encompasses a massive subset of other words that in reality DO NOT matter. A word is of no use if you don't know the definition, but a definition is plenty useful all on its own.
I think that's where people get scared. Just look through many of the examples above and you'll be surprised. There's no mystery to them, and I'm sure many of you (conscious of it or not) have implemented many of those many times.
Algorithm is efficient and concise code. All the different names and acronyms flying around are just a way to apply your efficient and concise code to a particular problem.
The seemingly tougher algorithms make so much more sense when they are applied in a situation of your own. If you start becoming conscious of your uses of code, it'll all get easier.
I'm sure you're doing just fine, and if you stop thinking of the word "algorithm" as some deep dark abyss of complex problems and knowledge, you'll discover it to be something that you may have done before, or it'll be something new to apply to your next project.