Ditch the terminology "isomorphic"

[chinedufn]

@cryptoquick brought up some good points in #28 (comment) that this is a source of confusion.

Let's ditch this terminology in favor of something that more people will intuitively understand.

@cryptoquick mind dropping your thoughts in here and we can hash out some better phrasing?

[cryptoquick]

Sounds good! I'm definitely in favor of "Full Stack Rust Framework", but it's also notable to mention that "Serverside Rendering" and "Universal Applications" are more accepted term by the JS community. Further, there's some overlap in PWA territory, but there are different expectations there, and although this would fold into that, there's a couple additional hoops and validations to jump through to promise a PWA app. Definitely something to work towards, though.

Also, I would note, although the majority of my app, client, and server code is in Rust, I've got several shell scripts that keep me from having a fully-Rust project-- as evidenced by the green and, of course, HTML red in this image:

Still, a very impressive metric for a full stack application, to say in the very least.

If there isn't a way of running scripts akin to NPM scripts in Rust or Cargo, then that green will remain.

Also, I should note, the HTML can easily be removed by incorporating in a Rust file with a multiline string, formatting it with simple named arguments provided to that template fn.

[dbrgn]

Isomorphic sounds cool but might scare off some people.

I'd also suggest to use terminology like "xxx with serverside rendering support", or something like that.

[qm3ster]

I think the word "portable" has to come in then.
Rendering isn't all there is, the big advantage of rendering in Rust to begin with is that you can bring your Rust business logic clientside.
I don't think "isomorphic" is a dirty word, it's better to just add other words too if there are concerns.
The frontend is JS-dominated and there it has a particular meaning.
(And that meaning is cool, hype synonym for portable between server and client)

[chinedufn]

haha @dbrgn I clicked into here thinking the exact same thing!

---

I think that the main considerations are

1. We want to be very approachable to people that have little or no web development experience. A major goal of Percy is to appeal to devs who have traditionally avoided web development because they didn't have (or sometimes want) JS experience

2. We want to be quickly understandable to people that have lots of web development experience.

One thing that people can get tripped up by is thinking that client/server or full stack means we're trying to support API development (i.e. that we're providing some of the things what Rocket / active-web provide), not just front-end web applications.

So ... one option that comes to mind for me:

Interactive frontend browser apps with server side rendering support

It's long, but I think that it doesn't have much room for confusion.

What do y'all think? How can that be improved / changed? Is it clear / unclear?

[cryptoquick]

Perhaps my goals for this project are more ambitious than that, but I just finished a proof of concept for a set of fetch functions for a warp API (instead of actix). I've got it working in my own full-stack Rust app, and I'm eager to pull some of my code out into something that might benefit the community. I suppose that's one why I'm interested in calling it "Full Stack Rust." I'm working on getting a RethinkDB database running on Compose working with it now.

[qm3ster]

@cryptoquick Imo "serverside fetch" can never be more than a performance optimization, because the developer of the "portable" code needs to be forced to consider the fallibility and asynchronicity of the fetch.

@chinedufn I agree that API integration shouldn't be a primary goal. There should be trivial-to-follow and up-to-date recipes on developing an API and a Percy webapp in one repo/run them together in dev/etc.
But beyond that, actually short circuiting inside the process doesn't get us anything good.
Exposing a non-network API to the API(lol) is added complexity, and the resulting system is harder to scale.
In real usage in the world we live in, most fetches will be from remote clients over the open Internet.
Which means if the API requests of the frontend server are your bottleneck, the remote clients are probably plain dying out there on the frontlines. Maybe reconsider what data you're fetching :D

[dbrgn]

Interactive frontend browser apps with server side rendering support

I think that sounds great! To me (a mainly developer mainly focussed on backend that has quite some JS/web experience but tries to avoid the JS framework hype) it would explain what Percy is.

[chinedufn]

@cryptoquick totally! I just mean that we won't be building building an HTTP framework. So - we want to make full stack Rust easy - but our place in that puzzle is

1. Focus on the browser rendering / server side rendering
2. As @qm3ster says, we'll most definitely want to provide examples of using Percy with things like Rocket / actix / etc to build production grade applications.

---

@dbrgn awesome - let's start with that for now!