4 ms·

This became the most toxic part of web development... the tech stack. Its why I went to go do something else. Holy fuck, all you need is a server application,

This became the most toxic part of web development... the tech stack. Its why I went to go do something else. Holy fuck, all you need is a server application, a database, HTML, JavaScript, and CSS to make a CRUD app. Seriously, that is really all you need. The problem though is that nobody trains developers any more and so you get a little bit of helpers to help the developers along, which turns out to be a mountain of bullshit that developers use to line their resumes like notes on toilet paper. As a counter point I wrote a large single page app and then adapted it into removable modules that can be turned off from a JSON file. So, its modular, which then solves for the design goal of most modern JavaScript browser frameworks. But, it's just vanilla TypeScript. It is stupid simple to scale, extensions from one of two TypeScript interfaces without tech debt. The best part is that its fast... like completing all initial execution, rendering, and garbage collection in less than 130ms. https://github.com/prettydiff/aphorio/blob/screenshots/papers/performance_browser_2.md https://github.com/prettydiff/aphorio/blob/screenshots/paper... So, in practice it seems you could easily replace 10 React/Angular developers with a single TypeScript developer and a series of small TypeScript interfaces. The bonus is that you get faster releases, 100% accessibility (because its mostly raw HTML instead of compiled templates), and a substantially faster product.

codyb 10mo ago
Nobody builds anything modularly. It's very weird. I've come into codebases at my current big co where 15 tables that all looked and acted exactly as terribly as one another (no sorting, no discernible sort, no filtering, limited page sizes, no search beyond CMD/CTRL-F) And they were all built out one by one, every time. What a mess, why! I consolidated everything down and am now bringing up both an App URL Param library other folks can use, a generic resource engine other folks can use, and a table engine which combines the two to give you most table functionality with a simple config and passing in the resources (We're internal tooling for small record sets so a lot can be handled on the front end since resource baseline can be assumed and customer count is low). Even when you build things modularly people will give you grief. It's over engineered. Well, you say that, except it's testable at the unit level, easy to slide in to other use cases (which the test cases help ensure resiliancy for old and new), small, not nested, discoverable, flat, easy to read, and easy to maintain. So sure, took a couple of extra hours of legwork up front compared to just dropping everything into a single React function as is the standard round these parts, but the benefits are clear.
gchamonlive 10mo ago
The article is, however, about a different kind of stack.
- owebmaster 10mo ago
  OP has an obsession with how every web/JavaScript developer is terrible besides him
  - austin-cheney 10mo ago
    How do you know when you don’t suck?
    - gchamonlive 10mo ago
      I don't think you can. Success is circumstantial, failure is personal. Sucking is the only way to know your limits.
      - austin-cheney 10mo ago
        The management answer is that you compare yourself against your peers using qualified metrics. You stop sucking when your numbers are high enough on your organization's bell curve. Most developers can't measure things, and most organizations won't train them, which limits them to forever sucking at what they do.
        gchamonlive 10mo ago
        But by then it becomes a number game and it stops being about quality but about optimizing given metrics. If you can you should always strive to suck less. If you can't then it's time to maybe seek some other working environment which will enable you to do so.
        brazukadev 10mo ago
        I have had the opportunity to try your optimized JS code and it sucks tho. It is almost comedic seeing you bragging about such a "blazing fast" bad app.

codyb 10mo ago

Nobody builds anything modularly. It's very weird. I've come into codebases at my current big co where 15 tables that all looked and acted exactly as terribly as one another (no sorting, no discernible sort, no filtering, limited page sizes, no search beyond CMD/CTRL-F) And they were all built out one by one, every time. What a mess, why! I consolidated everything down and am now bringing up both an App URL Param library other folks can use, a generic resource engine other folks can use, and a table engine which combines the two to give you most table functionality with a simple config and passing in the resources (We're internal tooling for small record sets so a lot can be handled on the front end since resource baseline can be assumed and customer count is low). Even when you build things modularly people will give you grief. It's over engineered. Well, you say that, except it's testable at the unit level, easy to slide in to other use cases (which the test cases help ensure resiliancy for old and new), small, not nested, discoverable, flat, easy to read, and easy to maintain. So sure, took a couple of extra hours of legwork up front compared to just dropping everything into a single React function as is the standard round these parts, but the benefits are clear.

gchamonlive 10mo ago

The article is, however, about a different kind of stack.

owebmaster 10mo ago
OP has an obsession with how every web/JavaScript developer is terrible besides him
- austin-cheney 10mo ago
  How do you know when you don’t suck?
  - gchamonlive 10mo ago
    I don't think you can. Success is circumstantial, failure is personal. Sucking is the only way to know your limits.
    - austin-cheney 10mo ago
      The management answer is that you compare yourself against your peers using qualified metrics. You stop sucking when your numbers are high enough on your organization's bell curve. Most developers can't measure things, and most organizations won't train them, which limits them to forever sucking at what they do.
      - gchamonlive 10mo ago
        But by then it becomes a number game and it stops being about quality but about optimizing given metrics. If you can you should always strive to suck less. If you can't then it's time to maybe seek some other working environment which will enable you to do so.
      - brazukadev 10mo ago
        I have had the opportunity to try your optimized JS code and it sucks tho. It is almost comedic seeing you bragging about such a "blazing fast" bad app.