<FromGitter>
<jwoertink> What exactly does "server rendered vue" mean? Isn't it crystal that's rendering on the server side?
<FromGitter>
<fridgerator> the vue templates are rendered on the server, rather than on the browser
<FromGitter>
<fridgerator> he's starting node processes to render them and returning them using a crystal server (amber)
<FromGitter>
<fridgerator> nice work btw @noahlh , I like it
Raimondi has joined #crystal-lang
<FromGitter>
<jwoertink> ah. What sort of benefits do you get from doing it that way? Maybe SEO? Or is it more performant?
<FromGitter>
<silmanduin66> hello
<FromGitter>
<fridgerator> yeah, both of those things
<FromGitter>
<fridgerator> I dont know a ton about it, but server side rendering react or vue seems to give you the benefit of both works (server render + javascript templates)
<FromGitter>
<fridgerator> with an added complexity of rendering on the server
laaron has quit [Remote host closed the connection]
<FromGitter>
<noahlh> @kevinelliott thank you! it's been a fun project to work on (and will be fun to continue working on since i'm using it myself for another project lol)
<FromGitter>
<aemadrid> @noahlh very interesting. I’ll keep an eye on how things go here.
<FromGitter>
<noahlh> @jwoertink there's a bunch of benefits that i see (and maybe some that i don't): SEO for sure, since you're sending down fully-rendered pages vs. a shell + javascript bundle that gets rendered on the client; initial load time, since for the same reason - browser loads pure HTML + CSS, and then the JS framework "attaches" (aka hydrates) once the page loads, so it's zippy on the client.
<FromGitter>
<jwoertink> oh ok. That's pretty cool.
<FromGitter>
<noahlh> biggest benefit to me though is that your view code is consolidated and in ONE place - instead of an ECR template that renders part of the HTML and then client-side Vue components that load the rest, you're writing your views once and getting them both server + client rendered
<FromGitter>
<jwoertink> Yeah, I definitely prefer having all the html done on the server side
<FromGitter>
<jwoertink> So that's a nice bonus.
<FromGitter>
<noahlh> totally. i'm old school about this and that's table stakes in any web app i build. the kids these days and their fancy SPAs ;) ;)
<FromGitter>
<kevinelliott> @noahlh I might actually consider rewriting my home dashboard product (Rails+Vue app on display art hardware) to this.
<FromGitter>
<noahlh> <html><script src=bundle.js></script><html> is what 90% of new SPAs send down from the server. that feels wrong to me
<FromGitter>
<noahlh> (i'm being somewhat facetious though - i know there's a time & place for that and it has benefits)
<FromGitter>
<noahlh> @kevinelliott awesome. it'd be a good way to experiment with crystal for sure. long-term goal of this is to port it to rails too (but need to get things in order / more developed / cleaner first)
spacemanspam has joined #crystal-lang
<FromGitter>
<j8r> Is it render for each request by the server like PHP? It's better to do that once, and hydrate the page with a json from an API call
spacemanspam has quit [Read error: Connection reset by peer]
<FromGitter>
<noahlh> @j8r by default (in current version) each request triggers a full render server-side followed by client-side hydration on load. it's def possible to have subsequent requests only handled by JSON from API calls -- you'd basically use <router-link>s (or a custom behavior) to have your client components make those calls to API-specific URLs
<FromGitter>
<noahlh> and by "each request" i mean basically if a request hits the server URL which triggers a `vue_render()` call in the controller. That's up to you. If you have requests go to URLs that have other behavior on the server then you can act accordingly (i.e. return JSON, etc.)
<FromGitter>
<Blacksmoke16> hows the implementation into frameworks work? just have to call `vue_render()` which returns a string which should get set as the response body? or is there more to it?
<FromGitter>
<noahlh> nope that's it
<FromGitter>
<noahlh> right now (first ver) vue_render() is a macro which does some Amber-specific stuff
<FromGitter>
<noahlh> but it's like 3 lines so very easy to adapt to, say...athena ;)
<FromGitter>
<Blacksmoke16> cool, yea athena already supports that so would be pretty easy
<FromGitter>
<Blacksmoke16> any string returned from an action is just dumped straight into the response body, so should be 👌
<FromGitter>
<noahlh> i think `request.resource` is the only amber-specific thing there (and the fact that it assumes you're doing an `include` in Amber's `ApplicationController`)
<FromGitter>
<noahlh> and i'm not even sure `request.resource` is technically Amber-specific?
<FromGitter>
<girng> "server renderer" for client side js LOL wat
<FromGitter>
<fridgerator> its a thing, a lot of companies use
<FromGitter>
<girng> lol they say better time-to-content. so they think connecting to a server and getting the html strings back is faster than running js on the client. yikes. 😆 ⏎ ⏎ > Faster time-to-content, *especially on slow internet* or slow devices. ⏎ baawhwhhaha [https://gitter.im/crystal-lang/crystal?at=5c3f9a211cb70a372aed0aa5]
<FromGitter>
<Blacksmoke16> well it would be, the first response would be the view with data already in it
<FromGitter>
<Blacksmoke16> vs having to make additional front end requests for data
<FromGitter>
<noahlh> ^^^ 👍
<FromGitter>
<girng> server side js will never be faster than client side js unless the task is something that supersedes the client's cpu power and the server is far faster
<FromGitter>
<girng> then, adding in the round trip time from the server->client as a factor as well
<FromGitter>
<greenbigfrog> why does ECR like `<%= "first line\nsecond line" %> not work? (Now that I typed this example, I think realized it's due to it generating html, so `<br>`
<FromGitter>
<noahlh> @girng just to clarify - we're talking about that first page load. so you visit a site, request a URL - you have a round-trip regardless. On a pure SPA, you get back basically <html><script src=build.js></script></html> so you're getting back SOME html anyway, then the client loads the javascript and builds the DOM client-side + additional round-trips to fill the DOM with data (typically via JSON APIs). That
<FromGitter>
... takes time and clients often show a loading screen which IMHO is bad UX.
spacemanspam has joined #crystal-lang
<FromGitter>
<noahlh> vs on that first request, having the server do a server-side render, send back a fully-formed HTML page + css + js package which gets rendered very quickly on the client. THEN the client loads the JS and subsequent requests (maybe) are loaded via json api. best of both worlds - fast initial page render + client-side JS.
<FromGitter>
<sam0x17> and if the server side CPU's power supersedes the client's CPU power you probably don't have a sustainable business model in terms of AWS bills
<FromGitter>
<sam0x17> (and assuming you rely on that heavily)
<FromGitter>
<girng> @noahlh that's a problem vue.js created themselves and then added a solution for lol. that's why it's so funny. ⏎ ⏎ > having the server do a server-side render, send back a fully-formed HTML page + css + js ⏎ ⏎ this is normal and how php has been doing it for years and what i do. it's also the fastest i agree. [https://gitter.im/crystal-lang/crystal?at=5c3fa0a30721b912a58f45e1]
<FromGitter>
<noahlh> yup i hear ya. React & Vue (and Angular? And I guess any client-side component-based framework?) all have this "problem" - but these frameworks do have major benefits - it's incredibly easy to build incredibly powerful reactive UIs. so i guess :shrug: ?
<FromGitter>
<noahlh> @fridgerator lol ;)
spacemanspam has quit [Read error: Connection reset by peer]
<FromGitter>
<girng> @noahlh it's all over hyped stuff IMO. "powerful and reactive UI's" can be done with vanilla js, css and html knowledge, no developer needs some special js framework. just adds more complexity. this is just my opinion. ⏎ ⏎ and analogy is: it's like telling a developer to use ANSI C to create a tcp gameserver with a tickrate that connects and uses a remote mysql db, when it can be done with crystal's
<FromGitter>
... TCPServer in a few lines of code. ANSI C option is the vue.js developer, crystal option is the vanilla JS way. it's so much more simpler
<FromGitter>
<noahlh> i hear ya! we're getting into religious-level topics & opinions though so i shall tread lightly lol
<FromGitter>
<girng> i don't flame no worries
<FromGitter>
<girng> i just wanted to voice my opinion about vue, thx for reading =]
<FromGitter>
<noahlh> haha cool cool 👍
<FromGitter>
<Blacksmoke16> no developer needs a framework, it just saves time by not having to do everything in plain js themselves
devil_tux has joined #crystal-lang
<FromGitter>
<fridgerator> why use crystal, you can do everything in assembly
<FromGitter>
<girng> js is a framework in of itself though. js frameworks make js more confusing than it already is because now the developer needs to learn a new API, etc. IMO the developer loses more time
<FromGitter>
<Blacksmoke16> how is that diff than you using amber vs making everything yourself
<FromGitter>
<Blacksmoke16> its the same idea just a diff lang :P
<FromGitter>
<Blacksmoke16> why use rails if you can just do it in ruby
<FromGitter>
<girng> well, imo, it's because people don't realize how simple js is already and how easy it is to modify the dom. sure, helper libraries and functions can be useful, but a total "js framework" that has its own way of modifying the dom (mostly slower than vanilla JS) is going way too far and just complicates everything
<FromGitter>
<proyb6> Nodejs works because they are one language and need security scanner like synk. I haven’t convince myself enough to use React or Angular. But Vue and Crystal seems a nice combination for websites like CMS
<FromGitter>
<noahlh> @proyb6 yup exactly - my first crystal project was going to be a new personal portfolio site / blog and i stated building it in amber and wanted better Vue integration and well that lead to a month-long sidetrack lol
<FromGitter>
<proyb6> Cool idea unless you plan to market it in the future, make it cool and secure. Meteorjs is growing but I didn’t have a visibility how their stuff works which is overly complex although I have been following their early development, with their addition React, Angular and Vue is much easier for startups to hire devs