Apple on the desktop is not in a good space. If you take performance out of the equation, the new Pro laptops just look and feel years behind what Microsoft is doing with Windows 11 and the Surface. MacOS was really fantastic a few years ago. It was lightweight and great for development and design. But, now it just feels old and bloated.
I agree, and it feels like a notch on such an expensive device is the perfect troll.
I am happy though that real keyboards are back.. I hope the notch doesn't make it to other devices...
It's my hopes that M1 and ARM in general can make massive inroads simply because of power efficiency, but I hope for it to be done outside a walled garden and I hope it can adapt to the X86 "builder" space... Otherwise its just a matter of time before Intel/AMD catch up (and bechmarks of new Intel leaks appear to be doing well - and i'll be honest, i have no complaints on my current gen intel or amd either)
Strongly disagree. I think there are certainly use cases around video and 3D design that performance is _the most important metric_. But, hardware performance has not been an issue for general computing or software development in a few years. The problem with MacOS is around usability. It is just not on par with Windows 11, ChromeOS, or even iOS. They haven't evolved the software to meet modern computing and it really shows.
Same here. Except for the cable part. I really like Google TV but, I am not going to buy new hardware for it. Hulu is good enough, plus they have some good exclusives coming back.
This. But, I would extend it to say that if you are solo dev it may also make sense to just use base JS to get stuff out quicker. If you have a team, then frameworks start making more sense b/c it extends best practices farther into the app.
Very cool design. Matches well with the name. In my mind, Radicle invokes the design of the 90s (skids, grunge, hip-hop). This isn't quite that but it still works.
I love this stack. I recently added AWS SAM to the mix as well so that I can automate deployments. I have always wondered why Route 53 was so expensive relative to the other services. I have a collection of low traffic sites that I run for local businesses and this is always the most expensive part. I guess it's hard to complain about $0.50. But, given I could probably run them all on $5 DO droplet, it ends up costing a little more.
Google search is broken and it has fundamentally broken the web. Every search now is just pages and pages of content farms. If I can tell a content farm within a few seconds of loading a page, surely Google can as well. So, unless this new "page experience ranking" blocks content farms, then I am not sure how it will be better for end users.
Can you give me an example of a search that produces content farm results? I mainly search for technical docs and such so perhaps I’m not seeing it as much because of that.
Why does google have to explicitly block these sites? No doubt all those garbage, ad-strewn recipe sites rank low on user experience metrics. So if there were a better recipe site out there, Google would show it to you. It seems they (recipe sites) are simply having a hard time monetizing without being uber annoying.
They certainly don't. They are a private company and can do whatever they want. But, Google was much better before content farms. You could find unique, original content by actual people. Google could easily fix this by devaluing sites that mass produce content. But they don't and we are left with the mess we have today.
Exactly. Google enables these content farms making it more difficult for actual people to make money from their knowledge. It is a mess with an easy solution.
Framework churn is real. I no longer recommend JS frameworks simply b/c the opinion of the framework developer drastically changes over time. So, you are constantly re-writing completely valid and working code to keep up with the latest version of the framework. The JS language itself, on the other hand, seems to be very stable with long deprecation cycles and steady improvements. So, it is much easier to build on.
I guess this depends on your definition of "stable". Sure, React code written in 2015 will still work, but it's hardly the "modern" way to write React and if your organization's code was written entirely in 2015, engineers will probably be clamouring to rewrite it.
Taking the somewhat-arbitrary but reasonable standpoint that "stable" means that there aren't any major architectural changes required to bring a codebase up to modern standards, I think the best you can say is that React has been stable since hooks were introduced in Feb 2019. So about a year and a half of stability, which isn't horrible but it's a far cry from stable since 2015.
The key thing for me is that old API is not deprecated, and the React team have publicly stated that they intend to maintain it indefinitely (and indeed are still updating it to work with newer React features).
At $DAYJOB we have no intention to rewrite our older class based code to hooks (except where we're otherwise making significant changes to that bit of code), and indeed we're still writing some new code in the class style.
If you feel like you need to upgrade then I think that on you, not the framework.
Apparently modern housing uses PEX water pipes, but my house has a mix of PEX, iron, and copper pipes. The water flows just fine. I'll probably rip out the iron and copper eventually when I do a major remodel, but I'm not stressing about it.
Agreed with "the modern way" to rewrite React code. Not simply for the sake of keeping current with version changes, but for one, to make sure your engineers are not constantly switching mental models between React Classes, HOCs, and Effects.
Another reason is the ease and speed of online documentation/resources. We all use StackOverflow to get answers and insight into problems we face on a daily basis, and as the framework (or library) progresses, the majority of Q&As adopt it, giving us a wealth of resources at our disposal.
Is the mental model switches between classes, HOC's, and effects really that taxing? Rewriting your code to match the current framework flavor is really less exhausting?
One time work to get knowledge outside your head vs mental notes for context switching while you code? For some people/projects, the first one would be much easier.
Personally I don't find hooks vs. classes much of a context switch. The mental model for the component lifecycle is more or less the same, it's mostly just a different surface syntax (there are a few extra rules for hooks like not putting them in conditionals, but you'd have those in a pure-hooks setup too).
If you understand each approach well enough they aren't context switches at all - they're just different tools for solving a similar problem. If anything, understanding each of them gives you a better understanding of the approach your team has converged on.
Disagree; the "done thing" in React has shifted since then (moving from class-based components and HOCs to functional components and hooks), and in the wider ecosystem, Redux is being abandoned in favor of more React native things like Context.
While React apps in 2015 probably still work with the newest versions of React, you can't put a 2015 React dev in a 2020 project and vice-versa as if nothing's changed.
Hooks are new but they aren't really that complicated. The junior developers on my team were more or less up to speed after a couple of hours reading the docs and a couple of hours implementing their first hook based component.
Our app is still using Redux, so I guess that one hasn't hit us yet (but there's also no real reason for us to update to a newer method).
Sure, it's definitely _peaked_, because there's a lot of other great options in the React ecosystem these days. But, there's still plenty of good reasons to use Redux. And, with our new Redux Toolkit package and the React-Redux hooks API, "modern Redux" code is a lot different than what you've seen in the past, as shown in our new "Redux Essentials" tutorial:
and in the real world react apps use countless npm packages, which get regularly deprecated as react versions move forward .. the real world churn in react land is most unfortunate
How much of an ecosystem do you really need? For me the key component are a state manager (e.g. mobX or Redux) and a Router (e.g. React Router). React Router has indeed been quite unstable, but that's gotten a lot better over the last couple of years. But React and Redux have both been super stable.
As a consultant who often sees existing systems in enterprise environments, react apps often have dozens of additional packages. And the churn on these packages is significant.
React project in the wild seems to exist in two modes from what I can see, the constantly tended garden, or the write and move on and leave it to someone else to rewrite in future (otherwise known as write only, or abbreviated to perl). /s
> react apps often have dozens of additional packages. And the churn on these packages is significant.
IMO that's just poor engineering and not an inherent problem with React. The app I inherited at my current job had many such packages. And we have indeed had to update/replace some of them. However most of them were implementing functionality which could be trivially replicated in "plain react" so we've mostly replaced them with simple internal components and are not anticipating having the same problem in future.
I agree, for a significant portion of the packages yet not all.
Regardless, the diaspora of packages is just common culture in Javascript in the wild. As a reference, I site leftpad. As a remedy I offer the saying 'its better to laugh than to cry'.. :)
Most of the code people have written in Vue 2 is compatible with Vue 3. Vue 3 has just added some additional features. Sure, there are breaking changes, but not to an alarming degree.
Actually React 18 is likely to have breaking changes due to Suspense. Specifically the deprecated methods that are currently prefixed with UNSAFE_ will likely be removed.
This is simply not true. React 15 is not compatible with React 16 and it can even take substantial effort to upgrade if you used componentWillReceiveProps (though which in hindsight could be avoided in the first place)
I did that migration on a very large react project (hundreds of thousands of lines). As I recall, after dealing with warnings for the later 15.x releases, the upgrade was seamless. They're also good about creating codemods to make the transition easier -- something somewhat rare in the world of software libraries.
Organizations love the churn because they can get away with age discrimination lots of well qualified devs are left out to starve to death while constant churn hides a system designed to filter out the most experienced.
That hardly makes any sense. Most widely used frameworks are open source projects; it seems much more reasonable to assume that constant changes in direction are more an expression of developers wanting to play with the fancy new toys instead of sticking with one paradigm and keeping it stable.
Even setting that aside, there's nothing keeping older developers from switching to a newer technology; it might be a bit bothersome to adapt to ultimately inconsequential changes again and again, but that applies to younger devs just as much.
It's also not like web development is old tech in any way. There's constant improvements being made and things are often changing for the better.
Well, for the most part at least. Looking at the situation with serverside resource compilation I have to wonder when the world of web will re-invent make and call it a revolutionary achievement.
I think what is not mentioned with any of the big SPA frameworks is the amount of time you invest in the churn between versions. After dealing with this in Angular for a number of years, I ended up going with stock JavaScript for my recent projects and could not be happier. Performance is much better. I have a better understanding of what goes into the product. And, I am not constantly dealing with a new version and breaking changes every 3-6 months.
I think it is just nostalgia for when the Internet was still young and interesting. Google made it easier and much faster to get to good, useful content. Now, it is just a mess. SEO/SEM folks beat Google. Now, no matter what you search, you either get content directly from Google or one of the thousands (maybe millions?) of content farms hoping to scrape a few pennies from your search.
