Hi,
Framework agnostic is clearly the way to go for ionic 4! We were very pleased to see your recent post The end of framework churn … this sums up our feelings precisely, and we’re glad to see that you guys also “get it”.
One great piece of potential that could be unlocked for us here is the possibility of layout/wireframe re-use between tablet form-factor cordova/SPA/PWA context and non-SPA public-web desktop browser context, where bookmarkable crawlable SEO-optimal rapidly-indexed content is absolutely paramount for us!
To unlock this potential we would really need some kind of capability for stencil to produce for our devs a pure-HTML version of the markup with the ionic web components completely compiled-out to inline pure (non-custom) HTML with all shadow DOM hoisted to light DOM etc… a-la polymer “vulcanize” or some kind of full SSR/Universal render capability that we can run in node then save to disc and pass around.
Are there plans to include such a “full build-out/inlining” functionality for ionic-core + stencil?
In case you’re unconvinced and thinking “why do you need that, you only think you need that but actually you’ve got an X Y problem, you don’t really need that; your real solution should be addressed elsewhere”, let me explain why such a capability would be very important and useful to us.
So why do we need vulcanize/full build-out to share code between tablet form factor and public web?
TLDR:
Plain SPA SEO story does not meet our needs, Full stack SSR/Universal is not an option for us, so to unlock this re-use we need a capability to build out tablet form-factor wireframes to “pure” HTML so that we can take that, and then sprinkle server-side ASP+razor/Django+blade templating directives in there, (instead of Angular/Vue/Whatever ones).
Full Explanation:
To clarify, when I mentioned SEO, we really care about crawlers such as Baidu, Facebook, and Twitter - we produce shareable snippets for social media that should be well promoted in business customers’ followers’ news feeds for example, and handle travel bookings from Asia, so: “don’t worry, route all requests server-side to your SPA and pass in an initial route parameter, avoid hashbang urls, add appropriate hand-rolled shims for location bar and back button compatibility, (gee thanks for the help mr. framework!) and check with google fetch: the crawlers that ‘matter’ will reach you… …eventually” is simply not a valid answer for us. Time-to-indexing, suggestion/summary links, it all matters to us!
We’re very happy with tried and tested toolchains like ASP.NET Core/razor and Django/blade etc for serving out fast loading, server-side injected “classic public-web bookmarkable/indexable content” and are extremely reluctant to adopt full-stack server-side javascript node.js + angular (or framework de jour) Universal/SSR “solutions” that involve going to some frankly creepy variant of a “headless pre-rendering browser inside node” style setup. All just as a workaround for the limitations of the crippled SEO capabilities of plain SPA, and so as to get us back from negative to zero.
To briefly justify this reticence in case full-stack evangelists are not convinced:
-
From a design perspective it’s bad separation of concerns, unnecessary complexity, and those experienced with local/remote isomorphism metaphors, (think back to COM+, CORBA etc) know such abstractions to be inherently leaky no matter how “cool” it sounds. It makes routing and content injection hard to reason about, where a more practical workflow would be to simply take our wireframes and sprinkle them with Angular/Whatever templating directives for cordova/SPA/PWA context and razor/blade directives for server-side public web context. (With server-side razor/blade tag helpers we can potentially even have a mode where razor/blade removes itself and injects angular/whatever directives when a flag is set, making the workflow full code-reuse with a “sprinkle-once/maintain-once” workflow pass).
-
From a practical/ops perspective, the idea of being vulnerable to running potentially CPU intensive DOM-render edge cases (e.g. a rarely hit page gets requested with atypical params and results in rendering an unreasonably large list where the backend devs forgot to limit the number of returned results) and having the whole single-threaded single-cpu node event loop grind a to halt while this goes on is toublesome to say the least! A single threaded non-blocking async event loop is great when you’re I/O bound. If you go CPU bound, not so much, as CPU is by definition blocking on a single thread. so in reality you want a farm of node processes with a round-robin proxy and monitoring etc etc, but don’t worry, for that there are… FRRRRAMEWORKS (oh joy!). Would you care to npm install -g forever and upstart and caretaker and snozberry and God knows what else?
No.
No we wouldn’t.
All we wanted was to use good mobile-friendly widgets in our UI content, with a bit of lightweight templating, and to send the odd button click to JSON instead of GET/POST.
Now aggressive opinionated rapidly-depracating frameworks are telling us “yes you can, but you must embrace the foo-bar.js TM way, and replace your entire sever-side stack with our preferred one”.
We’re sick to death of rapid deprecation, (we’ve been burned a number of times already just in the cordova space), framework churn and decision fatigue; we’d rather just keep maintaining an extra independent set of wireframes for public-web indexable content (bootstrap + a bit of jQuery) and give up on re-use than tie ourselves further to all that.
We want good well-encapsulated libraries and tools, not opinionated frameworks that want to encroach on our whole stack…
…but we’re crossing our fingers and hoping that stencil+ionic core will be “fully vulcanizable” and therefore also non-js server side templateable, and allow us to share great full-SEO capable layout with industry best widgets between all our tablet/desktop style form-factor contexts ![:wink:]( ":wink:")
Sorry for the length of post, but the full background to the use-case considerations is both interesting and complex. Good luck with Ionic 4!
Did I mention we hate javascript? ![:smiley:]( ":smiley:")
Yours, Liam
“Save us WebAssembly!” they cry out in vain, cold and alone, adrift in the eternal darkness of the ancient void, waiting for their np̀m̢ dependencies to resolve… B̢̬̣͉̫̱Ṳ̱̩̜͎͉̩T̮̠̼̺̪͓͠ ̖̜̻̦͢H̳͓̱͎̳͎E̘̯L̳̼̤̤P̧̰̪̤̠̥̠͍ ̛̯D͎̘̩͇͎O͈̺̮͍͙̙E͍͇̟̼S̝̲ ̢̮̩͇̟N̮̭̰̬̟̕O̪̙͙̗̼̝̮͜T̲̮̯͇͢ ͖͢C̗̥O̡͔͎͓̳͇M̖̗̻E͈̣̲̥̱!
Z̪̤͔̫̯͔̼̯͡͞͠A̷̛̛͚͍̭͓͙̥͕͕̭͎̘̼̹͉͉̼̫͖̺L̷͠҉̣͖̙̖̼̣̘̥̝̙̖͟ͅG̻͈͉̲̤̻̫̖̭̭̺͚͚̣̱̗͘͘͜Ó̷̗̜̗̣̤̭̲̳̺̥͍̩͇͍͓́
