Hacker Newsnew | past | comments | ask | show | jobs | submit | moretti's commentslogin

Thanks to the Vite team for building a faster, modern bundling solution on a fully open source stack that isn't tied to a specific framework...cough cough, Turbopack


It looked okay until I scrolled down to the browser compatibility table and had to tilt my head to read the vertical text


Can anyone confirm if the final build number is the same as 12.0.1 RC2 (21A559)? You can run `$ sw_vers` from the CLI to check it.


Yes, it's the same build version


I use Copilot mostly as replacement for intellisense and macros. It helps me automating repetitive tasks. I would never trust Copilot for an algorithm or a snippet, I mean I would treat the code just like anything taken from StackOverflow or Github.


yarn 2 solved real problems with zero install and advanced PnP. Maybe the only problem was that it was released too early, wasn't mature enough when it came out. Now it's just better than v1 and npm, works particularly well on large mono repos where upgrading a package can often break other modules due to how node_modules hoisting works.


The problem with Yarn 2 is that it wasn’t Yarn. You can’t change the whole thing and keep the same name. They thought people would just keep using Yarn out of inertia. That’s not how it works.


That's what the "V2" signifies: a major, (potentially) breaking change.

I'm not surprised nor upset that V2 is radically different. It's all in the versioning scheme!


Eh. They're allowed to do that as per a literal definition of semver, but they turned it into a completely different tool with completely different usage patterns and use cases. It's one thing to have to make some small tweaks to handle an isolated breaking change in a dependency. It's another matter entirely to have a perfectly good core part of your stack deprecated out of the blue and told that you need to rewrite every line of code that it touches.

I see this as analogous to the Angular 2 situation, except that Google actually did a good job maintaining Angular 1 (retroactively named "Angular.js") for a number of years afterwards and providing a solid migration path. Everyone who had staked their projects and businesses on the future of Angular 1 was understandably annoyed.

All that being said, while I have problems with specifics of their approach, I actually think Yarn made the right call on this. After NPM caught up with v7, it became a bit of a wasted effort to have two redundant projects that were almost drop-in replacements for one another. Yarn staking out a different path at least justifies its continued existence.

What I think could have been better is if they'd put an explicit acknowledgement in the migration docs that Yarn 2 wasn't going to be a good fit for all users of Yarn 1, and a recommendation of NPM 7 as an alternative successor to Yarn 1 for such users. An even nicer gesture would have been if they'd written an alternate migration doc for Yarn 1 -> NPM 7.


It's more than that. It broke working projects because v2 was opt-out, not opt-in.

If they'd made a new tool/project called "yarn2", leaving "yarn" alone, that would've been fine.


It’s opt-in though?

You install it into your repository, and it gets vendored.

The yarn 1 binary on your machine will use yarn 2/3 if it’s in the repo, otherwise it will just run yarn 1 as normal.


it has a microSD card slot: https://www.steamdeck.com/en/tech


They slow down the phone after an unexpected shutdown, when the battery is unable to deliver the necessary peak power.


It’s interesting that you find this “simpler”. One of the great advantages of React is that is declarative, it’s easy to understand how a component will render given a set of (props, state). Your example is quite the opposite, the render method violates this principle and each event handler manipulates the DOM using a ref. I’d call this spaghetti-React.


Did you miss the fact that this component is interactive? You can't do interactivity declaratively.


By declaratively I mean that in React you typically declare how an element should be render given the current (props, [state]).

For example, in vanilla JS, you might have something like:

  const btn = document.createElement('button');
  btn.className = 'btn red';
  btn.onclick = function(event) {
   if (this.classList.contains('red')) {
     this.classList.remove('red');
     this.classList.add('blue');
   } else {
     this.classList.remove('blue');
     this.classList.add('red');
   }
  };
In React instead:

  class Button extends React.Component {
    state = { color: 'red' }
    handleChange = () => {
      const color = this.state.color === 'red' ? 'blue' : 'red';
      this.setState({ color });
    }
    render() {
      return (<div>
        <button 
           className=`btn ${this.state.color}`
           onClick={this.handleChange}>
        </button>
      </div>);
    }
  }
I find it simpler to understand, because render, given its state, describes exactly how the UI should be.


This only works for simple cases. Where this breaks down is when you have to inspect the current state of the DOM before deciding what changes to make to it. Example: scroll an element into view if it is not already visible. More examples: drag & drop, interactive resize, etc.


Redux is not an implementation of Flux. These two blog posts explain the main differences: https://code-cartoons.com/a-cartoon-guide-to-flux-6157355ab2... https://code-cartoons.com/a-cartoon-intro-to-redux-3afb77550...


Redux absolutely _is_ an implementation of the Flux Architecture. I've described it as "Flux taken to its logical conclusion". If you read my post "The Tao of Redux, Part 1 - Implementation and Intent" [0], I quote several comments and pieces of early documentation that back up Redux's Flux heritage. Redux inherited the idea of plain action objects with a `type` field, action creators, and the concept of "dispatching"

[0] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao...


I stand corrected. Thanks for these posts!


This is also a really good resource: https://github.com/thejameskyle/the-super-tiny-compiler


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: