Show HN: Purview – A server-side component framework (opens in new tab)

Yes, that was my inspiration! Chris gave a great talk about it at ElixirConf is anyone is interested in watching: https://www.youtube.com/watch?v=Z2DU0qLfPIY

Some differences compared to LiveView:

- Type-checking: there are extensive JSX typings (https://github.com/karthikv/purview/blob/master/src/types/js...) that ensure you're attaching event handlers with the correct signatures, specifying supported props, using valid HTML tags and attributes, etc. Static-typing guarantees are one of my big priorities.

- I'm not sure if LiveView intends to support nested components like React does. Having the ability to split up complex pages into components that you can nest and reuse (with mostly one-way data flow) is a key part of maintainability. I wanted to maintain a very familiar React interface, so you can pick up Purview quickly if you're comfortable with React.

I was thinking the same. I expect elixer/phoenix to easily outperform js/node. I believe with phoenix it actually makes sense what they are going, which I can't really say from this "thing".

This looks awesome, thanks for sharing! :)

A common criticism I heard about React a few years back was combining JS and HTML within the same file, as opposed to having them separate. As with most decisions, I think separation is an important trade-off you need to consider: it's easier to reason about the individual, separated parts that are well-contained, but it becomes harder to reason about the system as the whole.

If you have a complex front-end and back-end with a REST API, each time you modify a server route, you need to find all instances in your client where you make an AJAX request to that route and change them appropriately. The potential for inconsistency can cause numerous bugs.

GraphQL solves this by having a very flexible and standardized server (albeit complex), giving your client access to arbitrary structured information using a query language.

Purview solves this by moving your logic to the server-side, where you can access your database directly. Because everything runs on the server, the client-server interface is abstracted away, and you don't need to worry about using GraphQL or REST. You can make database queries, contact external services, etc. directly within your components.

To keep this maintainable, you split up your page into logical, reusable components, just like you would with React, and each component now not only contains your view logic, but also the server-side logic. Given that you've decomposed your components well, this makes it easy to reason about the whole system when it comes to any part of your page.

Personally I took a break from frontend work, I'll circle back in a few years once web assembly is ready.

The JS ecosystem is insane once you take a step back and look at it.

True, but you could move it into a model class, maybe use mobx or another state library

I know this comment is a joke, but this is actually how react was created. Facebook made a templating language in php called xhp (https://docs.hhvm.com/hack/XHP/introduction) and some people at fb developed react as a natural extension to xhp but in JavaScript.

Perhaps I could've explained myself better. I meant that all the business logic of the components (i.e. event handlers, lifecycle hooks, setState() calls, etc.) run on the server, unlike just the initial server-side rendering that React provides. The server maintains the state of all components, and when an event occurs, the client notifies the server to run the appropriate event handler.

You're not required to use TypeScript. As janpot mentioned, the library is transpiled prior to being published on npm, so you can use it with regular JavaScript. This is true of most TypeScript libraries.

Not to me, if it's distributed on npm in its transpiled form it doesn't matter.

Why's that garbage? Sometimes a full SPA is not needed.

> Maybe we could later exchange X with something that only sends bitmaps?

Can we call the followup Wayland because that is the only way to go :)

We've been using this in production at the company I work at for about the past ~1.5 months. We've gone through a fair number of fixes and improvements throughout that time (bugs, race conditions, performance, etc.). It's definitely still a nascent project, but we're excited to continue using Purview and developing it. Would love to get your thoughts if you try it out sometime.

Higher latency connections will certainly have longer delays, but it's quite fast on a reasonable connection thanks to the persistent WebSocket, even if you're sending each letter that's being typed. We're using Purview in production at the company I work at, and we haven't had issues with input-related delays.

If you don't need to send each letter, it's recommended to not do so; the submit event object includes all form data, so you can do one final validation at the end, similar to what you'd do with a normal web server.

You're right, there's validation for the WebSocket messages sent to the server. For certain events (e.g. submit), the validation of user form data is left to you, just as you would normally be responsible for.

Whenever any information needs to be saved or processed by the server, you can perform your server-side logic inline in the event handler (e.g. update the database, contact external services, etc.). There's no need to make an AJAX request and have a corresponding API route. This abstracts away the client-server interface, and you get safety guarantees with type-checking.

All the business logic of the components (i.e. event handlers, lifecycle hooks, setState() calls, etc.) run on the server, unlike just the initial server-side rendering that Next.js provides. The server maintains the state of all components, and when an event occurs, the client notifies the server to run the appropriate event handler.

Because the DOM is not synchronously accessible, I guess.