mistersys

My man must not write JS

title is confusing.

SQL announces: 2023 is finished, on April 13th, 2023.

In my experience in tech, most teams directly access and manipulate production frequently. Bigger companies usually have restrictions on this but in the start up world not so much.

I had a similar experience after switching to DVORAK as a nerdy teenager, however I found by just leaving my smartphone on QWERTY, I'm able to switch and still type 40 - 50wpm with minimal practice on a real keyboard. I'm more like 100wpm on DVORAK.

Practicing both layouts a little may make it possible to keep both modes in your head, but I don't know if a completely different input mode would make this harder.

No need to be pedantic. He's obviously saying that there are better strategies then vDOM with lower overhead.

This is proven by Solid.js which is faster then every VDOM framework, has an API that is functionally the same as react, and doesn't use VDOM.

Solid.js is even faster than inferno, and it doesn't really use a VDOM strategy, uses a strategy much more like svelte. IMO svelte is just poorly implemented from a benchmark perspective.

In reality, most of these benchmarks are not meaningful when talking about real app performance. What's meaningful is how you do global state updates in your app. If you use a react app with react-hook based context providers that unnecessarily update hundreds of components on simple changes, you perf is going to suck. If you use a react app and don't use React.memo anywhere, perf is going to suck. If you use react very carefully and are fully aware of when the vDOM is going to run and use small components that only update when their data actually changes, and ideally avoid running vDOM 60 - 120fps a second for animations, performance is going to be good.

I like Solid.js because it does all this for you by nature of just using the framework. Svelte does some of this for you so for real world apps performance is likely to better than react, but it doesn't do it as well as Solid by nature of it's state management strategy, not by nature of it's DOM update strategy.

The less you update, the faster your app will be. Then the DOM diffing strategy doesn't matter.

https://news.ycombinator.com/item?id=34446673

Fun idea, but pretty unfun to play. Half the questions are just five, six different words you need to `|` together, and not enough time to even type out that many words.

Feels like the author thinks regex is a useful way to match a bunch of unrelated words in a paragraph. Not really the point of regex.

I also thought this. But then I remembered I had a $700 bike stolen from my hotel when I stayed in SF for 2 days. Checks out.

A successful Web3 (if we want to use the term) project should be unfundable to capitalists. That's what makes this so hard. Teach people how to not be wage slaves, then people won't throw away all their power to the already-wealthy.

It really feels like internet infrastructure has been growing more unstable. More outages, feels like way more bugs happening on my apple products as well.

I believe this is the result of the same thing that causes all the chaos in all human fields, lack of consciousness. We live in a very distracted time, COVID is still one more stressor on top of all the other things we have to manage in the world we've built to be inhospitable to mental health.

There's a shift happening in certain areas, but I think the old guard of tech is due for a revolution of some kind. My two cents, to start we need to stop building things with such low-level tools.

I think the point here is that we've worked ourselves into a corner with web technologies. The web is very reliant on GPU rendering, but when building an app with DOM + CSS, you don't have direct access to all that power. You have to be very careful to construct your application in such a way that it can be efficiently rendered, and actually use that GPU power.

Basically, they're getting rid of the middleman: the web. Think about most modern web frameworks (React, Angular, etc.), they're basically immediate mode GUI frameworks, but we do "virtual diffing" in order to translate our immediate-mode-like code into DOM (a retained mode UI framework), then the web renderers the DOM via immediate-mode-like patterns again. Pretty strange if you think about it.

Our stacks of technology are getting in the way of creating good software. So yeah, it's on old idea, but in light of the state of the art in IDEs and Text Editors today, this is an interesting approach.

Note, this is a problem in the first place because of how good the web is. The web has so much tooling, cross-platform support, and documentation / learning resources that it's being overused in places where it's very inefficient, simply due to momentum and mindshare. When you have a hammer...

Now, one of the biggest reasons for the success of the web is cross-platform support, but it's not just cross-platform support. It's the only write once run anywhere platform, truly. Most other cross-platform frameworks require you to think about the native environment at some point, but it's very rare on the web because of the robust standard library including Media access, Networking and even more rarely used APIs like WebMIDI. Not to mention that web design culture allows you to ignore the ui patterns of the native OS you're targeting, allowing more cross-platform savings.

If we can somehow manage to throw away the DOM + CSS (except, perhaps, for decoration) and replace them with immediate mode frameworks, combine that with WebAPIs for interfacing with hardware, and decouple those from JS (maybe via WebAssembly), then we have a competitor to the web for complex cross-platform software that is actually interesting. Perhaps Zed and their Rust-based GUI framework could help push us in that direction.

Edit:

Another aside, the performance of immediate mode GUI. You could argue that retained mode UI can be made to have better performance than immediate mode, but I think the right combination of caching and framework-level optimizations to allow for partial updates are the solution.

You might say "that's not immediate mode though?", and sure, but what we care about here is fast applications that are easy to build. We've discovered that writing code via declarative patterns has huge benefits over "object-soup", so our goal should be to make those patterns as fast as possible. I think the DOM and retained-mode GUI is a just a result of the Java style of Object Oriented obsession.

The JS Ecosystem + The AWS / Serverless ecosystem is a love story of the likes of Harley Quinn and the Joker.

This week I picked up a gig working on a website for a non-profit organization, the needed some basic changes to a few forms. The reason they had to hire me, a web app developer, the site was built by some agency with Next.js / Jam Stack technologies, Contenful, AWS Lambda, AWS Amplify etc.

This simple website, is one of the most complicated monstrosities I've ever worked with. Every page downloads multiple megabytes of JSON from the Contentful API just to render dead simple pages with text and images. Every time there's a change in contenful, a new build in AWS Amplify is triggered to generate the site to static content... only the React code is so complicated with so many round-trip, nested server requests (n+1+1+1 etc) that the builds fail constantly because the API server (on lambda of course) which serves the Contentful content basically gets DOSed. I had to write logic to retry all app API requests just to get the builds to consistently work so I could work on the website. The code that transforms these megabytes of JSON into webpages must have been written by a mad man.

Also screw AWS for not building proper tools to debug AWS Lambda. Not having to manage servers sounds awesome, so everyone has started using lambda, but the developer experience of having to wait 10 - 15 minutes just to add a console.log line is like pulling out your own finger nails and then scraping them on a chalkboard. Then AWS built the most noisy, difficult to use and hard to navigate log management solution on the planet (CloudWatch), and started sipping their beers.

You can avoid these technologies all you want, but one day you're going to have to work with a project that choose to use them, and you can't control that. I believe library authors and service providers have a responsibility to think about developer experience that's being ignored. Or perhaps, since developers don't always have a choice in the technologies they use, building easy to use developer tools isn't worth it.

This isn't really business logic... unless you're in the business of simply converting data formats.

As a data fetching approach and especially as tooling primitive to eliminate the n+1 ORM problem this is a terrific tool to be aware of.

Okay, yeah we can serve UI over the wire. It's possible to make it work. But the experience will never be the same as a a native application that's designed to handle offline functionality, interactivity and optimistic updates.

The Hey email client is great example, hotwired.dev was built for Hey.

Guess what? It kind of sucks. It's buggy and slow. Randomly it stops working. When the internet goes down, random things work, random things don't work. If it weren't for Hey's unique features like the screener, I would much rather use a native app.

There's a ton we can do to make the the developer experience of rendering on the client side better, but there's only so much we can do to make the user experience of serving UI over the wire better. When the wire breaks or slows down, the UI renderer stops working.

We built an internal tool for our team we call "restless", and it lets us write server side code in our project, and import it from the client side like a normal functional call, with full typescript inference on both ends. It's a dream. No thinking about JSON, just return your data from the function and use the fully typed result in your code.

We combine that with some tools using React.Suspense for data loading and our code looks like classic synchronous PHP rendering on the server, but we're rendering on the client so we can build much more interactive UIs by default. We don't need to worry about designing APIs, GraphQL, etc.

Of course, we still need to make sure that the data we return to the client is safe, so we can't use the active record approach of fetching all data for a row and sending that to the client. We built a SQL client that generates queries like the ones in the OP for us. As a result, our endpoints are shockingly snappy because we don't need to make round trip requests to the db server (solving the n+1 ORM problem)

We write some code like:

    select(
      Project,
      "id",
      "name",
      "expectedCompletion",
      "client",
      "status"
    )
      .with((project) => {
        return {
          client: subselect(project.client, "id", "name"),
          teamAssignments: select(ProjectAssignment)
            .with((assignment) => {
              return {
                user: subselect(assignment.user, "id", "firstName", "lastName"),
              };
            })
            .where({
              project: project.id,
            }),
        };
      })
      .where({
        id: anyOf(params.ids),
      })

Okay Cascading Style Sheets :)

It's weird, the only reason I can't use Apple Music is because it doesn't sync between devices. Apple being the company it is, it's just crazy to me that I can't pickup listening where I left off on my phone once I open my laptop.

Aside: Also there's a ton of bugs, very poor job on the QA side of Apple Music

Spotify has designed this feature amazingly. Sometimes, I wonder why companies don't steal good ideas from each other more often, it seems like Apple has just refused to implement this terrific user experience.

Yeah I don't think a cost breakdown on my drop ship products on Etsy would increase sales. We roughly double the price vs. cost of goods, but it's not like we're rolling in dough because at our volume fixed expenses take up a really significant amount of our profit.

Sure if someone is starting from scratch. We have Microsoft, Android and Linux which are alternative computing platforms, and android + linux are already fully ARM. Apple's chips are still much faster than most Android ARM chips, but Android ARM manufacturers are not starting from zero.

This seems like a reasonable argument, however I must say that buying content from iTunes is usually not cheaper than an Netflix subscription, unless you don't actually watch TV regularly.

With the highest level premium subscription of $17.99 a month you could only watch 4.5 movies a month, or 5 - 6 episodes of a TV show. I don't watch TV regularly, but if an average user watchtime of greater than 2 hours is accurate, as I'm getting from a quick search, that's more like 90 episodes a month.

Yeah this is the problem with the React ecosystem. I'm intimately familiar with this stack and used to use redux with "duck" modules professionally, complete with sagas and epics, and rxjs and the whole kitten, so it's not that I don't understand all the terms and am just overwhelmed. It's just that once you stop using Redux, it becomes so much easier to build and manage your app, and you don't even realize how much you're complicating everything by using sagas and actions creators and reducers and selectors and.. and.. and.

You don't even realize how bad the boilerplate is until it's all gone. With svelte and some writable and readable stores, I can build apps in a fraction of the time because every time I want to make a change I don't have to start with an action creator, than integrate that into the reducer, then write a selector, then pull it into my component. Oh I guess I need to write an epic with rxjs to fetch the data.

Svelte has 2 primitives that replace all of this: readable and writable. You can create a writable store and you call `.update` or `.set` like react setState. Want to separate your update logic from your component logic like in redux? Easy, just export functions to update the store instead of calling `.update` in your components.

Then, there's readable. Now, readable can be used like a reselect selector, but it's also far more powerful. You can subscribe to changes from a writable, or even other readable stores. You can create a readable that fetches your data. You can create a readable that subscribes to firestore collection or document. You can make a readable that combines data from multiple sources. It's all clear and composable. And I didn't have to write an action creator with an action constant called `LOADING_PRODUCTS`, and one called `LOADED_PRODUCTS`, and then one called `UPDATED_PRODUCTS`, and for good measure we should also create an action "PRODUCTS_REQUEST_FAILED" that we'll emit from the epic.

In these stores, cashiers are waiting around most of the time. That's the issue. They couldn't stay in business because they had to pay for the cashier to checkout as well as wait around. By letting customers checkout, there's no more wasted money spent on employees waiting around.

Also, the stores that are most promising don't require checkout at all, so that's an entire category of human effort eliminated, for better or worse.

I do agree text wins when it comes to expressiveness. However, that expressiveness comes at a cost, just look how difficult it is for beginners to grasp the initial concepts of programming.

I've seen some people pick up this medium very quickly, and others struggle for months with little progress. However, almost anyone can pickup Sketch or Illustrator for creating UI prototypes very quickly.

The expressiveness of text is not always a strength. It's very hard to build programming languages without text, but I strongly believe we still program too much when building UIs. Excel demonstrates that people can quickly pickup a minimal programming language for connecting data to UI, I think an Excel-Sketch hybrid is where the future lies for building applications in particular.

GitHub search is not very smart, but I prefer that when searching code. When searching code, I'm usually trying to find exact tokens i.e. a variable name or an error message string vs. searching documents.

I find it useful all the time.

"There wasn't a liquidity problem"

No matter the real explanation, here's the reality. Some firms continued to allow trading of GME, and a few firms including Robinhood did not.

I don't think it's clear that Robinhood did anything illegal, but it seems clear from their lack of transparency and Enterprise BS tactics that they aren't going to lay out a clear reason as to why they halted longs and other firms did not. Probably because it paints Robinhood in a bad light.

All this does is continue to expose Robinhood for what it is: A budget brokerage firm with a shitty product. Avoid if you want to maximize your profits.

I understand your point here, but I think we're a couple of innovations away from dramatically reducing the cost of UI development.

The state of the art for web and mobile app development is a delicate stack of tools that require a lot of expertise to wield. However, if you pay attention, most the complexity of modern UI development is accidental, not fundamental.

Figma already has "auto-layout", which is essentially flexbox. Imagine a world where your designer just builds your whole app with in Figma with flexbox-like constraints, then they hand off to your developer who just writes a couple of snippets code to wire it up to a database and makes sure the elements are configured to be SEO friendly.

IMO developers dramatically underestimate the power of GUI tools to usurp their role because we think in terms of such low level tools.

+1, It's very rare I run into people on the internet that seem to understand this. We're all obsessed with getting our delicate stacks of tools to work together that we fail to realize we're building at entirely the wrong abstraction level.

The solution to slow SPAs is higher level frameworks and tools that compile away the slow runtime. Svelte is a step in the right direction. We have many more to go.

Honestly, I believe the role SPA front-end developer is overvalued at the moment, not because the job is easy, but because the tools are so poor. Once we see platforms that properly balance ease of use with expressiveness and composability, I believe there will be huge opportunity for development agencies to undercut the market.

The answer is simple: Traits

The weakness of OOP structurally stems almost entirely from inheritance, which I think is very poor construct for most complex programs.

How should the widget situation be handled? Well, what is a widget? It's hard to define, because it's a poor abstraction.

Maybe all your "widgets" should be hide-able, so you implement a `.hide()` and `.show()` method on `Widget`. Oh, and all your widgets are clickable, so let's implement a `.click()` method.

Oh wait.. but this widget `some-unclickable-overlay` is not clickable, so let's build a `ClickableWidget` and `ClickableWidget` will extend `Widget`. Boom, you're already on your way to `AbstractBeanFactory`.

We got inheritance because it's an easy concept to sell. However, what if we talked about code re-use in terms of traits instead of fixed hierarchies?

So, our `some-unclickable-overlay` implements Hideable. Button implements Hideable, Clickable. We have common combination of these traits we'd like to bundle together into a default implementation? Great, create super trait which "inherits" from multiple traits.

Rust uses such a system. They don't have classes at all. Once you use a trait system, the whole OOP discussion becomes very obvious IMO.

1. Shared state can be bad, avoid if possible

2. Inheritance is a poor construct, use traits, interfaces, and composition instead.

3. Don't obsess about DRY and build poor abstractions. A poor abstraction is often more costly than some duplicated code.

4. Use classes if they're the best tool in your environment to bundle up some context together and pass it around, otherwise don't

Yeah, I think there's a tremendous amount of use cases for Materialize for companies that already have data store infra and want real time analytics or such use cases.

However, I also think differential dataflow solves a big problem for smaller companies building out their MVP or in early-stages. Firebase is popular because it's easy to set up, and it's realtime functionality on the client side mean you don't need to write a client-side data management layer, you can just use firebase's realtime functionality.

The issue is that firebase is completely untyped, isn't relational, and has limited queries. So you end up writing gnarly non-transactional code that makes many round-trip requests to query basic stuff.

I think there may be an opportunity product that combines the performance of and client-side tools of firestore, the ease of use of airtable and the real-time query and materialized view functionality of materialize into a database platform for businesses that want to scale their product.

Big ask obviously, but I know that a product like that would help me launch products much faster, I'd pay a lot for it.

I think the killer app for differential dataflow would be an easy to set up realtime database like Firebase, but with much richer real-time queries and materialized views.

Materialize (built on differential dataflow) is cool but doesn't have the complete package of a persisted database.