vcarl

Chromium dev tools essentially IS an IDE with a built-in debugger. You can set breakpoints, step over/into/out of code, monitor network requests, view/edit the DOM tree, edit CSS in real time... For some code, you can even edit it while it's executing. Plus it exposes a REPL at window scope.

100% agreed. Webpack 2 is going to be a fairly sizable change, but for the better. I've been following the webpack meeting notes, pretty excited to see where it's all headed.

> JS is actually a crazy powerful functional programming language in disguise.

I feel the same way. And since you can write a cruddy jQuery mess that fetches data and spits out to backend-as-a-service providers, Javascript is hands down the easiest way to go from nothing -> project others can use.

The ecosystem is in a bunch of growing pains right now, but if you don't care about maintainability and scaling up to a large project, just throw up an HTML page with some styling and javascript that makes it interactive.

It's not going to kill professional photography, but the folks who buy a DSLR for the bokeh might not have a reason to buy that camera. Might shrink the market for DSLRs.

They're even a YC company!

I love that Africa is the highest continent (at time of posting) for "learning" and "opportunity." I've seen some articles about entrepreneurs in various African countries and it's always amazing how much impact they're able to have with limited materials, and access to the web can get you a lot.

But when you come across a Torx screw, I bet you're really happy you have the configurable screwdriver.

>I think this is where starting out small and simple usually works.

Very much agree. Make something quickly that somebody really likes, and try and find more people who like it. Figure out what people like about it and expand in that direction. Rinse and repeat, as you expand just keep making sure more people want it.

> We had to write in the most passive tense possible. That’s why you’d see headlines that appear in an alien-esque, passive language.

I was just thinking that the Facebook summary headlines are surprisingly journalistic compared to Buzzfeed, Upworthy, etc. Seeing somebody complain about that explains why their title is "news curator" and not "journalist."

This is an edge case of one of many libraries that attempts to make form handling simpler. It's well known that rapid rerenders of complex components is bad for performance, rendering 83 form elements every time a key is pressed is obviously not going to do well. There are ways to mitigate this (like debouncing the keypress handler), but this issue alone doesn't mean React can't handle large forms.

Agreed, as much as I support the ideals of the EFF, this kind of misleading scare tactic really rubs me the wrong way. It feels like they're compromising the moral high ground in order to elicit a larger response--which I understand might be the straightest path to accomplishing their goals, but it feels dirty.

I'd say it's a good idea to get enough familiarity with code to be able to distinguish between good and bad code, and to be able to have a rough idea of whether something is well architected.

Spreading vision is an important nontechnical skill for a founder. I see this as distinct from but related to networking, being able to convince talented people to work for below market because they earnestly believe in the vision is crucial at early stages.

As a technical person working on a startup, I personally would appreciate a partner with more familiarity with the regulatory aspects of starting a business: filing paperwork, basic accounting, taxes, etc.

I also wish I had better Excel chops to better analyze data coming in (signups, revenue, expenses, etc), but am too focused on more technical areas to devote time to learn it.

I'm sure there are other skills that I'm forgetting in the moment, but that's a few anyway.

This seems like a great style, but it's not going to catch on because it's a separate dependency. If this were distributed as a configuration file for the most commonly used linters, I'd be interested. Since it's its own linter with its own plugins etc, hard pass.

This is the problem with lots of companies making their own bots--it doesn't actually make people's lives easier, it just shifts the problem. We don't need a bot for each business and service we use, we need well architected, well maintained, well documented APIs for each. If you have a good API and good brand awareness, you don't need to follow the fads; the community will do that for you.

Agreed on On The Media. It's basically just meta-news, but stepping back and looking at the narratives being presented is really interesting. Their recent show about this history of political polling was fantastic.

Additionally, React is intended for highly complex, highly interactive applications, time-to-content is less important than on, say, a news reader. It might take 2 or 3 seconds to get the first page, but once you're there your interactions will be quick. Even if you do code splitting, well-bundled code will have a "commons" chunk, so fetching a new page won't redownload React and other large libraries.

There's interesting work happening with tree shaking, which allows you to do static analysis at compile time to remove unimported code. The new JS `import` syntax is specifically designed to enable this, so it's just a matter of time until tooling and libraries catch up.

I try to shoot for meaningful individual commits, squashing to get the intent of each change (more or less) self contained. I've found it really helpful if I ever need to `git bisect` to find what introduced a bug, I get a small(ish) commit that only affects a single module. Very helpful when debugging code I wrote last year.

Slack offers markdown, message editing, emoji reactions (which I use the hell out of, one of my favorite features), large snippet sharing, link previews, in-app gif/youtube previews, don't need a logger for scrollback...

I love IRC, but the features don't compare. You might be able to implement some/most/all of the missing features, but they're not available out of the box.

It throws off my reading if I'm just checking that I know what something is and only need a quick skim to verify that. I immediately lost track of what was the explanation and what was the original text.

With Venmo/Square Cash, I find myself paying people via app more than anything. Forgot your wallet at lunch? Splitting up bar tabs? Our landlord wants a single check, and paying my roommate rent via Venmo removes all the pain of handing him a check (he was terrible at depositing them) without needing to carry around a few hundred dollars in cash every month. These apps have been available for years, and it's easy to get it set up to pay/deposit directly to/from a bank account, which makes transactions free. Cash is no longer the most convenient way to give friends money for me.

I'm also waiting for panhandlers to figure out Square is free, assuming they have a smartphone. "Sorry, no cash" stops being the end of the interaction if they start taking credit.

I agree, a better process than voting would be "evaluate the advantages and disadvantages of each practice and determine which results in the highest quality, most maintainable code."

But since when have we been any good at identifying future needs or identifying maintainable code? Just be consistent, try to at least leave SOME documentation for the next guy, and don't be actively malicious.

It doesn't make it less valid, but "is JSX bad" has been done to death. It's been the subject of Medium posts like OP since I started using it in 2014. If you're "ramping up a team that's unfamiliar with JS and React," maybe you should be deciding whether to hire somebody experienced with JS and React instead of deciding whether or not to use JSX.

But optimizing for those with no development experience isn't one of the goals of React. From the "thinking in react" page in the docs,

"React is, in my opinion, the premier way to build big, fast Web apps with JavaScript."

Nowhere in the documentation does it stress that it's easy to learn or ideal for beginners. If you don't know Javascript, writing React applications (or any application, really) is going to be painful. Full stop. JSX adds cognitive load when writing code, but reduces cognitive load when comparing the DOM to the component that created it. Given the amount of time I spent debugging and refactoring, I'm happy to use JSX.

It was discussed a long time ago. Some googling found this very old link

http://facebook.github.io/jsx/#why-not-template-literals

Seriously. If you like it, use it. If you don't like it, don't use it. If you work with a team, take a vote.

This post spends quite a bit talking about beginners who are learning Javascript, React, and JSX all at once. Of course they aren't going to get it right immediately, if they didn't get tripped up on JSX they'd get tripped up on something else. "Beginners don't get it" might be the weakest argument I've heard so far.

If you compile ahead of time, you can tune your optimizations. With the right tooling you can tell the compiler that a certain path is hot and should be optimized from the beginning, or catch deoptimizations better, or just get rid of the compilation cost. Right now I'm not sure how much practical benefit there is, but there's a lot of potential.

It would be great if that were how it was taught, but when I took the class it was taught as a trick. No theory behind it, just the prof on the board saying, "But look! :swap: And now you can integrate it."

I remember a similar problem in Calc 2. I forget the specifics now, but I think it was an integral of some combination of sin/cos that ended up being circular. You had to recognize an opportunity to swap one of the steps for an equivalent, which would lead you to the final solution.

Fair enough, low latency, high interactivity applications aren't well suited, but those will always benefit from being as "bare metal" as possible.