As a developer knee-deep in the JavaScript world since around 2015, I’ve come to a rather disheartening conclusion: React, along with the broader JavaScript community, has failed us. It’s been a ride, but one that’s left me feeling more exhausted than exhilarated. The constant yak-shaving, the spinning of new frameworks—it’s become a cycle that’s far from productive.

The Rise and Fall of React

When React first burst onto the scene, it was a revelation. The virtual DOM was blazing fast, and it did a fantastic job of abstracting the messier parts of the DOM. You didn’t have to deal with the blur, and that was great. But as time went on, we realized that loading a file from a server and then running all the client-side processing in a single thread was slow, especially on mobile or if you weren’t on the latest hardware. It was brutal.

The narrative around React shifted to efficiency. With its abstractions, it could be more efficient—or so we were told. And sure, JSX is nice to look at, and for a while, it seemed like a good trade-off. But after nearly a decade, the supposed efficiency hasn’t translated into performance. React, at this point, might just be the most poisonous part of our toolkit, whether you’re using Next.js or, to a lesser extent, Remix with its more web-friendly approach.

The Next.js Conundrum

React has become synonymous with Next.js as the ecosystem has evolved. But let’s be honest, it’s slow, clunky, and creating a good user experience is a Herculean task. There are a lot of blogs and videos decrying the benefits of Next.js, and you might enjoy some of those, if you deploy specifically to Vercel, and only Vercel. But it’s still a heavy rats nest of virtual DOM eating resources underneath all the over engineered incremental cache validation. The cost of using React now far outweighs its benefits.

I’m working on projects in React and Next.js, and I can’t say I enjoy it. Next.js has some APIs that feel obtuse and don’t translate well to other frameworks. So, what do you start a new project in today? That’s the million-dollar question.

Exploring Alternatives

If you’re looking for alternatives, there are options. Laravel with LiveWire, for instance, is a solid choice. Rails with Hotwire, sprinkling in Inertia.js or Alpine.js, or even an Enhanced dev framework could work. Elixir Phoenix is another route worth considering.

To create the best user experience, you’ll likely need a server-side framework. And here’s where I’ll be blunt: JavaScript server-side is a mess. The serverless trend, with its gross abstractions and limitations, isn’t helping. You’re forced to deal with database connections, pooling, proxies, and a whole lot more just to get to your database.

If you’re set on going server-side with JavaScript, maybe Nuxt is an option. Redwood and Remix are mostly great frameworks, but they still rely on React. I wouldn’t start a new project with them, but if you’re shipping and you know React, I won’t tell you not to use them. However, I do hope they fall out of favor. Not because the people working on them aren’t great, but I no longer believe in the core idea of use React and a foundational part of a good web experience. For the developer or the user.

The JavaScript Community’s Identity Crisis

We don’t have a Rails to Ruby or a Laravel to PHP in the JavaScript world. Why? The community is fragmented, with different interests and agendas. JavaScript runs in the web client, attracting a wider array of users, investors, influencers, and bad actors. This diversity is likely why we don’t have a consistent, dedicated framework for the community.

A Plea for Change

In conclusion, serverless isn’t the cost-saving solution it’s made out to be. It’s likely to cost you more in money and time. For your next project, I dare you to try anything other than React or its derivatives, especially Next.js. Let’s break the cycle and explore the wealth of other technologies out there. It’s time for a change, and it starts with our choices as developers.

JavaScript has come a long way since it was first introduced as a client-side scripting language for the web. With the introduction of Node.js in 2009, JavaScript has become a popular language for server-side programming as well. While JavaScript on the server has come a long way in the last decade, there are still several issues that need to be addressed.

Firstly, the performance of JavaScript on the server can be a concern, especially for applications that require heavy computation. JavaScript is an interpreted language, which means that it can be slower than compiled languages like Java or C++. However, recent advances in just-in-time (JIT) compilation and other optimizations have improved the performance of JavaScript significantly.

Another issue with JavaScript on the server is its asynchronous and event-driven programming model. While this model can provide better performance and scalability for web applications, it can be difficult for developers to understand and maintain. The use of callbacks and promises can lead to callback hell and make code difficult to read and debug. However, the introduction of async/await in ES2017 has made asynchronous programming in JavaScript more manageable and easier to read.

Security is also a concern when it comes to JavaScript on the server. Unlike client-side JavaScript, which is run in a sandboxed environment in the user’s browser, server-side JavaScript has access to sensitive information and resources. Therefore, it is essential to ensure that the code is written securely and to follow best practices to prevent security vulnerabilities.

Lastly, the lack of a strong type system in JavaScript can make it difficult to write large, complex applications. TypeScript, a superset of JavaScript that adds optional static typing and other features, can help alleviate this problem, but it requires additional tooling and learning curve.

In conclusion, JavaScript on the server has come a long way, and its popularity shows no sign of slowing down. However, developers need to be aware of its limitations and challenges, such as performance, asynchronous programming, security, and the lack of a strong type system. With the right tools and best practices, JavaScript can be a powerful language for server-side development.

These are all cursory details of JS using something like Node on the backend. All of which are factually accurate sure, but don’t really tell a complete story. None of these I would list as concerns when starting a new backend project in JS. Things like cohesion, interoperability with the data layer and other services, and real testability are the real struggles with using JS on the backend. These are the things that developers are going to run into. The obstacles that will slow them down, cause errors/bugs, and require a lot more attention than they really need to. What isn’t really possible in JS as a backend server is:

rails new project
rails g scaffold DataType
rails db:migrate
rails server

And that’s gonna cost you and the other developers a lot of time and effort on maintenance and away from your core business logic. Not really a good trade off.

I’ve been working in React Native for the last bit, and I have to say, I’ve very much missed it.

function TimelineStackScreen() {
  const colorScheme = useColorScheme();
  return (
    <TimelineStack.Navigator>
      <TimelineStack.Screen
        name="TimeLine"
        component={TimeLineScreen}
        options={({ navigation }) => ({
          title: "Timeline",
          headerRight: () => (
            <Pressable
              onPress={() => navigation.navigate("New Post")}
              style={({ pressed }) => ({
                opacity: pressed ? 0.5 : 1,
              })}
            >
              <FontAwesome
                name="pencil-square-o"
                size={24}
                color={Colors[colorScheme].text}
                style={{ marginRight: 15 }}
              />
            </Pressable>
          ),
        })}
      />
      <TimelineStack.Screen name="Post" component={PostDetailsScreen} />
    </TimelineStack.Navigator>
  );
}

editorial illustration by Karolis Strautniekas and Mads Berg synthwave, portrait of a lonely city, colorful, fine texture,detailed, muted colors,film noir, dramatic lighting, dynamic composition,moody, vivid, matte print, Crepuscular rays

The following is a transcript from episode 31 of JS to Elm podcast released in 2018:

Hello. My name is Jesse Tomchak, and this is JavaScript Elm episode 31. JavaScript is the new C a show about learning Elm functional programming, and a general sense of leveling up as a JavaScript developer today, we’re gonna get into our topic. JavaScript is the new C. As my thesis point, but first I want to give us a little update on ow notes and sort of what that project looks like and is currently going through we’re at a sort of tipping point right now in our application where we have grown our Elm application inside of our react.

And it has sort of taken over a rather large smart container react component. We’ve stripped everything out and we’ve turned it into an entire Elm application embedded in here. And we’ve got some decisions to make as to whether we want to, how we want to move forward with this application. We can either move on to another part of the application and choose that and sort of iterate and do the same thing.

Do that again and again, and eventually we will. Come together and have to figure out how to sew or push out the last remaining pieces of the react applications. As you know, the ultimate goal is to have a complete LM application, as much as possible. The idea to replace the react application with LM entirely with the exception of any of the interior stuff that we need.

AWS signatures, API calls, things like that. The other option is to continue to grow our existing Elm application and sort of slowly take over the react as a single app, rather than trying to put all the little Elm pieces back together at the end. And frankly, I haven’t really decided which one I want to do or which one would be better or more viable or ups and downs.

I’ve got like a pros and cons list that we will probably go through once I have a decision, but it’s kind of up in the air right now. If you have any ideas, if you think one may be better than the other, or you have gone down this road, I would love to hear from you. You can get me on Twitter at JSL. You can email me at contact.

JS tom.com. That would be amazing. I would really appreciate some input on that. So for today, I want to present my thesis topic. That is the following in a few short years, JavaScript will be considered in the same realm as programming in sea. Meaning to write an application, JavaScript will be considered midlevel air prone, dangerous, consistent with the lowest common denominator, and only really used when you need to leverage a specific use case to say in five years, we won’t be using JS.

Is incorrect. I think it will have the same longevity as C. It is built into the fabric of so many things as a dependency. I would say, I think day to day, developers will not be writing in plain JavaScript, but rather a higher level language that will target JavaScript. At compiled time. I’ve got a little chart or table in the show notes that.

Sort of do a quick little comparison between C as a programming language and JavaScript. The C language is an operating system is used mostly in operating system and system levels everywhere. JavaScript is used on the web everywhere. C Le C has a long list of languages that. Target it as a compile, as does JavaScript C has the Nole references as does JavaScript.

It also has undefined C is great for performance and yes, JavaScript is also optimized and stupid, fast in a optimized VM with just in time compilation. So the, the sub. Titled to this topic is JavaScripts is dead long live JavaScript. And the idea I want to convey is that I really like JavaScript. So I don’t want to come across or think that I’m of the thought that we don’t want to ever write in JavaScript.

I think it’s, I think it’s a great language. I think it has over the last couple years, I’ve learned it has. Deep deep sort of features that make it specifically unique as far as somewhat, you know, C style syntax with a lot of functional style prototyping functions as first class citizens, things that have led me to better programming, paradigms and design decisions.

It’s also really dangerous, right? Function is not defined. X is undefined. These are general things that we come across on a day to day basis as JavaScript developers. But what I want to sort of convey is that it used to be really straightforward to get started with JavaScript, open a text editor or browser, and write some JavaScript code.

You would ship the bike code as the. What the browser would basically compile and run that sort of paradigm where you could just view source and sort of skim through the entire thing at this point is fundamentally dead. JavaScript as an ecosystem now has task runners, bundlers transformers, common JS ES modules, ation uation source mats package management with MPM dev servers, prod performance builds virtual Dom rendering V just in.

Optimize compilation and so on and so on and so forth. JavaScript is no longer shipping readable bike code, readable source code as the bike code to run. Right. We are shipping these G zipped unified bundles that are, I would argue no better. For human readable then assembly. Right? You can sort of discern stuff out of there if you are used to seeing it a lot, but otherwise it’s pretty gnarly.

I would contest that JavaScript has. Been an easy language to master, but an easy platform to be productive in without a mastery of the language, with the laundry list of things that I just listed off. I also believe that that easability in getting, being productive in a, in the platform is virtually gone.

So what does it take to start up a. New application in JavaScript? Well, some, I think the first thing you would say you would argue is, well, you could still just write a dot J S file and put it in a script tag in a way you go. You could, but to start up a web application, what would be required? Well, essentially all the things that I just listed, you would need a complex CLI tool to start up a project.

If you were going to do it from scratch, you would start with a folder. N PM in it. You know, uh, I installed a, I started a new create react app and it installed, I think, 890 something packages. This is both a positive of the ecosystem that I was able to get so much in, just a few quick installs and also a negative of the ecosystem that my.

Project which doesn’t do anything, but render a blank page requires 900 packages and several build steps in order to get out there. My idea with comparing this with C as a language is because C has sort of, uh, stood the test of time, right? It is fundamentally embedded in everything from Unix to Lennox, to systems, to the subset of superset languages like C plus plus languages that interact with.

You know, Java going C sharp Python, Haskel objective C, uh, which is sort of where I got my roots from. But would you want to write your next application in just C not likely, right. You wouldn’t have the build set, the tool chain, the, the sort of nice, nice tool developing and your user experience would not be particularly awesome.

We would probably choose, you know, Java or go Lang or Haskel, you know, or swift or. You know, depending on what we were targeting, we would not choose just Rossi. I would say that the O the same goes for JavaScript. There is a laundry list of languages that interact with JavaScript. Um, you know, we know that one right off the top of our head dart type script, peer script, coffee, script, closure, script, scholar reason, and on and on and on and on.

And that was just a short list. The long list of language. Interop with JavaScript and compile to JavaScript is huge and has been going on. So long, I believe coffee scripts was 2008 or 2009. Right? So we’ve been at this for nearly a decade where we are writing in another language to sort of get around some of what we would consider as developers, the shortcomings of the language.

So I would ask you the same question. Would you write your next application in just vanilla JavaScript? Well, and some of you out there are going to nod and say, yeah, absolutely. But if you are writing an Ang. You would, you would use Cript a lot of listens as a show are trying to write an Elm and we’re we’re doing so because of the things that it offers in addition to on top of JavaScript, the compiler and the friendly air messages and this sort of type safe environment that Elm offers us for web development.

Type script offers a superset of, of static types, right? Pure script offers, sort of the same things, closure scripts, and scholar reason offers, you know, some very interesting, uh, benefits we’ve seen over several years, a. Massive explosion of languages that target JavaScript to enable them to take advantage of not just the web, but the entire ecosystem that comes with JavaScript.

Um, I’m talking specifically, you know, out of the Elm, we have ports where we can write safely an Elm and. Still take advantage of 600,000 library packages out there that are available to us. You know, APIs for local storage APIs for WebGL a, you know, web APIs for location, data, like all these things that are targeted to JavaScript.

We can still leverage in our. Language of choice for us on this podcast, it is hopefully, or more than likely Elm, but not necessarily languages that are built as a superset of C and JavaScript. Have a common theme to overcome perceived shortcomings. In sea or JavaScript. And I say perceived because they’re not necessarily tangible or concrete, but to the developer and the application and that specific build and that those specific needs plain or Rawi plain or raw JavaScript have shortcomings.

So you might ask, well, if you are making the comparison that. JavaScript is the C language of the web. And what I’m saying is a larger scope than that, that JavaScript is in essence, a companion to see in the larger sense of programming, you are not going to write your Java, your applications day to day in JavaScript in just a handful of years.

Right? We don’t nobody today I think opens new. Project and, and says, I’m gonna write this entire stack in C while doable. You’re not really likely to do so. Right. You’re gonna have to reinvent a lot of paradigms and rebuild a lot of things and, and that sort of stuff, even C plus plus like, you know, depending on what you’re trying to build out for us, we’re, we’re building user facing applications.

A lot of the time JavaScript, uh, web apps, progressive web apps, electron. Desktop apps like slack or vs code. I feel like half the apps on my desktop are all in electron now. So I’m not too far off from just using a Chromebook, I guess, which is fine if they keep the touch bar on the max, but that’s a whole nother story.

The point is that in as little as four or five years, I don’t think JavaScript will be a growing ecosystem anymore. As much as a sort of mature place for development on top of packages for interrupt will become more mainstream. The language itself is adding so many things between deconstruction and spread operators and template literals between 20 15, 20 20 17, 20 18.

Um, Array buffer memories and things like that. It is becoming a deeply complicated language that coupled with the fact that you can’t just view source code anymore and actually get an inkling of what in the world is going on, the ability to learn and, and sort of absorb JavaScript is also diminishing as well.

So as it gets more complicated, it is getting less accessible. To anyone that opens their web browser, right? They’re not looking at JavaScript code. They’re looking at modified ified Z zipped Java script. Bite code that just, I mean, it’s unreadable, but it’s small, right? It’s just a couple kilobytes or hopefully a, you know, a couple, a couple hundred kilobytes, not a couple hundred megabytes, uh, for that initial load.

Right. We’re doing lazy loading. Prefetching all that good stuff. And so this is an idea that I’ve had rolling around in my head a lot and sort of one of the reasons I started to explore other languages, I looked into Elm and I looked into pure script and I really wanted to get sort of into this vein.

Type script. Didn’t really appeal to me from. Foundation standpoint. I also didn’t really want to do a lot of angular as I really liked the sort of react paradigm. So obviously through this podcast, I I’ve, you know, put my money behind Elm and, and bet on Elm as a sort of long term, one of the. Long term outcomes to this sort of shift.

There’s also web assembly, right? This is new and coming out. This is where we actually ship assembly code that gets run natively in the browser that compiles from C and C plus plus and rust as compile targets. Right? These is standard memory management, non garbage collection applications, and the transition to high level languages that compiled to JS.

Bit happening. I said coffee scripts was 2008. So give or take 10 years now. And I think it’s just reached that sort of bursting point. You know, we had things like dart, um, coffee scripts, Ruby JS. I, I think Python JS, I think you could name most of the language that is, that would actually compile target to JavaScript.

Um, and El, you know, under the covers, there’s Hask, GC. HJS I would have to check. I’m not totally sure. Go for JS is one for go Lang, but JavaScript is so ubiquitous and yet it is so unsafe to write from a development standpoint, you know, Elm and touts, no runtime air exceptions, which JavaScript absolutely does not have.

Right. It is difficult to write JavaScript. So I think we’ve reached that tipping point tipping point in mainstream. I mean, here we are in a podcast. Every year at Elm com gets bigger and bigger and bigger. And I want. Web assembly today too. But web assembly is just getting started and you know, it, and, and by web assembly getting started, right.

We had ASM JS, uh, and before that we had, um, native client and ACL project. Right. So it’s just been constant evolution, but it will likely be years before we see a mainstream tooling in. Web assembly, right? It’ll have its sort of niches and things, but you know, as, as browser support slowly moves out, it could be a very long time before we see it as a mainstay in web development.

I hope not, but. You know, and think about the state of JavaScript in, you know, two to four years, let’s even say four years. So that’s 20, 20. Nope. That’s 2022. You know, in four years you will have 2, 3, 4 more iterations of the TC nine 30 committee we’ve got right. Patting left PAing string, string, patting, string, patting, other things, right.

They they’re piling a lot of things on the language and it’s constantly backwards compatible. At this point, we we’re working on a rays smush. You know, the language is going to sort of reach this sort of breaking point where it’s going to have to sort of either settle down. As a core or branch or, you know, I don’t think they can keep adding things at this pace, but we’ll see.

We’ll, we’ll see what happens with that now in these sort of research for supporting arguments and supporting facts. For my case, as JavaScript as the new C, I came across, uh, Landa, the ultimate org website, and I found a quote from none other than the author of JavaScripts himself. Uh, Brendan. Reads like this, the new better is better hope for multilanguage is, uh, the NaCl that I talked about a minute ago, the native client, it was the driver for pepper API that failed by being two chromium specific hope Springs, Eternals.

In my humble opinion, that CNC plus plus tool chains will have CFI enforcement for portable, safe binary code sooner than the browser vendors will agree on native client and pepper, two or pepper, three. The worst is better. Hope is compilation to JavaScript combined with language and VM evolution. That is my bet.

And I’m putting my money on it at Mozilla. This was a quote. From 2011. So seven plus years ago, Brendan had this idea that, yeah, it would be great if we could have safe binary code to the browsers, but really, uh, compilation to JavaScript combined with VM evolution is going to be our best bet. He saw this seven years ago.

It’s mainstream today. I think it will be the overwhelming solution in four or five years. Where JavaScript will not be the go-to language will, will there be a, a main go-to language, probably, you know, things seem to settle it, you know, at the top with one or two at the top, and then you sort of get a selection of, of outliers, but who knows, you know, it’s, it may be something that’s not even out yet reason has a lot of traction behind it.

Pure script is good. I’m a personal fan of Elm. But everyone’s got their own pony in this race. And the last thing I’ll say before we, uh, we go to picks is that there is a language called JavaScript plus, plus that compiles to JavaScript. So like C and C plus plus JavaScript plus plus makes my case for me.

There you go. It’s a perfect correlation. I rest my case. All right. So that’s my case for JavaScript as the new C I’d love to know what you think about the idea, the comparison, the pitfalls, the problems, the, the holes in the argument. Uh, I’d be really interested to know what you think. So catch up on Twitter with me JS to Elm.

Uh, catch up with me on slack at J Tom chalk. Let me know what you think. I really think this has. Legs, uh, until someone points out that this is a ridiculous idea, and then I’m going to continue to research it and try and. Uh, hold on to it. So let’s go to picks. Uh, my first pick is a site called type classes.com and type classes is a site for learning functional programming.

It is brought to you by the authors of the HASCO book. Chris Martin and Julie, Chris Martin and Julie, Chris Martin and Julie, uh, Julie, I don’t remember your last name. Uh, Julie. Maru key. Sorry. Julie Maki and Chris Martin, they have been talking about making videos for Haskel and have done it. The site is up it’s called tech classes.com.

I think it is really super awesome. So check out the site and let me know what you think. I also found this really cool. My next pick is this really cool site called, uh, carbon.now.sh, which you may or may not already know about to create and share beautiful images of your source code. So you just type in your source code and it generates this awesome image and it even has like a tweet code button right there.

So you can just tweet your code out. It’s super rad. And my last and final pick is. Jay Phillips talks about web assembly, discussing what it is, how it can be used today and opportunities. It will unlock in the years to come. So we ended the, we ended my discussion with these sort of like, well, what about web assembly?

And where does that fit into the paradigm? And, and, you know, these things move slowly, but. There is opportunity today in web assembly. And if you were like, Hey, this is cool. Uh, check out J Phelps stock. It’s really, really good. Uh, and that’s it for this week. Next week, we will figure out what we’re doing with our Meow notes application.

As we sort of build it out in Elm, uh, as always check out the resources for all the links, um, and resources that I found to put this episode together. Please follow on. Twitter at JS LM, you can follow me at J Tom shock on Twitter. Um, you can email me. I’d love to get sent email contact JS lm.com and we’ll see you next week.

Getting my thoughts together with react context and the current uses of manageing state in the react community. There’s a lot of ‘just you context’ that feels more and more like a failure to properly explain what context actually is, and how it works.

Context is primarily used when some data needs to be accessible by many components at different nesting levels. Apply it sparingly because it makes component reuse more difficult.

React docs

It is very clear that context is not the silver bullet that is often quoted when building applications with react. It is simply one piece in the larger consideration of state management.

It’s only February so maybe I’m getting ahead of myself, but this post by Claus Matzinger, author of Data Structures and Algorithms with Rust, was very encouraging.

Initially, a book was this unsurmountable challenge, but, one chapter at a time,

It’s nothing profound, but a great simple explanation of the benefits you as the author get out of tacking a project as massive as a book. You bet the resources listed are in my amazon book list for down the road. 😉

ArsTechinca

Pai didn’t release the full Broadband Deployment Report

No kidding. 🙄 But wait, with a little digging you wouldn’t believe what the results are!

Despite the limited information available, advocacy group Free Press was able to discover a huge error that showed broadband progress under Pai’s leadership was less impressive than he claimed.

So there was a big error, they fixed it, and then continue to lie about the results of their unsuccessful program. Ok. Got it.

From 9To5Mac

According to a promotional message found in the service, the price for Apple Arcade will be $4.99 / month, including a one-month free trial. As Apple previously announced, the service will allow access to all members in a Family Sharing account.

If this is the case, I’m all in. I would have been in the fence about it at $10. That compounded with the Switch Lite at a lower price is gonna make gaming at my house with young kids awesome for everyone !!!!!

This week Apple has been putting several products to the dirt nap, sleeping with the fishes.

Original HomePod Originally overpriced, over engineered, and stuck with Siri. While it did sound fantastic, the price tag of $349 did not offer the same features and benefits as smart speakers a 1/3 that price. And while we’re used to paying the ‘Apple Tax’ for good products that work well in the ecosystem, this first version was noticeably lacking for the price. Even more concerning is the 4 years it’s been out, it has received little improvements via updates. Most notably it launched without multiple timers, eventually released, I struggle to think of anything else noteworthy that the HomePod improved upon during it’s lifespan.

iMac Pro Released the same time as the HomePod, fall of 2017, this iMac was easily the best iMac ever made. Also just like the HomePod, it was released, and left without any revisions or updates during its life. (Dropping the 8-core model doesn’t count) The iMac Pro came from an alternate time line where Apple was not going to make a new Mac Pro, there was to be no more powerful, modular tower from Apple. Months before it’s release, Apple had its unusual round table to announce it was changing directions. It would be almost 2 more years before the now Mac Pro is readily available, the iMac Pro, the future pro machine, was now relegated to keeping pro users content until then. Often referred to as the most powerful and quiet iMac ever, it continues to be a favorite among podcasters. Now with the M1’s out, Apple is closing this time loop, leaving the iMac Pro in a short list one 1 and done products.

While these products are discontinued for very different reasons, it marks the end of the beginning into a new chapter for Apple.

While Greater China and other emerging markets accounted for the vast majority of the year-over-year iPhone revenue decline, in some developed markets, iPhone upgrades also were not as strong as we thought they would be. While macroeconomic challenges in some markets were a key contributor to this trend, we believe there are other factors broadly impacting our iPhone performance, including consumers adapting to a world with fewer carrier subsidies, US dollar strength-related price increases, and some customers taking advantage of significantly reduced pricing for iPhone battery replacements. 

Apple Website

Like many I can’t say the last line that iPhone battery replacements made a significant impact to lower sales than previous projected, it’s a bad look Tim. The smartphone market is mature and for the most part fully saturated. Someone like myself, who has pre-ordered most iPhones, getting the newest biggest best, have held off in recent cycles. Why? The combination of phones breaking $1,000, with the leveling off of hardware speed from year to year. Even with that, I’ve been Apple Leasing iPhones since they offered it. Pretty much iPhone as a service. At this point every 2 years seems more than adequate.

Full Response from Apple 

What Spotify is demanding is something very different. After using the App Store for years to dramatically grow their business, Spotify seeks to keep all the benefits of the App Store ecosystem — including the substantial revenue that they draw from the App Store’s customers — without making any contributions to that marketplace. At the same time, they distribute the music you love while making ever-smaller contributions to the artists, musicians and songwriters who create it — even going so far as to take these creators to court.

I am not sure I’d quite agree with Spotify “using” the App Store to “dramatically” grow their business without making any contributions to the “marketplace”. What they mean is using the App Store and not paying Apple for that privilege. Also the jab making “ever-smaller” contributions to the artist, is a separate issue all together and not the point of this particular argument. It’s a valid argument, just not this one.

The only time we have requested adjustments is when Spotify has tried to sidestep the same rules that every other app follows.

Mmm. That every app follows. 🤔 What about Apple Music? Does it go through the same app approval process?

The only contribution that Apple requires is for digital goods and services that are purchased inside the app using our secure in-app purchase system

Oh, you left out the part where the purchase system is the only option. Against the rules to link out the any other option Against the rules to even mention having any other products of any kind that is not purchased directly through the in-app system. This is explicably user hostel on Apple’s part. Why aren’t talking about Google’s Play Store because you can link to, mention, advertise other tiers and products in your app. That’s the point, there are options. Look at Netflix if you download the app, and don’t have an account, there is nothing for the user to do. They can’t sign up, they don’t have a clue what to do, or where to go. That is not a good user experience and wholly on Apple and their imposing rules.

I read this and I think, Apple is not budging on lowering the 30% fee. Not now, and with the focus on service revenue, not on an infinite time line. If anything, it will become more restrictive over time, not less.

With another day comes another company making a push for more podcasts in it’s lineup. Today that’s iHeart Radio

From The Verge

iHeartMedia will harness more than 850 radio stations to build its podcast audience and entice potential advertisers. The company today announced Sunday Night Podcasts, in which 270 stations will play a prerecorded podcast episode in between music or talk radio. The initiative will bring podcasts to the airwaves in every one of iHeart’s markets.

I like the idea of using other avenues besides the ‘podcast app’ to expose people to podcasts as a medium. I have friends and family that continue to listen to FM radio to this day, even with dozens of other options, their car is tuned into some random station I don’t know. They are unlikely to fire up their podcast app and find something interesting to listen to. This might be a soft sell that gets them over the hump? I guess we’ll see.

Netlify deploy might auto publish?

It’s very tricky for platforms… these are winner-take-all markets. It really is winner-take-all. If you’re there with half as many apps or 90 percent as many apps, you’re on your way to complete doom. There’s room for exactly one non-Apple operating system and what’s that worth? $400 billion that would be transferred from company G to company M.

Bill Gates

My hope is after reading Ben Thompson’s Aggregation Theory I will be better equipped to answer the question I have. Ok, so how best to approach the tech industry in a way that promotes competition when the network effect is so strong?

I didn’t realize that BlackBerry was still around, and haven’t been dismantled and sold off for scrape like Palm or Motorola. Turns out they are making a business as a patent troll. 🙄

BlackBerry, which refers to itself as a pioneer in mobile messaging, alleges Twitter “created mobile messaging applications that co-opt BlackBerry’s innovations, using a number of the innovative user interface and functionality enhancing features that made BlackBerry’s products such a critical and commercial success in the first place.”

BlackBerry sues Twitter for patent infringement

Bringing the blog back in-house

Rework Podcast

This move by Basecamp, along with other antidotal moves from others, maybe some research later, on moving away from curated platforms like Medium and other spaces where the author or company don’t really own the content or experience, to a self hosted content service like WordPress or Ghost is really on the rise. Maybe I’m just hyper aware of it from building out my own stream of content that is not tied to a specific platform, but I’m definitely seeing a growing trend.

Buttigieg isn’t the only Democratic candidate calling for more broadband in rural areas. Last week, Sen. Elizabeth Warren (D-MA) announced her big broadband plan that would include an $85 billion grant program for nonprofits and local governments to build their own networks.

Pete Buttigieg rolls out $80 billion plan to improve rural broadband

It would be great if this sort of talk actually made it through election cycles. Like so man promises before it, ISP’s have and will continue to spend millions of dollars annually to keep their respective monopoly on providing subpar internet to rural Americans. 😢 Making promises like these nothing more than campaign rhetoric.

When we talk about regulation for tech, maybe we should review net neutrality for ISP’s ?🤷🏻‍♂️

King County Superior Court Judge Timothy Bradshaw found that “Comcast violated the Consumer Protection Act more than 445,000 times when it charged tens of thousands of Washingtonians for its Service Protection Plan without their consent,” 

ArsTechnica

Maine lawmakers have passed a bill that will prevent internet providers from selling consumers’ private internet data to advertisers.

The state’s senate unanimously passed the bill 35-0 on Thursday following an earlier vote by state representatives 96-45 in favor of the bill.

Maine passes law preventing ISPs from selling browsing data without consent

Follow up from a previous post on blocking the IRS from creating a free tax filing option to compete with Intuit.

Lawmakers are planning to drop a proposal to prohibit the Internal Revenue Service from offering a free online tax-filing option, Politico and Pro Publica report. The provision was included in the Taxpayer First Act, which passed the House in April but has not passed the Senate. It was backed by the makers of private tax preparation software, including Intuit (makers of TurboTax) and H&R Block.

ArsTechnica

In one of its provisions, the bill makes it illegal for the IRS to create its own online system of tax filing. Companies like Intuit, the maker of TurboTax, and H&R Block have lobbied for years to block the IRS from creating such a system. If the tax agency created its own program, which would be similar to programs other developed countries have, it would threaten the industry’s profits.

ProPublic

Having just done my taxes, and paying Intuit a hundred bucks every year to e-file my federal and state taxes, this story makes me even more wound up than usual. And yes, I could manually do them myself, but I’d rather spend that time doing other things I deem more important.

It just grinds my gears when private companies push and lobby to keep the status quo, keeping entities state, federal, or local from progressing and providing appropriate help for the public. This law only benefits share holders of companies that provide tax software. It in no way can be contorted to be “in the best interest of the public good”.

🤬

So the cross posting from here wasn’t working, and it wasn’t until I figured out that the RSS feed didn’t have the updated URL scheme that the rest of the site has. 🤦‍♂️ It was only setup to populate the post slug, missing the month and year path.

Starbucks feels like a digital library for those that can can afford $5 coffee. I tend to see more people on their device or sharing content then anything else.

Facebook also denies that it collects, records, and maintains data on users’ “information and activity,” though it does admit that “users can provide Facebook with certain information.”

Facebook denies allegations that you make friends on Facebook

It is strange to me that anyone could say this, much less write it up in an official legal document, with a straight face.