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. info@mathigon.org 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).
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.
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!
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 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.
I strongly disagree - 900 hours is plenty of time for the right candidate. Granted, you couldn't put my mom or dad in this course and turn them into a front end dev in 12 weeks, but for the right candidate - absolutely. The program runs from 10am - 9pm, six days a week. That's a lot of commitment, and whoever applies is going to want it. So 12 weeks, absolutely.
It's my opinion that front end devs are born front end devs and don't realize it until they learn to program. The position requires a certain attitude and effective decision-making process that not all programmers possess, and it seems like the Catalyst organizers are screening applicants. A good developer can master any API just by reading the documentation - I guarantee they'll teach them that.
I have to admit that I was also skeptical when I heard about this model, but empirically, it works. (We're not the first program of this type -- there are several others.) Learning goes really fast when you have a lot of smart, dedicated people in a room, and employers see value in graduates.
Meanwhile, consider the alternatives available to our potential students. My buddy JP is probably going to be one of our first students. He had the most popular Harry Potter fansite in the 90s, and has run websites for most places he's worked in the last several years. He's gone through codecademy, but his last job was as a delivery guy. Do you really think this is going to make his future worse?
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.
Thanks for the thoughtful response. I'm Tony, a co-founder at Catalyst.
There are a couple of interesting points to address here. One is that having an intense program could have a negative effect. In my experience teaching programming in immersion schools like this one, the students who stayed these kinds of hours knew they were going to work that hard from the beginning and just got more out of the program. I myself learned to code through an immersion school and felt more like I was missing out when went home at 7-8 than anything. We are looking for the type of person who wants this kind of all-encompassing program for 12 weeks.
I also think one-on-one tutors are great ideas, but for me personally being around a room full of other motivated people that are in my same position is so much more motivating.
I'd love to hear about what you think the 'wrong mentality' is. Feel free to ping me offline and let's chat.
Hey Shawn. I've been looking into Dev Bootcamp so to hear about Catalyst is exciting for me. I'm surprised there are several other programs of this type though. Which ones are they?
Not sure if this counts as empirical evidence but I was a Dev Bootcamp graduate. Working full time now. I recognize the deficiencies in my knowledge and experience before anyone else does, and there are many, but I am stil learning and loving what I do.
I'm also a Dev Bootcamp graduate and I work at Hipmunk now as a software engineer. Something like 93% of my class (summer) got hired so I'd say there's _some_ empirical evidence. What kind of engineers we'll be in a year's time will be even better evidence and from my own personal experience, I think the results will be positive.
I help run App Academy (appacademy.io), a similar program also based in SF. For what it's worth, we graduated our first class about 3 weeks ago, and our students have already received offers from companies such as Twilio and Thoughtbot.
Not to mention 12 weeks with 900 hours worth of instruction and projects.
900 / (12 * 7) = 10.7 hours per day including weekends, or 15 hours a day without. These classes better be absolutely riveting to keep a student's attention.
> I shed tears for the companies that hire the "graduates" of this "start to finish plan."
Companies can hire them as interns and pay them as such for a trial period. In the US, companies can also fire at will if the experiment doesn't work out. Moreover, finding front-end programmers is generally hard, so for many companies this is probably a worthwhile experiment.
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.
There's a significant amount of effort put into touch handling on the native side of the world. Browser-based apps shouldn't be in the business of emulating the native behavior unless absolutely necessary. (Unfortunately, it's painfully frequent atm)
You encounter difficulties such as:
* Different behavior across platforms (and risking uncanny valley responses if you don't duplicate it; particularly around scrolling)
* When the browser provides hooks into the underlying native code, the current event structure can't satisfy. For example, `-webkit-overflow-scrolling: touch` fires scroll events erratically on iOS and fails to update the scroll position between them.
* Fun "bugs" such as iOS Safari's annoying behavior of popping down the nav bar when you tap any anchor that has a href attribute - regardless of whether you intercept and cancel the events in either phase.
It's a matter of finding a balance between abstracting platforms and simply exposing their underlying mechanics. I'm not sure which side should win there.
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."
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!