duhi88

Am I missing something? Those diffs look identical.

Edit: got it. Thanks!

Jamstack needs to smooth out the client side of the experience.

Netlify CMS has been great in testing, but I haven't deployed anything to a client with it. I know that, as a dev, I'll never get stuck in a situation where I can't accomplish something with Jamstack (Gridsome is the one I prefer). I just fear the day a client needs to use a CMS and they can't edit/demo something the way the expect.

All these people who "miss Wordpress"...have they ever worked on a WP site that wasn't just modifying an existing theme and installing a handful of common plugins?

Most sites I work on these days are either simple enough to be solved with no-code solutions, or complex enough that Wordpress is going to hold you back.

Why? If they drop their free tier or do something evil, I'll just start pushing my static files elsewhere. Why is that a bad thing?

Even their serverless functions api and DB can be connected to any serverless provider.

Gridsome is the one that I use (VueJS version of Gatsby). What are the sorts of things you found it couldn't do?

I want to get our team using it for simpler projects, and I haven't really hit any blockers with Gridsome, whereas I've hit plenty with Wordpress when we need a specific url structure.

but shorter due to commercial breaks.

Agreed for the most part. Anything where SEO is critical (most things these days), we use Laravel for (trying to move away from Wordpress), with some custom classes to help standardize important SEO stuff.

I haven't had that experience with Hugo, but I pushed the files up to S3/Github Pages/Netlify and had them served from there. I'm a big fan of the concept.

I've had a great time with Gridsome, the VueJS version of Gatsby. I don't understand why, with React, you need to install a 3rd-party dependency just to update your meta tags. Like, it should either be part of your main layout when you set up your site (my Laravel approach), or there should be a built-in configuration for it, like Gridsome has (https://gridsome.org/docs/head/). Every site needs this stuff, so it should be a first-class feature.

For real. Maybe, just maybe, a voice-controlled speaker doesn't need the latest cutting edge CPU.

I wasn't expecting new Homepod hardware until after they announce on-device Siri. That seems like the only thing that would warrant a better CPU.

Agreed. I wonder what the cost is on that chip.

Apple Watch S5 - Sensors + Speaker + Markup = $99

Probably just turning an R&D project into a marketing feature.

Have you tried this with Apple's Magic Trackpad or al=ny other bluetooth trackpads?

What is a non-proprietary solution for full-disk encryption?

Any chance that the Servo renderer could leveraged for cross-platform GUIs as an alternative to Electron?

I don't know if there would be any meaningful benefits over Electron, but I can see why it might be attractive to build everything in Rust. Seems like you could extend Servo with features required by your app, too.

Woah, there. They said they were just learning. No need to purchase special hardware until you're trying to run state of the art models.

You can get very far on any laptop before hardware becomes the main blocker. And before building an ML machine, there are cloud compute options available for far cheaper.

what would be the benefit there? 20GB can't be that much cheaper than 24GB, right?

I'm pretty sure that most developers are not using retina screens as their second display. Maybe things are different in The Valley, though...

But I get it. From their perspective, those aren't Apple screens, so they don't need to support them.

You can use it on your own computer, you just can't publish content with it that isn't iOS-related. They're not going to come knock on your door because you've set SF to be your system font.

Obviously this just comes down to personal preference.

All the major companies have poured lots of money into engineering typefaces specifically for their UI and brand. They're all designed to be easy to read and give off just enough personality to not be distracting. Objectively, I'd be surprised if one were better than another.

I like some of the open source sans serif fonts just as much as Apple's SF fonts. Google's Roboto has a bit too much personality IMO, but it might be better tuned for Android than the web.

Yea, I went down that path, too. Super puts less strain on my fingers, and feels more natural (also, I've been using 95% Macs for half my lifetime, soo...it's a lot of retraining).

It surprises me that there isn't a distro or easy to use tool to use Mac-style keybindings, given the overlap of Macs and Linux systems in tech.

That's kinda been my experience, too. The amount of detail Apple has put into their drivers and software is truly underrated (and overshadows by their more recent scummy business practices).

The surprising thing to me is that most of the small details I rely were in OS X 10-15 years ago. If a Linux distro were created to mimic OS X 10.4 I would be perfectly happy using it as an everyday OS and recommending it to others. I keep hitting dead ends in my research, and it seems like the major desktop environments have a lot of architectural problems preventing them from implementing some basic UX improvements.

The barrier of entry to help develop these features also seems high to me, coming from web development.

It makes their data more accurate, and they can better train their models to identify data unstructured data on all sorts of sites.

If you know Vue 2, Vue 3 will be easy to learn, as well. There are some more advanced features you can choose to use if you want, but I guarantee you could pick it up really fast. This isn't an AngularJS -> Angular sorta change.

Also, give it a few more months before building anything non-trivial. Some of the more popular libraries for Vue 2 still need to up updated for Vue 3 (vue-router, vuex, for instance).

I was surprised that became a feature of Vue 3, as well. I was hoping they would drop it, assuming you could just use Babel + Polyfills to get it to work if you really needed it.

For me and my team, it hits the right balance between Angular's structure and React's no-structure. We can use it for small apps within a server-rendered website, or larger SPAs.

I can hand a project to a junior dev and not have to explain project structure or patterns, nor worry about things going off the rails. Generally, after getting a feature working, most of the feedback I'll need to give is "break this 300 line file up into 3-4 smaller ones". Great ESLint rules provided by the Vue team really help with this.

With Vue 3, with the two APIs, I know that I'll be able to hand a feature off to a developer of any level and know they can accomplish it however it makes the most sense.

I can also jump into a legacy Vue app built by another team and have no issues getting oriented. In my experience with React, I haven't seen the same router configuration twice. Most React projects I've inherited feel over engineered

On a more meta level, I think the single-file API its a much better mental model than React's. Your HTML is still just HTML, and your styles are CSS or Sass, or whatever you choose.It's why I preferred AngularJS over the others at the time.

k.

Clearly not that irrelevant if you're in here commenting.

Thank you for making this cross-browser compatible! I'm definitely checking it out.

Do developers really not care about Firefox anymore? Is it just the younger generation of devs who ignore it, or has everyone stopped?

I guess it's Mozilla's fault for dropping the ball on real community outreach...helping devs build stuff that other Firefox users will use. idk..I just hate seeing all these great tools released for Chrome that _should_ be able to be adapted for Firefox.

If your business relies on your ability to walk in into a store with your shirt off and a mom-and-pop shop denies you access, you can look for one of their competitors. If all the mom-and-pop shops decide have a "no shirt, no service" policy, that rule probably exists for a reason (its a form of democracy).

I don't really care about Epic's stake in the matter; they are clearly making plenty of money. A smaller company with a different idea that treads the line with their in-app-purchases would be in a tough place.

Looks solid. Are you using Nova for the backend?

Also, is this intended to be a thing you buy, fork, and make it your own? Or will it be more like a framework where customers receive updates to the core code?

"Variable bitrate" encoding is a thing, which allows chunks of a file to be encoded at a higher or lower bitrate depending on how much is happening. I don't know exactly how it happens, but I assume that each chunk is determined by duration or size, while Netflix's new method determines each chunk by the content.

In order for this to be the default, you'd need either humans, or pattern recognition algorithms to identify the chunks. You also need to quantify how by how much each chunk needs its encoding parameters tweaked.

Monetary costs aside, that's increasing complexity of your pipeline with relatively small gains. I'd bet that more companies will start looking at similar approaches now that 4K HDR (and 8K) are becoming more common. Probably not worth the R&D for 1080p, but we'll see tricks like this start to trickle down, I'm sure.

It's highly unlikely we'll see anything similar in FOSS tools in the near future.