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 at least some kind of full SSR/Universal render capability (including shadow-to-light DOM hoisting via forced polyfill if necessary), that we can run in node, then save to disc and pass around.
(We’ve considered doing something similar to the second option in Ionic 3.x, basically to extract fully rendered sample HTML source to work on, from a test client, after page load via document.outerHTML - should work, but it’s not top prio right now, and the coming reliance on shadow DOM with web components could make this approach moot in any case, depending on the availability of additional polyfills.)
Are there plans to include such a “full build-out/inlining” functionality for ionic-core + stencil?
What level of support will there be for non-shadow capable browsers via polyfills etc, will it be similar to polymer (IE11 + evergreens)?
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?
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” non-componented 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).
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 and rapidly promoted in business customers’ followers’ news feeds for example, and we 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!
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 UI 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 accidentally 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 to a 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 express and forever and upstart and caretaker and snozberry and God knows what else?
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, then turn it into abandonware…
…but we’re crossing our fingers and hoping that stencil+ionic core will be “fully vulcanizable” and therefore also non-js server-side renderable/templateable and non-js crawlabe, and allow us to share great full-SEO capable layout with industry best widgets between all our tablet/desktop style form-factor contexts
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!
“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͈̣̲̥̱!