That is the trend, but just because something is popular doesn't make it optimal. Developers are also excited about marginal gains from LLMs. The reality though is that most of those same teams could 2x their productivity by going back to a more retro stack, without losing quality, and also lowering costs in hosting and devops. The move to multi-service was for scale, but somewhere along the line people forgot to measure whether they needed that complexity at all.
It's fair to point out that there is real skill involved in that kind of work. However, I don't trust the average "frontend developer" to do pixel perfect implementations either. Many of them don't even seem to know CSS anymore. And not to discount your experience, but being able to implement a design is something that is easily testable when evaluating candidates. Because I come from the multimedia agency world, most of the candidates I've hired were actually for that kind of role. Accidentally hiring people who can't do the work points to a competency issue with management. As I've pointed out elsewhere, I have the awards to speak authoritatively on this. But perhaps me focusing on average skill is just an unfair way to look it, since I'm never really looking for average anyways.
That's an interesting point about team composition. Companies originally split frontend from backend to scale up the number of developers they could put on projects. The idea was that each system could be a black box to the other team, and you may only need one person that understands it all end-to-end. The problem was that by splitting monoliths into multiple services they basically lost most of the advancements the industry had made to increase developer velocity. If your org was trending towards hyperscale, then you would have been transitioning to a multi-service architecture anyways, but for everyone else the move to SPAs resulted in a massive loss of productivity.
Listen, how impactful LLMs will be largely depends on the type of code teams are writing. If you're already building in a highly declarative manner, where your libraries are automatically handling most of the glue for you, then you may not have much of a need for writing code more quickly. These are the teams that are actually fast. Teams that already spend a bunch of time writing glue code will likely see significant improvements in velocity, because LLMs are good at regurgitating existing patterns. What they probably won't do is refactor your project so that your team starts operating on the level of the formerly described one.
backend and frontend engineers aren't as distinct from each other as they are from ML or something like embedded development. It is very normal to be able to build a web interface end-to-end, and frankly something I expect of every competent developer in that space. Someone who is a high-performing frontend engineer should also be able to perform at a high level in backend, and vice-versa. I'm talking about the industry as a whole though, and specifically that I wouldn't trust the average "frontend developer" to be making wise engineering decisions. Saying this coming from a background of working with designers on webby award winning projects and having a high degree of respect for the platform.
I suspect the cultural issues with JS primarily boil down to the fact that every org needs JS, which in turn results in 1) a glut of junior/mid devs and 2) it naturally being ground zero for hype cycles. At this point I honestly wonder if most orgs should even hire for JS skills, or if they would be better served by hiring backend engineers and training them to write progressively enhanced UIs.
These things exist on a spectrum of features but they are all mapping tables to objects at the end of the day at the bare minimum. Pedantry around what technically should count as an ORM is not super productive. The fact is that defining a schema in one place and getting a whole slew of features out of that automatically is multiplicative to productivity.
The author presented their opinion as broadly stroked general advice and in that context it is poor. And, specifically regarding database/sql, creating a bunch of pointers to scan values into for every query you write is the definition of insanity in all but the most performance sensitive applications. We're talking microseconds (or even nanoseconds in some instances) on an operation typically measured in milliseconds.
Anti-ORM sentiment is a senior developer red flag. It indicates pretty clearly that an engineer views their work more as an art project, rather than valuing achieving the actual business goals in any reasonable time frame.
I went through the same evolution, even built a PaaS for AWS, but I kept going and now just deploy my own stuff to VMs with Swarm via one command in Rove. It's great. And yes I know kubernetes I use it at work. It's an unnecessary waste of time.
As with any profession, most workers are just proficient in whatever they need to do. The people littering these things with comments about how Tailwind is "enough" are probably telling the truth for their personal experiences. A lot of web developers don't have professional experience working with designers and implementing software to visual specifications.
Right? If a company can't be trusted to do password hashing, then they definitely shouldn't be trusted with PII. With that said, I think it's the SSO and broader ecosystem that orgs are paying vendors for.
Could be as simple as he wants to say he "ended" the war. If history offers any lessons, it's that he doesn't think too much about the details and doesn't care how his actions impact others.
The framework website currently has a strange message about putting users into queues just to view the homepage. Might be time to start thinking about setting up Varnish
It's wild to me, as someone who grew up thinking I was conservative, that conservatives hated Biden and Harris so much. Nobody ever brings the receipts either.
It has been this way since the dawn of electronic banking. I once had complete access to all digital wallets for the Seattle metro, which I gained by looking at two cards and noticing the numbers were incrementing. Even with all of the flaws of electronic transactions, it's still better than walking to the bank and hoping a check won't bounce.
Backend development is all about data storage and retrieval. It's no coincidence that the most celebrated backend frameworks of all time developed best-in-class ORMs for their respective languages. Being able to define a single structure that defines how data moves all the way through the stack is incredibly powerful and opens up development optimizations that simply don't happen when mixing boutique libraries.
Eh, starting with k8s just because I might want kubernetes in five years is a hard sell, given how easy swarm is to setup. devops that does not fulfill an immediate business need should be delayed because that labor is hella expensive.
Does Podman have a swarm counterpart, or does running services still effectively require configuring systemd and then switching to kubernetes for multi-machine?
You should consider licensing the core project more restrictively with something like a FSL. Regardless, there may be more of a market in selling "pro" licenses to plugins for projects like WordPress, Shopify, Payload, Craft CMS, etc that include integrations with 3rd party services.
Framework _and_ CMS so most of these don't seem to apply. I haven't seen Vaadin before so that's interesting. JHipster seems like the closest to the ones I mentioned but the UI looks unpolished in the overview video.
I've written ORMs for both Java and Go and agree that Java is a wonderful language with a much more complete type system than Go. However, it feels like Java web development teams typically suffer from not having their own Wagtail/Payload/etc and build way too much from scratch. Maybe there is some great open source framework+CMS out there making waves in Java land that I'm unaware of?
Really not seeing the forest through the trees on this one. The president is not supposed to have unilateral authority to axe written law. He's trimming the legislative branch, not the budget.
It's kind of funny to me how derided full stack developers are as unskilled generalists. It would have been unthinkable back when I started web development to only learn half of what it takes to build a website.
Grand Rapids and Traverse City might meet your criteria, but it's hard to say given how subjectively they are worded. If you want to live in a town with a large university, then obviously just look at the top three universities by size in each state.
Sure docs for massively popular libraries are translated but think about using autocomplete, reading the actual library code, or even just reading other code in your organization. I have to imagine it would be difficult without any English proficiency.