jordanlev

This is so wonderful, thank you. Please don't change anything about it (except making the explanation of the channels available in the site's info panel)!

Yes. The other confusing thing about CORS is that CORS is not a protection against anything, but rather a way to UN-protect (in a restricted fashion) the browser's "same origin policy". Same Origin Policy is the protection, and CORS is the way to allow the browser to poke a hole through that in a limited fashion (only for the domains that the original site you visited say it should allow).

I've been using this service for years: https://formspree.io/ -- they do a decent job of preventing spam as well.

I sure am! Introversion doesn't mean you don't like interacting with other people, rather it's that such interaction is draining, and you need to be alone to "recharge" (whereas extroverts "recharge" by talking to others). Even the exhaustion of interacting with people is more of a scale than a binary thing -- I personally find one-on-one interactions much easier than groups.

I am an introvert (although I don't have social anxiety). I work at a company where we pair program every day. I was very nervous about it at first, but I absolutely love it.

Sure, if your coworkers suck it's going to be horrible. But I've found that most people who go into programming are themselves introverts, so as you get to know your teammates and build trust, you know how to interact with each other, take breaks, not talk over each other, etc.

In fact, I think someone who is more extroverted or someone who is loud/obnoxious, would have a more difficult time pairing since it might be harder for them to listen to the other person and step back a bit.

As a counterpoint to most of the comments here: I work at a company where almost every developer pairs all the time. I absolutely love it. I thought I would hate it. I'm an introvert. I previously worked as a solo freelancer and then as a remote teammate. So I was very nervous about this aspect of the job, but figured I'd give it a shot (other things about the job were appealing enough that I was willing to try it out).

Some thoughts based on my own personal experience:

* The biggest win for me is I am much more focused and productive throughout the day. Having an actual person to be accountable to on a continual basis keeps me from meandering down unimportant rabbit holes, unnecessary/premature refactoring or re-organizing, and general procrastinating (reddit, HN, etc)

* Development is definitely at a slower pace on a daily basis than what I'm used to working on my own, but over time I think it evens out in terms of quality of code and maintainability.

* Knowledge sharing is huge -- when I was solo, I could never truly take a vacation because I was the only one responsible for my piece of work. Now I'm on a team where we all pair with each other and switch around every day... if someone is out, it's no big deal. Also makes it much easier to onboard new people (the company I work at is a consultancy so projects are always ending and new ones beginning).

* Despite being an introvert, I feel no more "drained" of energy at the end of the day than I ever did at any other job. One-on-one interactions with people I know and build trust with just doesn't affect me the way other social interactions do.

* Pairing is not a panacea. Some of the comments I've seen here are about how horrible it would be to pair and feel judged all the time or one personality overriding the other... I suppose that's possible but it doesn't happen at my job because my company values and encourages trust. My team is comprised of mature people who all value team cohesion and working together towards a goal over having to be right all the time or proving to someone that we're better or whatever.

* I am never "stuck" pairing with just 1 person for a long time... we switch around every day. I probably pair with any given person only once per week (on a team with 6 developers). But each team has autonomy to structure the pair switching however they want.

Those are just some thoughts off the top of my head. Happy to answer any questions anyone may have (and if it sounds interesting to you, my company is always hiring... we have physical offices around the world, as well as a "virtual office" for remote employees).

I work for a company that takes agile development practices seriously, and I pair program all day, every day. I absolutely love it -- primarily for the reason you cite (I previously worked mostly solo as a freelancer or remote teammate)... having the direct accountability all the time makes me much more focused and productive. (fwiw, I am definitely an introvert, but a one-on-one situation is much easier for me than a group).

My company (World Wide Technology - Application Services) is hiring -- we have some physical offices across the U.S. and a few in other countries, as well as a growing "virtual office" team (which, while remote, is still in frequent communication and pairs remotely). Email me if you want to talk more or be put in touch with someone about applying (my email address is in my profile).

It’s never easy :) In this case though I would try to explore ways to deliver meaningful work to the customer more quickly. Without that quick feedback loop the entire premise of “agile” is meaningless (at that point it's basically just a way to organize your todo list).

Got a link to the podcast? I’m unable to find it in Overcast or Google.

Been reading his blog for a long time, but didn’t know there was a podcast. I’m unable to find it though — do you have a link?

"Throwing together" anything using anything is not really that hard, but understanding the problem, making trade-offs with limited time and budget, writing maintainable and well-tested code, making something easy to use, accessible, efficient... these are all very difficult to pull off regardless of whether you're building a CRUD site or not.

I would also disagree that the web dev learning curve is not that steep... sure to get something to "compile" (well, show up on the screen) is stupid easy (<p>Hello world</p>)... but to actually make a functional, usable, performant, efficient, accessible, beautiful site or app requires managing a lot of complexity across a bewildering amount of environments and tools.

There are lots out there, but the terminology is not consistent so it's hard to identify them.

Perhaps one of these would serve your needs:

https://strapi.io

https://getcockpit.com

> What is wrong, with plain old HTML?

Not specific to GraphQL, but plain old HTML doesn't work when other non-technical people are managing the content of the site. They need a GUI, and hence the need for CMS's in general.

lol, I've been a javascript developer (among other things) for over 15 years :)

The point is that some people/teams/environments prefer to not treat everything as a javascript app. Especially in the agency world -- thinking about one's website from a markup/design-first perspective is a totally viable thing. And if you have designers on your team (or for solo practitioners) you sometimes don't want to javascript all the things. It's great that you found an approach that works for you, but it doesn't mean that it's the only best way for everyone and every situation.

> React (really JSX) solves the single problem of making HTML a part of JavaScript.

This is the crux of the matter. The people who find Vue appealing (myself included) come from the world of design and html+css markup and jQuery. We're not looking to get html into our JavaScript -- rather we're looking to get JavaScript into our html!

There is absolutely no reason to switch from React to Vue if it's working for you (and I don't think anyone in the Vue community would argue with that). But you came from using backbone -- the people who love Vue I think primarily come from using jQuery. We feel the same way about Vue as you do about React, and that's okay! (btw I also use react and also think it's great)

As for staying in React for the rest of your career -- give yourself more credit and hope you'll be around long enough that this isn't true :)

Not all aspects of Shopify can be customized -- especially with the checkout workflow (eg you can only set a logo for the checkout page, but not style it). Also the non-ecommerce pages are woefully lacking in content management functionality (anything more complex than a blog is impossible without using a third-party app to store custom content in meta fields).

And writing apps yourself is not always ideal because they need to run on your own server (thus mitigating the benefit of using a hosted platform to avoid infrastructure maintenance), and any frontend modifications can only be done via JavaScript (you can't modify the outputted HTML itself, so it's a lot more difficult to make robust, performant and accessible customizations to functionality).

> they took advantage of the reporter’s good faith and benevolent motivations.

Someone with truly benevolent motivations does good things because they believe it's the right thing to do -- not because of a monetary reward. I'm not saying they shouldn't pay him more, but I think it's going a bit far to say they're "taking advantage of him".

If I find a wallet on the ground and there's $200 cash in it, I'll return it to the owner and leave all the money there. I don't expect a reward and certainly don't feel like I'm being taken advantage of if they don't give me some of that $$.

A few years back I made a hobby project like this -- it scraped the website of the local free weekly paper (since they have pretty much every concert listing, large and small) and then did a youtube search on band names so you'd see an embedded video or two for each show.

I think most larger cities (and smaller cities if they have a large university) have such a newspaper (e.g. Village Voice in NYC, Willamette Week in PDX, The Mercury in Seattle, etc)

I bought Tracy's "Hello Web Design" book and it's fantastic! I would assume the Hello Web App book is also quite good.

Note to applicants: see the very last item in bullet-list about their definition of "remote". I was told that I am not eligible because I'm 4 hours away from Louisville instead of 3 hours away.

I would have assumed in the context of HN (and StackOverflow, where I first saw the listing) that "remote" means anywhere with an internet connection, not just "working from home but in our city".

I did receive a relatively prompt reply though, so that was appreciated (and it was fun answering their questions).

Uhh, the very next sentence in the article is:

> Floods pose a serious threat to those living in the city, with 61 percent of residents having already experienced water damage to their properties. While rainfall poses a threat from above, rising sea levels threaten the city’s inner islands, which could easily be damaged by flooding if canals overflow.

I mentor and teach a lot of designers and beginning front-end developers. Services like this and FormSpree are a godsend for allowing them to create functioning contact forms on websites without having to go down the server-side rabbit hole.

Also, even though I'm fully capable of building my own form handling back-end, if I'm just building a static site it's nice not to have to deal with all that just for a simple contact form.

Wrong. Tables impart meaning to user agents (browsers, screen readers, google bots, etc) and as a side effect they have a default visual style that is useful for some layouts in some limited situations (but without any kind of fine-grained detail that most modern designs call for -- ESPECIALLY when making responsive designs that work across different screen widths). CSS Grid, on the other hand, is a tool specifically for complex visual layouts which imparts no semantics on the content (so it is proper to use for non-tabular content).

Or use intercooler, which was inspired by turbolinks but is a completely separate (and non-coffeescript) library: http://intercoolerjs.org/

If you have an existing site, then you have a really great advantage (versus building something new): existing site traffic and analytics!

Look at which browsers your users are actually using, and check https://caniuse.com for which versions of which browsers support the new feature. Make a business decision on what percentage of visitors you're okay with getting a page without a nice layout.

If the number of visitors with non-supporting browsers is tiny, then go for it! But make sure at the very least your pages fall back to something where the content is visible and accessible... like make sure it is at least somewhat usable as a single-column list of things.

If the number of visitors with non-supporting browsers is higher than you're willing to lose out on, then still use CSS grid but spend more time on a fallback that looks okay (but doesn't have to be perfect). Perhaps this could be using flexbox (if your users are mostly on kind-of-new-but-not-super-old browsers), otherwise go old-school and use either floats or display:table. (I personally would go with display:table since it's the most grid-like... but depending on your layout it might fall apart under certain circumstances).

Key things to keep in mind are:

1) There are still plenty of people using browsers that don't support CSS Grid. But this may or may not be plenty of YOUR users, so check your actual traffic.

2) You definitely want a fallback of some kind, but the fallback does NOT need to be exactly perfect! "Good enough" is probably good enough.

And hopefully in 3 or 4 years we can forget about a time when CSS didn't actually have any tools intended for page layout :)

Came here to say the same thing! Link: http://www.rifters.com/real/Blindsight.htm

I use both Lyft and Uber regularly, and it's the exact same experience (except that the Uber app/system periodically decides to not process my request for unknown reasons).

Part of the magic of CSS to me is that it doesn't require javascript to work. But loading this site with localStorage disabled just shows a blank white page. So I guess not only is javascript required to render the page, but if it can't store some (what exactly?) data locally then it entirely fails without any kind of warning. Weird.

I agree. But there's a difference between being straight-to-the-point versus "shouting" at people. You can be direct without being mean or belittling about it.

The problem is that often things are not so clear-cut... what seems like a fuckup at first glance or from one perspective might be something different (perhaps one thing is messed up but it was to fix another thing, or perhaps you are mistaken and things are just different but not "fucked up", etc). As soon as you start shouting at someone, they will tend to get defensive and dig in their heels, thus making it more difficult to get to the bottom of what actually happened and why. For most of us in software, our jobs are not saving lives or anything -- it's not worth creating a toxic culture just so you can feel good about yourself by shouting at someone.