cletusw

Source? You can have many buses using a single BRT lane which is much cheaper to build and maintain than the number of lanes you would need to move the same number of people in private vehicles. Even more so once you start building grade-separated highways and their off ramps.

Previous discussion: https://news.ycombinator.com/item?id=48733236

https://Symfonium.app is a good player for Android

In the behind the scenes video the photographer makes an offhand comment that yes, he was going to take the silhouette of the skydiver (and maybe some of the immediate surroundings) and composite it with a mosaic of sun images taken around the same time (but without the paramotor present).

That's the entire point of "war crimes" and "crimes against humanity" definitions like intentional starvation. It doesn't matter what the justification is, they're not allowed by the international law and need to be punished as such in all cases unconditionally.

The difference is for proprietary features, you can just charge that subset of users that care for its maintenance, using that money to hire additional developers, etc. For OSS you instead have a relatively fixed budget of time & resources and have to balance competing interests in a zero-sum manner. On the flip side, there's nothing preventing the vocal minority from forking if the feature is important enough to them!

There are a good amount of lower power ones (e.g. with an N100 CPU) that draw ~15W usually and not that much more at full bore, and some of them are starting to come with USB-PD power inputs (even if they come with a DC power adapter some will accept USB-PD on another port).

Look for "PD in" on this sheet for some examples (columns BW-BY): https://docs.google.com/spreadsheets/d/1SWqLJ6tGmYHzqGaa4RZs...

Ugh, yes. My kids play this one at school and when I read about the game mechanics I was super disappointed. Luckily they stopped begging me to subscribe eventually since I wouldn't budge.

Then middle and upper class people will just keep on polluting at marginally lower rates. The only real solutions to this problem are ones that get the will & finances of the upper classes involved.

Having two completely unrelated UIs – one for mobile, one for desktop - isn't really responsive. When done that way there's some point (e.g. 1199px width in the OP's example) where you suddenly have a tiny mobile web site with a ton of blank space on either side (or worse, it stretches it all out to fit and all the blank space is within every single button and widget).

There should either be several progressively more "mobile" breakpoints, or even better, use component queries so individual chunks of the page can rearrange their contents as their available area shrinks.

This is (was) largely a problem caused by holes in the web platform. Historically it was incredibly hard (if not impossible) to style or otherwise extend the behavior of a true <select>, so most apps had to reimplement it (poorly). <selectmenu> seems to be the new styleable built-in replacement.

And then because code sharing across apps/frameworks/companies/etc was historically very hard, only really big companies had enough headcount to build fully functional, accessible, customizable replacements for built-in components. Web Components solve this, allowing global collaboration on common leaf node components like <select>.

Related: https://blogs.windows.com/msedgedev/2022/05/05/styling-selec...

I don't think vanilla HTML/CSS/JS is the way to go for beginners because of the "time to visually interesting results" problem. Starting with a framework that has widgets you can reuse is much more interesting and motivating.

That said, I'd argue that the selected framework should be one that doesn't completely obscure all the underlying HTML/CSS/JS (I'd avoid TypeScript at first) from them so it's easy to learn that when needed, plus it makes debugging using browser dev tools easier and means they'll have transferable skills for learning a second framework.

GWT (RIP, thank goodness) would be the extreme negative example, but React is on that side of the spectrum as well.

Vue, Svelte, Lit, and Angular seem to be the most popular frameworks on the "closer to HTML/CSS/JS" side of the spectrum, though I only have experience with the last two. Lit's great; Angular's not my favorite.

Please don't do this. This confuses and possibly prevents screen reader users from using your site.

> "I just wanted something that is small and works like a normal HTML element"

My first stop when looking for a web component is always https://component.kitchen/elix because of their commitment to the Gold Standard (https://github.com/webcomponents/gold-standard/wiki), which is basically to imitate native elements wherever possible.

Thank you! I wasn't quite getting the 3rd party cookie vs. actual site visit distinction from their post.

HTML Imports were actually among the first (shipped in Chrome), but then ES Modules/import/export took off and now spec authors want to reconcile the two before standarizing.

That's one of the huge benefits of web components -- third parties can iterate quickly to find useful patterns, then browsers can just standardize the best/most popular ones. The old way of discussing ad nauseam in committee then implementing straight in the browser gave much less useful elements. (And it's much less straightforward to convert a popular React component into something browsers could implement natively.)

Honest question: How is React/vue/etc. different in this regard?

Spelling error in title. Should be ... Electric Thruster

Official SpaceX video: https://twitter.com/SpaceX/status/956236301275054080

More good footage + audio: https://twitter.com/nova_road/status/956221490785026053

Don't miss NASA's incredible CG video of what this was like: https://www.youtube.com/watch?v=xrGAQCq9BMU

Link should be changed to https://github.com/jamesroutley/write-a-hash-table

Sure, it's not as convenient as instant streaming, but the Netflix DVD shipping catalog is unparalleled. Every old movie you can think of plus new releases as soon as they release on DVD. Well worth what I pay since I'm patient enough to wait a couple days for the disk. Plus, if you pay a little extra for the blu-ray service the quality is way better than streaming "HD".

Of course, it looks like all of the breaking changes introduce compile time errors, so if you try it out and it compiles, you're good!

Looking forward to the string enums! I've been using https://github.com/Microsoft/TypeScript/issues/3192#issuecom... but it'll be nice to have this built-in.

I haven't used Flow much, but having used TypeScript at work for only a few weeks we've already found several instances where the type system isn't flexible/complete enough to describe several perfectly valid JavaScript idioms. Workarounds often mean lots of `any` types or tons of boilerplate/repeated code. Not fun. On the whole, though, compared to un-typed JavaScript, still totally worth it. I'd just be interested to see how Flow handles some of these situations.

They did: https://www.youtube.com/watch?v=jC3LQFpuzqs&t=12m19s http://forum.nasaspaceflight.com/index.php?topic=42544.msg16...

This one probably isn't reusable since it landed in the water. Their next goal is to make a floating "bouncy castle" to land it on.

Could be true, but SpaceX President Gwynne Shotwell challenged that report directly: https://www.youtube.com/watch?v=xjXYSJF-7Cs&t=16m31s