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

51–56 of 56 posts

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

#51

Post by thebigfatpanda2 »

karthikksv wrote: post #43
weego wrote: post #33

So now we're stuffing sql in our react as well as html and CSS? React is on course to reinvent the PHP that everyone spent so long laughing about

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-…

> 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.

Sorry, but any sane codebase usually abstracts away HTTP info like routes through services which means that your components only know about the dataService and don't care if the data is coming from a REST API or localStorage

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

#52

Post by root_axis »

karthikksv wrote: post #48
root_axis wrote: post #45

> What if your React components ran on the server-side? Huh? React components can run on the server side, that is one of the primary benefits of React compared to its predecessors.

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.

Ah! I see what you mean. It reminds me of https://github.com/airbnb/hypernova

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

#54

Post by basch »

karthikksv wrote: post #29
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…

Is this a pretty similar idea to https://derbyjs.com/ ?

https://github.com/share/sharedb

https://github.com/derbyjs/derby

https://github.com/derbyjs/racer

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

#55

Post by tdhz77 »

karthikksv wrote: post #43
weego wrote: post #33

So now we're stuffing sql in our react as well as html and CSS? React is on course to reinvent the PHP that everyone spent so long laughing about

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-…

This is how cold fusion works, written by Adobe for too steep of a price. I wonder if we are just running circles around the same ideas. Are we really moving the ball with Purview? I’m lost.

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

#56

Post by [deleted] »

Scooty wrote: post #30

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'r…

[deleted]
Post reply on HN