Hacker News Reader

Comment by iandanforth | Hacker News Reader

I know many developers who want nothing to do with frontend work because of two main factors, 1. The obsession with bleeding edge technology and 2. The developer community being disproportionately composed of young and/or new and/or self-taught developers who "discover" new paradigms constantly. Those factors create a constant churn in technologies in which nothing is learned and everything is repeated every six months to two years. It's like watching mayflies argue about politics.

This article feels much the same.

View on HN

That's what made me so confused about the framing of the article, because it seemed like it was going to go the other way.

> Things you forgot because of React

Ah, this is going to be a back-to-basics, here's how great vanilla JS, HTML and CSS can be.

> I used to only listen to new music, updating my tastes with each week, and was never really satisfied. Then I discovered that there were certain genres that didn't update each week, and were timeless and satisfying.

Ok, this is definitely a back-to-basics, don't jump on the flavor-of-the-week

> React is old news now, here are a dozen new flavors of the week.

Wait, what..?

I was laughing at the line that hooks are as old as his kid (as if this made them ancient) followed immediately by the comment that his kid is going into pre-k.

His kid is... drumroll... 4 years old.

That's a really curious perception of time. I consider everything as old as my kids spanking new. My oldest is 16.

I wonder what causes this (except me being old, but still, I thought this even when my oldest 4 as well).

People should kick off a bunch of things on when their child is born to remember timescales are relative.

Buy a green banana. Buy a certificate of deposit. Plant tomatoes. Cellar a bottle of wine. Plant a redwood tree.

I made a wine kit for each of my children - it makes 30 bottles and we drink one a year on the birthday itself.

I've found it helps for scale and as a bonus you get to see how a wine really ages over time.

You probably know that not all bottled wines age well, in fact only a handful do. Usually high sugar content is important, because the sugar preserves the aromas and keeps them from evaporating. Alcohol content, acidity and tanins also play a role.

Most bottled wines are meant to be drank right after bottling or in up to 5 years, white wines less than that. They get more brown or orange as they oxydize. Prosecco and sparkling wines are usually better if they're from the previous year.

Perhaps you could argue that high initial sugar matters but final sugar content definitely does not. I only like my wines dry with no residual sugar remaining after fermentation is complete. A decade on my big reds are tasting fantastic.

I've had exactly one bottle of white go bad on me and it was somewhere in that 8-10 year range. It can definitely happen and would not recommend a white for this kind of thing . . . but this is also how you learn.

For someone not wanting to go the "make it yourself" route, I'm sure if you went to a good wine distributor and said you were looking to buy two or three cases of something you want to cellar for a good long while they would be happy to steer you in the right direction.

Having a kid is a major milestone so time perception might be tied to that moment

Speaking of timeless music:

    A change, it had to come
    We knew it all along
    We were liberated from the fold, that's all
    And the world looks just the same
    And history ain't changed
    'Cause the banners, they all flown in the last war

- Won’t Get Fooled Again, The Who

Meet the new build system, same as the old build system

Exactly, I feel cheated and I'd like my time back.

This article seems completely filled with nonsense.

After YEARS and THOUSANDS of projects proving that 2-way binding causes massive problems, the author insists I shouldn't believe my lying eyes. This may sucker devs with only a handful of years writing frontend code, but any dev who lived through those years won't be buying what is being sold.

"Hooks are outdated" is also false. I used Knockout and signals YEARS before React. Signals are NOT better. At a large scale, they are fragile and nearly impossible to debug because EVERYTHING in your entire app is a moving/mutating target. Just because they "aren't afraid" doesn't mean they aren't coding horrible bugs everywhere that will come home to roost from seemingly unrelated code changes in another part of the app.

The author claims that you can port libraries between other frameworks easily. This is absolutely false. The only "portable" solutions are going completely headless then making wrappers for various frameworks and if you do this, then React is no different than any other framework.

Bragging that you can't understand the difference between useMemo and useCallback after reading the docs (one is general memoization and the other is function-specific) isn't a dig at the framework so much as an indictment of the author.

Benchmarks are another interesting area. The actual delta between React and other systems isn't as massive as some seem to believe. More importantly, React's ability to defer rendering of some elements gives it the potential to feel faster to the user (which is the important metric).

I find the React is "hard to learn" claim fascinating. When I used AngularJS, it took 1-2 MONTHS to write basic stuff. Becoming an expert required 6 months to a year as you slowly learned the entire AngularJS codebase debugging stuff like the digest cycle. I taught a LOT of people to code React. 1-2 days to learn those basics and 1-2 weeks to know everything. The core React API has grown, but it's still not very complicated. Other frameworks may be quicker to learn, but in my experience, the difference is not huge upfront and there are almost always weird edge cases that haven't been documented that you'll run into (and that's without the signals edge cases).

> Bragging that you can't understand the difference between useMemo and useCallback after reading the docs (one is general memoization and the other is function-specific) isn't a dig at the framework so much as an indictment of the author.

Yeah, it is fairly obvious (though, to be fair, it wouldn't hurt to point it out) that:

  useCallback((...args) => {
    <*statements*>
  }, [<*deplist*>] );

is effectively identical to:

  useMemo(() => (...args) => {
    <*statements*>
  }, [<*deplist*>]);

Are they "effectively" identical or they just identical? What's the difference?

Effectively as in "they have the same effect". The difference was stated in the comment that you replied to: One is for general memoization, the other just for functions. You can use useMemo exclusively if you prefer.

But it does reflect so much that’s wrong with the React development.

Creating a first class hook whose only purpose is to wrap another first class hook, all so you can pass in a function rather than a function that returns a function.

I hear what you’re saying. I think in the abstract it seems like an unnecessary helper function. But in a historical context it makes sense.

About a year before hooks was introduced it was discovered by multiple teams that inline anonymous JSX functions could create big performance issues. This was particularly felt in react native development. The solution back then was to do the whole .bind(this) to your callback methods in your react classes.

Because of this (my guess) is the react team wanted to make it extremely obvious how you could use closure state as opposed to private method callbacks when they went intro hooks, without teams having to worry about taking a performance penalty with inline callbacks. It was not obvious to me (and I’m sure many others) when hooks came out that you could memoize functions before rendering.

Again, I get the redundancy point and maybe at this point it could be deprecated but I think you have to think about where the community was before hooks.

Memoization is saving things in memory, it's a tradeoff of memory for fewer function calls. It doesn't work with all possible callback functions (because they need to be pure based on their inputs and dependencies for the saved values to still make sense), and also you don't always want to spend the memory on it (some smart memory use is going to be more performant than the function calls, too much memory use is its own performance problem).

The two hooks have different names because they make different trade-offs.

They are identical in their effect[1]. At one point they were almost identical in their implementation. Looking around at the (much larger) current React source seems to indicate that this is still the case.

[1] https://react.dev/reference/react/useMemo#memoizing-a-functi...

In this specific case above they work the same, useCallback memoizes the instance of a function passed. useMemo memoizes the execution of the function it is passed. but both have valid separate uses.

Two-way data binding is a foot-gun for sure (I also worked in a large knockout codebase circa 2010), but man is the alternative a PITA when you’re just filling in a form. And the problem only shows up when you start propagating two-way data back up the tree.

If someone wants to invent a framework where two-way form binding is easy, but the data can’t leave the component without being dispatched as an action, I’m in.

The framework you're looking for is more or less Vue.

(some will probably disagree, but I think most that have used Vue significantly won't)

I too thought Vue would be a solid fit for what they described.

useReducer is what you're looking for

React is ridiculously hard to “self learn”. Not because React is necessarily confusing, but because React docs are extremely confusing and the transition from class components to function hook based components means you can search for a problem and find answers only for class components, whereas the function component solution is buried deep if it even exists.

And we know it’s confusing because the React docs themselves reflect the confusion. A great example is useEffect, where the original docs quite clearly state that useEffect can be used to handle side effects, whereas the new docs say it’s used to “sync” components (and I don’t remember if it explicitly says not to use it for side effects, but that’s the common understanding people have now).

> whereas the new docs say it’s used to “sync” components (and I don’t remember if it explicitly says not to use it for side effects, but that’s the common understanding people have now).

other way around. useEffect is for side effects (hence the name) and are _not_ needed for "syncing" state with props.

Thank you. I never understand why frameworks have two way data binding and signals, both are heavily bug prone. React still reigns supreme.

> Bragging that you can't understand the difference between useMemo and useCallback after reading the docs (one is general memoization and the other is function-specific)

Right, the first argument to useMemo must be a function, but the first argument to useCallback need not. That's what you meant, right?

useCallback makes sure that you don't recreate a function you need in a component at every re-render but only when its dependencies change. It returns a function.

useMemo returns a value which is the result of calling the function it is given once the dependencies change.

So useCallback is basically useMemo called with a function that returns a function.

> useCallback ... returns a function.

It returns something with the same type you gave it. If you give it a function it gives you a function back.

In typescript it's declared to take a function but in practice it doesn't check, and can be used to stabilize the identity of anything.

useMemo otoh _does_ only take functions.

> everything is repeated every six months to two years

Same feeling looking at the new Vercel SQL library. Oh wow now you can write SQL right next to your client-facing code, such convenient. You have just rediscovered PHP.

To be fair, frontend frameworks solve a problem. Application can get too big that you cannot manage all the states imperatively. Declarative UI building really help to keep the UI separated from the logic. But then management get greedy and and try to shove all the features they can think of into one single big app. Like, if you went to a page and click a button, going to another page will let you know that you clicked that button and shows up some nice CTA so you won't forget. Frontend people scramble around trying to create new abstraction to keep their working surface manageable. Then you get workflows where to get the result of an API call you have to dispatch a thunk action so it would update in the global store (my example may be antiquated, I'm away from React & Redux for a little while), instead of just, you know, call it and `.then()` update the UI.

Maybe if you have an app that is twice bigger than a normal app, maybe, I don't know, split it into two apps instead? The problem of web development app right now, I think, is because people are being monolithic where it should be independently modular, and then try to cut up your backend service into pieces when a single monolith works fine.

PHP can't run in the browser.

Ah but that's not what I am referring to. If you take a look at Vercel Postgres page [^0], you will see that Vercel is marketing a new way of writing server side rendered code, where you can write SQL code right next to the HTML-ish code for the frontend. So I'm just merely making a (meant to be humorous) comparison with PHP.

> PHP can't run in the browser.

Well actually, WordPress did it [^1] [^2]. They compiled PHP to WASM, so you can run our favorite web framework in your own browser.

I see your point anyway. Systems evolve. Tooling has to follow suit. PHP cannot achieve some of the feat today mega stack can. The problem arises when we apply the latest bleeding edge technology meant for systems that have to serve millions into our little MVP that may have less than 1000 users in your first few years.

[0]: https://vercel.com/storage/postgres [1]: https://developer.wordpress.org/playground/ [2]: https://github.com/WordPress/wordpress-playground

You don't need a mega stack to attach an event listener to an element. PHP can't do that.

I dont think you are listening what he is saying. The vercel sql library is serverside javascript. This could be any language. What the library reinvets is pattern that has been criticised, hated and laughed at not that long ago. Especially in this form of raw sql mixed in between html.

It was specifically the react/you-must-have-api crowd who bashed PHP bacause of this.

I guess in the end PHP was what people wanted all along.

The Vercel SQL library doesn't mix raw SQL and HTML. It can't, since that'd easily allow public db access on the frontend.

What people wanted was the speed of a server-rendered starting point and the flexibility and performance of client-side templating and interactivity. JS/React can deliver this, PHP cannot.

Wow i just said that it is server side javascript because you were claiming ... and that its mixing raw sql with html template like what was hated in PHP. Have you even looked at https://vercel.com/storage/postgres - its right there in their example.

You are either trolling me or you are not really sure how these things work?

You could do that with PHP backend + any frontend framework during the last 2 decades before.

OK, now you can do it using just one JS framework i guess? But is it a revolution? A breakthrough?

You couldn't do that before. Combining a PHP backend and a frontend framework meant you had two different html templates.

Thats not true. You had one .php file (or more, if you use includes) where everything was located: the HTML, if necessary any JS via <script> and interspersed with <?php … ?> depending on what dynamic stuff you wanted to output.

And this is parsed to one output file that is sent back to the browser.

What are you event talking about? Are you aware that any touring completel language can output JSON... what two different html templates?

I'd say don't give anyone bad ideas, but we are too late:

https://github.com/oraoto/pib

Sorry friend, WordPress already beat you to it: https://github.com/WordPress/wordpress-playground

When I was starting out in the industry, I wasn’t even a programmer yet when a lead developer sat me down and taught me about the pendulum swing. At the time it was closer to six years to two decades. It’s clearly gotten faster in the era of Stack Overflow, but if you’re seeing six months to two years, that’s ridiculous (you’re not, the situation is).

That conversation accelerated the first ten years of my career by making me more effective. I knew people who made it farther with less work than I did, but mostly I knew the reverse. So I in turn have talked about the pendulum swing with more people than any other topic.

In the Expanse, Amos talks about The Churn, which is a related phenomenon.

“When the jungle tears itself down and builds itself into something new. Guys like you and me, we end up dead. Doesn’t really mean anything. Or, if we happen to live through it, well that doesn’t mean anything either.”

If you come through chaos unscathed it doesn't mean you were good. It just means you were lucky. Don’t let it go to your head.

The motivation of people with 3 years of experience is to jump on a bandwagon that mutes the effectiveness of having 15 years’ worth of experience. You’re dragging half of the industry down in order to pull yourself up. That’s defecting, and we all know how that turns out.

I've been doing web development since 1996. I've witnessed the ebbs and flows and hype trains.

Svelte's the real deal. How do I know? Because it's not a new API or paradigm. It's the old web just better.

It encourages HTML and sane CSS, not just wrapping them in endless boilerplate. It compiles to efficient code rather than making you write all of it over and over again. It takes all the lessons from the last decade and a half and distills them into familiar web development patterns.

   <script>
   <style>
   all your HTML
   + bare minimum of logic to solve your problems

I haven't been this excited about a new web technology in a decade, so coming from an old school web dev who learned off of view source in 1996, take that into consideration.

And while I prefer Svelte, Htmx is doing a lot of the same work; not new APIs; just embracing old ones without all the boilerplate.

I love svelte too, but I would argue that the way svelte extends JavaScript by making reactivity a language primitive pushes svelte beyond "the old web, just better".

https://gist.github.com/Rich-Harris/0f910048478c2a6505d1c321...

https://svelte.dev/docs/svelte-components#script-3-$-marks-a...

https://svelte.dev/docs/svelte-components#script-4-prefix-st...

That's where this part kicks in:

    "It takes all the lessons from the last decade and a half and distills them into familiar web development patterns."

That includes reactivity and state management—two concepts that weren't adequately covered by the old web.

Well, CSS itself is a problem, because it is not component-izable and composable. I only use inline CSS now, not because it the very best aproach, but at each it keeps my projects sane after years.

It is in Svelte. Take a look. You write normal CSS as you always have, and Svelte takes care of scoping it to just your component by default.

React really made people think they couldn't expect any better.

Have you noticed that Lambda is just FastCGI, Cloud Edition?

+ multi-availability zone redundancy and resiliency, multi-region deployment options, and edge computing at CDN endpoints.

Other than that, for web functionality, they're identical! ;-)

Then of course there's the ability to supplement authentication on the backend, detect file uploads for background processing, etc. All of which are outside the scope of FastCGI.

But you don't care for Lambda. That's fine. You do you.

That only works if you think that basic HTML and CSS where at any point good platforms for building complex applications. Many people (me included) wouldn't agree with this. In that case, saying that Svelte doesn't help overcome any of those fundamental limitations of web development would not be a selling point.

Things only get worse when you add vanilla javascript to the mix.

Every web app no matter the framework boils down to HTML and CSS at its core. The furthest you can get from those is ratcheting up the number of <div> and <span> elements, then of course making the mad dash to reintroduce the lost functionality through heaps of JS and accessibility through aria roles.

Or… you could use the tags most appropriate to the problem with accessibility and SEO automatically coming along for the ride.

PicoCSS is an excellent example of what can be accomplished with just a sprinkling (~10KB) of CSS over plain old HTML.

Browsers can do so much more than they used to out of the box today. We should take advantage of that rather than silo it away in one-off React-based APIs.

Compiled languages boil down to assembly, but I wouldn't like to write them as assembly files with a few higher-level constructs sprinkled through the files.

You may disagree that html and css are that bad. But I think it was always a mess, specially when you go beyond linked documents and add any kind of interactivity and forms. There's also inherent limitations like "select" dropdowns offering very little functionality and mostly ending up as custom components in all projects I have worked in.

You seem to be taking the position that Svelte does not allow for components for cases like custom dropdowns where HTML falls short on its own.

This is not at all the case. I highly recommend actually looking at Svelte examples before commenting further.

That said, there are a lot of folks out there who don't know that, for example, combo boxes and accordions are possible with plain HTML.

    <datalist>
    <details>
    <summary>

PicoCSS is a great resource for seeing what's possible with just plain HTML and ~10KB of CSS.

I don't have knowledge about Svelte so you may be right about it solving all those issues. My contention is with regards to the general idea of the article and some comments that seem to indicate that everything was good in the web development world before React introduced a bunch of problems. React did introduce some problems, but to sell me on migrating I'll need to see that the new framework solves the issues inherent to web development, not just the issues that React created.

I do not think that is a charitable view of the article or most people's comments. We all knew what was gained. We just bemoan what was lost, much of which has been found to be largely unknown to more recent entrants into the field.

Folks aren't against solving problems. I think the main concern is the amnesia regarding problems that had already be solved and are now be solved again only not as well.

i too have been developing since 1996. and in 1996, nobody was making web-based applications with anywhere near a fraction of the complexity that modern web apps manage.

please build spotify using only HTML and JS language features from 1996.

Nice straw man you've built there. Be a shame if anything happened to it.

Htmx is nothing but new APIs bolted on to a markup language.

Where that markup language is HTML, yes, I agree.

It's a feature, not a bug. That said, I personally prefer the Svelte model. I like leveraging the client browser for effect, not just rendering everything server-side.

What a grumpy comment.

- Two of the best developers I know are completely self-taught.

- I'd argue there have been so many front-end frameworks not for the sake of novelty because the web platform itself was incomplete and stagnated. (And also blew a huge opportunity with the APIs for web components.)

- Now that the platform is evolving and innovating again, more and more things are moving out of the frameworks and back into the platform. Javascript has massively improved.

- Some amazing and complex engineering happens in the frontend space because of the constraints and the need to eek performance out of everywhere you can. You can't just throw more servers at the problem.

- Experiences vary, but I've been on more projects delayed by over-engineering the backend than the frontend.

> And also blew a huge opportunity with the APIs for web components

How? I really don't understand this sentiment.

The web components API is a gajillion times less complex to me than, for example, react.

Coupled with a light weight rendering library like lit-html, a basic component takes seconds.

- Make a class that inherits HTMLElement

- Create a rendering template in connectedCallback using your favorite templating/rendering library.

- Add class properties that call render() when they're changed.

The cognitive load is a fraction of what's needed for frameworks like angular or react.

> The web components API is a gajillion times less complex to me than, for example, react.

And then you go on to list multiple complex things:

- Create a rendering template in connectedCallback using your favorite templating/rendering library.

So you need to bind together a connectedCallback and some rendering library

- Add class properties that call render() when they're changed.

So you have to manually wire class properties to manually call render.

In comparison, React alreayd handles all of that for you.

> The cognitive load is a fraction of what's needed for frameworks like angular or react.

Since you mentioned lit-html, that "lightweight rendering library" has all the "cognitive load" of React, and is getting more complex

> So you need to bind together a connectedCallback and some rendering library

It's no different than jsx, you just get to pick whatever you want. I honestly believe that 90% of the dislike for WC comes from the name "connectedCallback". If they'd named it "onCreate" or something, everyone would be using it. It's named that because it's the lifecycle method for when a component becomes connected to the DOM, so it's technically correct - a component can be created and function without being connected to the DOM. But people really hate that name for some reason.

It's all the same stuff. You have to do all the same things regardless of framework. You declare a template somewhere, you define the props that will cause a render on change, and you keep track of the internal state of the component. With React or angular or vue or whatever, you still have to do all this, you just incur the cost of a massive framework too.

> So you have to manually wire class properties to manually call render.

Yeah, 1 line of code. And in exchange you get to avoid a whole framework, get much better performance and have real control over your component's render cycle. Also, you still have to do this with react, it's just a different syntax.

> Since you mentioned lit-html, that "lightweight rendering library" has all the "cognitive load" of React, and is getting more complex

Huh? Lit-html is simpler than handlebars. Are you confusing it with LitElement?

(( I've split my reply into three parts to avoid a wall of text in a single comment.

I may run into "you're posting too fast, so not all part may appear at the same time" ))

Part 3.

> Huh? Lit-html is simpler than handlebars. Are you confusing it with LitElement?

Of course not.

At the time of writing lit has:

1. A custom DSL for writing HTML

      <some-tag
          attribute=value
         .property=value
         ?boolean_property=value
         @event_listener=value></some-tag>

2. A custom JS DSL in the form of custom directives. Currently there are 12 of them.

They may look like regular functions, but they will throw an error if you use them outside of their scope.

Example:

    // is fine
    html`<p class="${classMap({someClass: true})}">Hello, world</p>`

    // Unhandled Promise Rejection: Error: `classMap()` 
    // can only be used in the `class` attribute 
    // and must be the only part in the attribute.
    html`<p style="${classMap({someClass: true})}">Hello, world</p>`

(Note: that error is incorrect because you can write `class="other parts of the attribute ${classMap(...)}"`)

More stuff is coming to lit, of course, such as contexts, server rendering etc.

(( I've split my reply into three parts to avoid a wall of text in a single comment.

I may run into "you're posting too fast, so not all part may appear at the same time" ))

Part 2.

> You have to do all the same things regardless of framework. You declare a template somewhere, you define the props that will cause a render on change, and you keep track of the internal state of the component.

> ...

> > So you have to manually wire class properties to manually call render. Yeah, 1 line of code.

So, there are two issues with these statements.

Main one is this:

So, for each property you need to track you need to manually call render. For each property in each component you write. Where in React, Vue etc. you... don't have to write that "1 line of code" at all.

And of course, "cause render on change" is trying to completely ignore the realities of re-rendering. If you "just call re-render", yo will run into a whole host of issues.

Example: You have a text box that has constraints on min and max number of characters. When constraints are validated, you want to re-render the input box with a red border. Well, the problem is: if you just re-render it, you will trash existing HTML, and replace it with new HTML, losing input focus.

And that's even before going into the fact that you want to minimize the amount of things you need to re-render. And "just re-rendering" trashes significant chunks of HTML.

That's why other frameworks (including lit) are not "just use template, track internal state and re-render". They track all the places where changes may happen, they keep track of user focus and input, many try and maintain scroll positions when large html changes happen.

---

The other issue is that it's not just properties, of course. It's also attributes.

Web components had a perfect opportunity to remove the distinction and only go with properties, but that opportunity is squandered. And the problem is: you can't reliably distinguish between the two. That is why libs and frameworks either give up and provide different syntax for setting them (like lit's `.property=` and `attribute=`) or rely on runtime heuristics.

And this is evident in the absolutely atrocious API surrounding attributes where you have to painstakingly manually sync attributes with properties in `attributeChangedCallback` with a bunch of `if name === "x" then`. Oh, and it's completely divorced from the `observedAttributes` callback because of course it is.

(( I've split my reply into three parts to avoid a wall of text in a single comment.

I may run into "you're posting too fast, so not all part may appear at the same time" ))

Part 1.

> I honestly believe that 90% of the dislike for WC comes from the name "connectedCallback". If they'd named it "onCreate" or something, everyone would be using it

Of course not. None of the criticism towards Web Components ever mentions "connectedCallback", or how it should be named differently.

Do you know the actual reason so few are using them? Let's skip the atrocious not-really-high-level not-really-low-level imperative API that they offer.

How about:

- 13 years after introduction they still need 20 more specs to try and patch just some of the holes in their original design: https://w3c.github.io/webcomponents-cg/2022.html

- Shadow DOM is infecting every spec so that the actual useful specs like Scoped CSS have to be delayed almost indefinitely to try and figure out how to work with this abomination of a design

To quote the report linked above, "many of these pain points are directly related to Shadow DOM's encapsulation"

- The amount of specs that are required to make them work, barely, and be "good web citizens". And the amount of APIs.

Oh, you want your custom input to a) be able to send its data in a form, and b) be accessible to a label outside of your component? Well, there's a separate API for a) and there's some separate future API for b). And meanwhile your custom button won't be able to submit your form, sorry, it's a 4-year old issue with no solution: https://github.com/WICG/webcomponents/issues/814

And all that despite the fact that there are already a dozen specs covering web components, and dozens more on their way.

- Web Components ar HTMLElement. It means you cannot use them inside SVGs.

This is impossible:

    <svg>
      <x-axis min="2000" max="2019"/>
      <y-axis min="0" max="100"/>
      <scatter-plot points="..."/>
    </svg>

This makes them unsuitable to a huge swath of graphics- and visualisation-related applications.

- A smattering of other issues:

-- They cannot be easily used when progressive enhancement is required: SSR story is still non-existent, you can't easily update the original DOM in a custom element without trashing it.

-- They cannot be easily lazy-loaded because slotted content is eagerly loaded:

    <p>Toggle the section for more info:</p>
    <toggled-section>
      <html-include src="./more-info.html"/>
    </toggled-section>

`html-include` will load in its entirety even if you never toggle the section. And yes, this causes a cascading loading of multiple resources, too.

-- they share a flat global namespace. Of course this will be solved in the next five years by a yet another spec.

--------------

If any userland framework had these many issues, it would be laughed out of the room. And yet here we are with people trying to argue that they are good now actually and all that stops them from being used is "connectedCallback" name.

These are also the reason why most framework authors that initially supported web components (Vue, Svelte, Solid) are now at best completely indifferent towards them.

Not going to go through point by point, because this isn't a great format for longer form discussion.

In general, the points you're raising apply to edge case use of WC.

Most of your gripes are around shadow dom, and I understand that and agree with you - CSS parts and all that stuff are pretty bad. However - I don't use shadow dom. It was intended to be low level API for when you need to author with complete encapsulation.

I've been doing native WC for years and I've never run into a situation where I need shadow dom. Or slots. Or any of that stuff.

The "attributes" vs "props" thing is a html/dom issue, not a WC issue, and again - just about any rendering library will deal with it for you, the same way react or vue or whatever does. It's an utter non-issue in normal development, I write WCs every day and haven't even thought about that in forever.

SSR and lazy loading are anti-features for me. If you really want them with WC the sure, jump into a framework like stencil, but I have zero use for them.

SSR is all about SEO and FCP, and I've never really grokked it's usefulness.

If I need SEO I don't do UI SPA stuff, I just write server side, and I don't need a component framework for that. FCP (first contentful paint) is already a gazillion times faster with WC than any framework I've ever used. The whole point of lazy loading is to defer work until it needs to be done, but you already get that with reactivity - you trigger your component data load on a property setter anyway if it needs to load, and if it's just rendering off properties there's no need for a lazy load.

The TLDR is that you're making this massive straw man argument about bad API with WC, but it's for this tiny edge case of use that's only intended for library authors and such.

The 99% use case will never encounter any of that.

I could build up a big(er) wall of text about the same sort of stuff for all of the frameworks too.

When you want to do complex things - it's complex.

In years of WC work, light weight components using light DOM and a little templating library - I've run into the issues you're talking about exactly zero times.

Also, you may want to double check your understanding of frameworks use and embrace of WCs.

> edge case use ... I've ... for me ... I ... straw man

This is why I hate engaging into any arguments with proponents and apologists of web components.

Any concern and criticism is brushed away as non-existent and insignificant. Even if the actual people who develop this and push this into the browsers are now marking them as not only valid, but a significant problem.

But sure, do keep telling yourslef that theonly reason why more people don't use them is because people don't like the name "connectedCallback"

> you may want to double check your understanding of frameworks use and embrace of WCs.

Please do this yourself. Outside of frameworks and libraries that explicitly advertise themselves as being 100% based on web components (like lit and stencil) almost no one uses them as the foundation. They may consume them, and they may have a way to compile components to them, but almost none actually use them.

And yes, keep telling yourself it's because of "connectedCallback" naming.

> Now that the platform is evolving and innovating again, more and more things are moving out of the frameworks and back into the platform. Javascript has massively improved.

A language so good you need to write another language that compiles into that language to make it tolerable.

> Some amazing and complex engineering happens in the frontend space because of the constraints and the need to eek performance out of everywhere you can. You can't just throw more servers at the problem.

I'm not sure about this opinion. Most websites are slow as all get out and require me to download the world to even get working.

> Experiences vary, but I've been on more projects delayed by over-engineering the backend than the frontend.

As a person on the backend I can tell you your definition of "overengineering" is ignoring the fact we have to deal with frontend cowboys all the time. When SEVs happen it's us on trial almost universally. Just the absolutely bonkers states a frontend can accidentally end up in despite good testing is enough to warrant "overengineering" to try to support it.

We had an opportunity to kill javascript and instead we embraced it. We deserve what we get.

> A language so good you need to write another language that compiles into that language to make it tolerable

If static typing is your thing, I guess. It's not for everyone.

> We had an opportunity to kill javascript and instead we embraced it. We deserve what we get.

Some of us quite enjoy the language.

> A language so good you need to write another language that compiles into that language to make it tolerable.

Some people need it to make it tolerable. That happens on every platform. You have Java and Kotlin/Scala/Groovy ... Microsoft even created F# to its C# ...

> We had an opportunity to kill javascript and instead we embraced it. We deserve what we get.

You mean VBScript? Or what other opportunity you mean?

I often get the sense that JS haters last saw the language in 1999. Modern JavaScript is a very nice scripting language. Succint, elegant, functional.

Its major omission is the lack of static typing, but JSDoc and WebStorm make it tolerable.

That’s something people have said for a while but I’m pretty sure React was the main thing people were moving towards 5 years ago and I think, for the most part, people are still using react. That doesn’t sound like constant churn or people switching frameworks all the time (caveat 1: react has changed from eg classes to functional components and hooks; caveat 2: maybe front end is broken into groups and one picked up react 5 years ago for two years, another picked it up four years ago switching away after two years, and so on, and I’m just combining them all as ‘used react for five years’ in my head).

I feel like the churn has gone down over time. But maybe that is also a decrease in my personal interest in front end as well as posts here (I recall there used to be a lot more frontend related posts here ~10 years ago)

5 years ago I was the lead architect on a v2 rewrite project of about 30% of our app.

We considered React but the landscape was also full of Angular and Vue and a bunch of others I don't remember.

At the end of the day, we went with the latest version of our boring server side rendering library that the rest of the app used. A huge reason was the churn in front-end javascript libraries.

I've never once regretted that decision and the project was a big success.

"we went with the latest version of our boring server side rendering library that the rest of the app used."

Boring tools are the best thing ever. What did you use?

We went from JSF1 something to JSF2 something.

Very boring but there was so much technology change already in this rewrite that we chose to limit the amount of new stuff for everyone to learn especially when we didnt know if it would be applicable to anything in their future career.

”especially when we didnt know if it would be applicable to anything in their future career.”

Wow, you made architectural decisions based partly on optimizing the employees career development? Kudos! I’m not sure how common actually investing intentionally in engineers careers is?

Seems to confirm his point, and matches my experience as well. Front end has largely standardized on React. Vue is a distant 2nd and Angular is really not even considered for new projects.

About six years ago I went backend to avoid the React churn, hoping it would eat itself by now. Unfortunately that didn’t pan out. Apparently it’s the new Struts.

The thing that these young and/or inexperienced developers don't understand is: Frameworks are not your friend. Framework projects are not created with your benefit in mind. Frameworks are created as an opening salvo so that some developers or organization can gain a foothold in the landscape and start collecting money from consulting contracts. The reason there are 1,000 React alternatives is not "people like signals more than hooks", the real root cause is 1,000 people want to steal market share from React so they can get paid as a consultant. "I like signals more than hooks" folks are just useful, predictable pieces of the landscape to be manipulated in this scheme.

Frameworks are your friend; either the one everybody used or the one you invariably end up writing from scratch for yourself for every project.

Indeed, a framework written to be used for a project has a limited amount of time where it's your friend. Until the big 2.0 rewrite comes out and they changed the API completely, and the clock starts counting down to the rapidly approaching 3.0 release where they will rewrite the API, before two weeks later announcing 4.0 alpha 1...

Maybe it's just because I'm old and grumpy and have seen lots of things come and go, but I don't understand how some frontend devs even have this much time to obsess over their tools.

It would be like car guys spending more time arguing about whether Snap-on is better than Craftsman than actually talking about and working on cars.

Snap-on and Craftsman are actually pretty antiquated tools by modern car guy standards. If you want a real wrench you go with a Mac RBRT - it’s the new hotness in combo wrenches but there are decent alternatives out there from Wright and Proto. Here’s a great video showing things you might have missed if you’ve been in Craftsman world for a while[1].

[1] https://youtu.be/hxtgWSpTC0o

I have absolutely no knowledge in mechanical engineering before and I am now really in a youtube-binge about wrench. Not sure it is a good thing that I can get captivated by absolute random topic or a bad thing because how technology just suck up our attention.

Have you met car guys? :)

> but I don't understand how some frontend devs even have this much time to obsess over their tools.

most of us don't. these comments are mostly from people whose idea of "web development" is a form and some static content.

Have you seen r/tools?

I thought the SnapOn koolaid was stale fifteen years ago. Turns out no.

It's disheartening to realize that the frontend space is no better now than when I began my career in 1990. And it's also disheartening that even though computers are like 5000 times faster now, that they feel slower to me as a developer and as an end user.

Nah, you're just focusing on the opportunities to improve rather than counting the victories. Here's my top 3 big steps forward of the last 20 years:

* Webapps don't need to be installed

* Webapps work on all platforms without vendor lock-in

* Webapps aren't trusted and get sandboxed by default

and a bunch of minor victories along the way (you can right click -> inspect every webapp, APIs generally exist and have entered the cultural lexicon, cross-site SSO exists and works).

These are good points.

At the same time, a lot of the UI tooling and APIs feel like we went back 30+ years. Everybody is still reinventing the pop-up menu button (aka “select”). I really thought this was a solved problem in NeXT by the early nineties.

> Webapps don't need to be installed

Was true of what I was doing in 1988 too.

https://en.wikipedia.org/wiki/Andrew_Project

vrml was also invented 30+ years ago but we're not lamenting that webgl is solving an already-solved problem.

https://en.wikipedia.org/wiki/VRML

Telemetry, ads, SAAS, terms of service, data breaches, platform effects.

Wholeheartedly disagree.

Advancements to CSS have made front-end way more reasonably than they were in the 90s. Stuff that took weeks to figure out with tables can now be done so quickly with `display: flex` and the whole grid system. It's beautiful.

If we had `display: flex back` in 1998 I probably wouldn't have stuck with FE rather than dive into the backend.

Web dev (as in: HTML and CSS) improved a lot in the last 20-30 years. But if I had to quickly make a fully functioning interface and had the choice between today's web and 2002's Delphi 7 I'd choose Delphi 7 in a heartbeat. And just look at what non-technial people were able to do with Macromedia Flash in the early 2000s. You need experienced frontend devs to recreate what designers did as a hobby back then.

Of course those solutions don't solve the transition between desktop and mobile layout (since that wasn't a thing back then), but more some modern frameworks solve that well (like whatever MS calls UWP right now) without forcing everyone to reinvent a way to do infinite scrolling without running out of memory

This reads as if written by someone with rose tinted glasses.

+1. would love to see an example of something created in Flash by a single designer that takes a team of frontend devs to create today.

fyi folks, Flash is also based on ECMAScript! just because the mid-90s tooling built by Macromedia triggers your nostalgia doesn't mean it was better!

If he is comparing things to 1990 then that means he's using "frontend" to included non-web UI tech as well, in which case flex vs tables isn't really the main point of comparison.

Nah. Tables were easy. All the craziness came with people using <div> as <table>. That was only recently fixed by flex box.

Agree. I did CSS before flexbox was available, and I have no ideas how I did before. There is tons of very good stuff coming our way in CSS (such as container queries), better ergonomics for Javascript, excellent tooling in the browser, stuff to be optimistic for, not just all this madness about the framework du jour.

I think this is what they meant by rediscovering or reinventing new things over and over. Yes, display:flex is newer than XUL and different in some ways. But 20 years on it seems disappointing that display:flex is perceived as such an advancement by those who have forgotten or never knew the past.

What? A few days ago I gave up trying to write a moderately complex component based on flex-grid. The number of options, and all the quirks of them, was overwhelming, and in the end I couldn't even get the basic behavior I wanted. Maybe i will try again some other. I think display: flex is very useful, display:grid is too complicated with the way they designed it.

It was all backend in 1998.

PHP running as lambda functions^W^WCGI. Those were the times.

What's wrong with this?

   float: left;

Oh wait… that was 2002 at least.

"Tables ought to be enough for everyone."

There we go! Nailed 1998!

Wow, I guess I really needed the sarcasm tag there. It appears some folks didn't get that this wasn't aspirational.

Dont forget clear:both; !

I was writing software when I was 12 in Clipper. The industry became riciculously slower since then.

The industry, sure - but the tools exist today to get things done faster than ever before. It is the people that are the problem, as always!

> It's disheartening to realize that the frontend space is no better now than when I began my career in 1990.

I disagree. Since I started programming some 20 years ago, I relearned web (and especially JS) every 5 years or so. And each time I was pleasantly surprised at how much simpler / elegant / clean things have become.

> that they feel slower to me as a developer and as an end user.

that's true though.

It possible (and even simple!) to make web-apps that are almost just as fast, but no one does that (at least not in the main stream).

Alternative history! I began my career around the same time, and I remember applications taking minutes to start up, Word/Excel crashing and corrupting your file with regularity, and all kinds of horrible anti-patterns. Applications always are as slow as users can tolerate, which roughly end up being about the same over time, but tolerance is typically lower these days.

What are you smoking?

The web has developed immensely since the 90s.

If some UI you use is slow it's certainly not because of the excellent frontend/web technologies we have today.

There are certainly many things to complain about regarding the state of the web but the frontend technologies are not to blame.

But it's been like this for more than a decade now.

Frontend work is unglamorous to a lot of developers but part of the more academic appeal is that it's still very much in its awkward teenage phase. That makes it appealing to tinker with and try to find a "better way." That's the churn.

It's been like that for at least 3 decades - which is how long I've been doing such work. I disagree with your assessment of it being an "awkward teenage phase". The rate of churn is accelerating while nothing really new theory-wise has been added. I agree with the parent post:

> disproportionately composed of young and/or new and/or self-taught developers who "discover" new paradigms constantly

> It's been like that for at least 3 decades

I've been there since the start, too. I disagree that it's been like that for that long, though. JavaScript was an awkward add-on at first, then a barely usable tool (early vanilla), then a stopgap measure to fix browser compatibility problems (jQuery, moo tools, underscore etc) and start to flesh out some libraries.

But the Angular/React phase was the first time people gravitated toward using the frontend as a proper language. Before then it was just a thing you had to deal with.

So 3 decades? Nah. 2 decades of "why do we have to deal with this" and 1 decade of "ok let's make this work somehow"

36 years at least. I'm not talking about WWW. HTML and JS were never meant to be the end-all of human computer interaction, but yet here we are.

I imagine an alternative history where good distributed software got traction.

> 36 years at least. I'm not talking about WWW. HTML and JS were never meant to be the end-all of human computer interaction, but yet here we are.

I have to be honest I don't know what you mean here.

The web and its frontend (and tooling) is what this thread is about. We've thrown out a lot in the mean time. Java applets, Flash/Shockwave, ActiveX, dynamic HTML ... the web has grown a lot and will continue to do so.

But the world of JS as a front-end application language is still fairly new. Until the late 2000s it was just a bolt-on for doing little things around static HTML.

The thread has been extended to cover all distributed front-end paradigms.

But your complaint was about HTML and JS being all there is? I'm not sure what it is you're looking for.

That is my complaint. And yes, I don't know what I'm looking for. All I can say is that the stack that I used 35 years ago was just as good as what I use today. An even more senior developer than myself says it this way. Humans achieve a certain level of complexity and sophistication in any given domain and have an hard time increasing it. I think we've arrived at that point with UX frameworks, and we did decades ago.

> But the Angular/React phase was the first time people gravitated toward using the frontend as a proper language.

Don't forget Backbone which preceded Angular by checks 7 days.

> The rate of churn is accelerating while nothing really new theory-wise has been added.

There's plenty of novel stuff out there, it just takes a long time to filter down to the mainstream. React hooks are probably the best example here: they're a crude approximation of an algebraic effect system from the early 2000s.

This comment smells like gate keeping to me: "developers who work with frontend tech aren't REAL developers".

Personally, I know many developers who are doing great work with frontend technologies. Some with little experience, some with decades of experience, some self taught, and some with formal CS degrees.

Frontend is a great career path for those who enjoy it.

I'm not sure where you read "developers who work with frontend tech aren't REAL developers" but it wasn't the comment you're replying to.

I mean, he did literally liken them to insects though...

...as long as the given front-end is done with a sane language using sane frameworks like Windows / Mac / Linux or iOS / Android.

None of those are frameworks.

They all come with a good set of standard frameworks?

Web ships with barely anything and when it does have something like Date handling people still write replacements for it because it's so bad.

I agree with you and think the eternal september effect is probably the largest factor working against advances in frontend dev but would posit a couple more: 1) front end dev is generally underestimated and under respected in terms of complexity, I have had many devs say “you are basically just building a json viewer” over the years which is somewhat true but a great oversimplification 2) the closer you are to the user the more ephemeral and hard to reuse your components are, and business incentives work more strongly against reuse because the higher ups can actually see the work that is being shared.

> business incentives work more strongly against reuse because the higher ups can actually see the work that is being shared

Can you talk more about this one? I think this is getting at something I've seen but have been unable to articulate thus far.

This is me. But the reason for this being the space is inundated with front-end frameworks - like there's a new one out every week. The nature of the industry is that you have to be up to date with everything. Like I had worked on Angular at one point but recently had to work on an older version and I couldn't figure it out easily. React was decent but now there's NextJs and Svelte etc.

NextJs is still react.

Well put. On the other hand, I pray that the industry doesn’t ossify right now around Facebook’s dominant framework. Sweet Jesus, anyone but Facebook.

It's open source, who cares who the originator is?

Tell that to people who're moving from the open source CentOS project.

tl;dr: I love web development again.

You obviously haven't tried Svelte yet. I would have agreed with you a few years ago though.

The churn as I've seen it has been a direct result of React's ecosystem, not in spite of it. Here's a partial list of React libraries that just provide state management:

    MobX
    Recoil
    Redux
    Akita
    Context
    Hookstate
    Zustand
    Jotai

Just for state management! And all exist solely because React state management is a monumental fustercluck.

Then you get into React API nightmares the article mentioned that have nothing to do with HTML, CSS, and JS but have everything to do with React's API quagmire.

You may scoff at pointing to Svelte as "just a new shiny", but it really is getting back to the web's roots. Htmx as well. I've been doing web development professionally since 1996. I have hated web development since soon after React was introduced. React solved a lot of big problems to be sure, but it introduced its fair share as well as made web development tedious in a way I hadn't experienced before. I wasn't developing for the web anymore; I was developing for React. I constantly felt detached from my actual target. Wrapper after wrapper of familiar vanilla libraries to shoehorn into the React ecosystem rather than living alongside it.

Svelte (and Htmx to a lesser extent) gave me back plain ole HTML & CSS. Svelte also gave back that simple JS that described the problem I was trying to solve instead of endless boilerplate on an API layer on top of the browser API.

Vue got close but didn't go far enough. SolidJS just made a faster React. Svelte and Htmx embraced the web with no holding back, and I love them for it.

so you'd prefer that there was only one state management solution for every webapp? what if i don't need 99% of the features of this monolith library?

Seriously, try Svelte. See how its Stores API works. For bonus points, look at the Context API. Between Stores, Context, and what looks like plain ole JS in the component, state management is a solved problem. With all due respect, calling it a "monolith" out of hand just screams you haven't even looked at solutions and don't know what you're talking about.

SolidJS stores work the same.

In other words, this is basically a solved problem unless you live in the React ecosystem.

What state management does Htmx provide?

Htmx defers almost all logic to server side. That's the tradeoff, and it's a major shift from what we've become accustomed to in the last decade (unless you've been writing PHP or something similar).

You provide listening points to various parts of your app, and when something changes, all points listening to that key also make the corresponding call to the server for refresh. It sounds hokey, but it's very effective, very efficient, and pretty easy to wrap your head around.

Deferring all logic and state management to some mystery and messy server-side black hole? Sounds like a monumental fustercluck.

Not any more than REST is. Server-side rendering doesn't have to be messy. In fact for most modern frameworks, it's become table stakes.

And how many libraries and frameworks and methodologies are there for server-side state management?

State on the server side is often a very different animal from client side. Whereas on the client, everything is either JS and/or a browser API, the server side allows for relational databases, Redis caches, and all sorts of other strategies, some based on session ids while others using whatever fits for that scenario. "It depends" but it's not just a library or framework as you'd imagine coming from frontend development.

Htmx is quite popular among folks who prioritize and enjoy server-side development. Svelte is likely more popular among folks who enjoy browser-based development. There is certainly some overlap between the two camps, but that's my take on it.

Wow. Relational databases, Redis caches, session IDs, different strategies for different scenarios... sounds like a fustercluck, no?

Not if you're a backend engineer. Then again from their point of view, they consider frontend state management to be a hopeless mess. Takes all kinds.

And why does a backend engineer's point of view on frontend state management matter? Why is a variety of options and strategies for different scenarios ok for the backend but not for the frontend?

The frontend has… a browser. It's a much more constrained toolbox. You are forced to use JS and whatever browser APIs made available to you.

The server side is only limited by what can run in a datacenter. Any language. Any service type. Any scaling profile.

Neither is more "correct". Both have pros and cons. As for why the backend engineer's point of view matters: if you are server-side rendering, you will have a better chance of going faster. A browser will always render HTML faster than JS that generates HTML on the fly, and the server side can always be made to generate HTML faster than a browser could. You can always simply throw more hardware on the server side to speed this up whereas you have basically no control over the performance profile of a random user's browser.

Look at Google search results. It's typically not JSON over AJAX; it's rendered HTML dropped into place. Why? Because every millisecond can be quantified into gained/lost revenue.

So why is it bad to choose a frontend state management strategy in a way that maximizes revenue?

> Neither is more "correct". Both have pros and cons.

I think frontend state management is a completely legitimate choice if it fits your use case.

Are you aware that these things still exist in apps no matter what kind of state management they use?

I remember when CSS was brand new. When IE5 had the first DOM. When jQuery took over the world. That's all like 20 years of time.

> ...Server-side rendering isn’t special anymore..

quietly dries tears using pages ripped from ASP.NET For Dummies

Those developers are immature.

JS was always here to stay. Wether you like it or not. Come with solutions instead of leaving it to someone else, or worse complaining.

JS was always super exciting, with a few lines you could build entire applications.

It's not so much about JS somehow being a language like no other, it's more about the web: HTTP, HTML, DOM. And XHR/fetch - JS wasn't exciting before them.

Could you please elaborate on this statement: "The developer community being disproportionately composed of young developers" ?

That's simple enough. Look at StackOverflow's survey (or any other) over 50% of professional devs have less than 10 years of experience.

That's 2013 or the year React came out and a full 5 years after the launch of Chrome/v8 started the next round of the framework wars.

On the frontend, things are even worse. Salaries started to skyrocket 7-8 years ago and the number of people suddenly interested has skyrocket every year for the past 5-6 years.

> Look at StackOverflow's survey

Part of the problem with this methodology is SO is useful among the most junior devs. For example, I haven't been to SO in several years but it was my go-to site in 2010.

The very large State of JS survey skews to even less experience overall with nearly 30% having less than 5 years of experience and a bit over 50% having less than 10 years of experience.

https://2021.stateofjs.com/en-US/demographics/

Yea i also noticed recently that survey is actually really skewed in that directio. And as such shouldn’t really be used as basis for any “state of the developer landscape”

You've misquoted, but I think the intent was clear; (commercial) front-end is more likely to get less experienced developers as the entry requirements are slacker at the lower end.

This lack of experience carries with it the same flaws and risks (and occasional benefits) that inexperience carries everywhere.

I see this as a problem to be solved in the software-education space

It totally could be solved. Make it a licensed profession. Make it like the legal practice where you have to go to school for 3 years and then pass a test to get your license. Only half joking.

agree with testing and licensing (and unionizing) but is there any particular reason people should have to go to school? one of the great things about the software industry is that anyone can teach themselves and make a healthy career out of it - would be a shame to add what might be an unnecessary gatekeeping requirement to one of the last few accessible career-paths with upward class mobility

The sad and ironic part is that additional gatekeeping won't produce better results anyway.

I think the results would be better as all practitioners would be well-versed in theory and practice. And of someone pitched a very novel approach, it would get more scrutiny. Of course we should be open to new approaches - just not for the sake of it being new.

I don't agree because current graduates aren't necessarily well-versed in theory and practice. In fact I've worked with CS graduates that don't understand theory at all and follow the worst conceivable practice. Of course CS education isn't standardized and I'm not talk about Stanford grads here. But I have a hard time believing that simply erecting barriers that require education will improve the situation when a lot of educated people still have no idea what they're doing.

The same question/discussion happens in the legal profession - and they have largely settled on the answer being "yes, you have to go to school"

IMHO, you can't have one (testing and licensing) without the other.

I've worked with plenty of educated developers who couldn't code their way out of a paper bag. One of our local universities has a shockingly bad program that's reproducing their own unique little brand of terrible bullshit. I've spent half my career fixing the messes they leave behind at various companies in the area.

I think left to our own engineers would have resolved to something like this already. The issue as I see it is corporations and business people have taken over the leadership of this trade to rake in money regardless of what it does to the real world.

And why wouldn't they you can create a problem out of thin air, solve the problem poorly selling the solution, and then when your rushed, half assed and bad solution has issues, you can simply sell the fix to that as well.

I doubt we will see much progress in the quality and rigor of software engineering in the near term, it will need to take a shift from making money in the short term at any cost to making a quality product. Instead we see the same thing happening to other industries so I hold little hope in the near term.

Reply on news.ycombinator.com