Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Purview – A server-side component framework

github.com

Post reply on HN
Print view View original

21–30 of 56 posts

Re: Show HN: Purview – A server-side component framework

#21

Post by karthikksv »

mplewis wrote: post #14

In React, forms are often built with this pattern: * Type/change events fire on the field (e.g. username) * Username updates the internal model (this.username = 'karthikksv') * The submit button fires an event so the parent page can act on the entire data model ({ username: 'karthikksv', password: 'fluffykittens' }) I'm concerned that this model won't work well using server-side React components on a network with hig…

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.

Re: Show HN: Purview – A server-side component framework

#22

Post by karthikksv »

rienbdj wrote: post #12

normally security would be implemented at an api level. you would have to be careful to implement that in the renderer here.

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.

Re: Show HN: Purview – A server-side component framework

#23

Post by vlucas »

It's a JS framework that targets server-side (node.js), and is written in a language that is not natively supported - TypeScript, thus requiring transpilation right out the box to use. Does that seem odd to anyone else?

On the update: This does seem kinda neat, and certainly useful in some situations.

Re: Show HN: Purview – A server-side component framework

#24

Post by janpot »

vlucas wrote: post #23

It's a JS framework that targets server-side (node.js), and is written in a language that is not natively supported - TypeScript, thus requiring transpilation right out the box to use. Does that seem odd to anyone else? On the update: This does seem kinda neat, and certainly useful in some situations.

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

Re: Show HN: Purview – A server-side component framework

#25

Post by karthikksv »

kgwxd wrote: post #18

I'm sure there's a use case for this but, for me, it's pretty rare to need pull new data or persist anything after most events, let alone every event. A single fetch and single save is usually all that's needed.

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.

Re: Show HN: Purview – A server-side component framework

#26

Post by martell »

choeger wrote: post #15

Wait, why could we not render the HTML on the server and only let the browser to the compositing? If there only was a protocol that would allow us to exchange input events and some drawing commands over some arbitrary network.. let's phantasize for a moment and call that protocol X. I would use it when it's mature so maybe from X11 on onwards. Naturally, sending draw commands has a big downside in efficiency. Maybe w…

> 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 :)

Re: Show HN: Purview – A server-side component framework

#27

Post by karthikksv »

vlucas wrote: post #23

It's a JS framework that targets server-side (node.js), and is written in a language that is not natively supported - TypeScript, thus requiring transpilation right out the box to use. Does that seem odd to anyone else? On the update: This does seem kinda neat, and certainly useful in some situations.

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.

Re: Show HN: Purview – A server-side component framework

#29

Post by karthikksv »

janpot wrote: post #4

looks like it's the react version of https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera... ? edit: nvm, it's listed in the readme as inspiration

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.

Re: Show HN: Purview – A server-side component framework

#30

Post by Scooty »

I've been playing around with a similar idea using nextjs. My idea was to create some kind of RPC interface with typescript that works seamlessly between server/client rendering, so during server rendering, RPC calls would just be regular function calls, and during client rendering/event handling, the calls would be made through sockets or HTTP requests.

There's a lot of criticism in this thread. I'm curious if you're using this in production. I love projects like this that really push the bounds of how these problems are typically solved.

Post reply on HN