Isomorphic / Universal #72
Comments
|
I can only tell you that it probably won't happen in the next few months as part of our initial release. But, it's something we want to investigate for the future. |
|
👍 for Isomorphic. "Truly modern UI" isn't an excuse for not providing an initial page render from the server. Perf, SEO strategy, progressive enhancement, and greater accessibility aren't things we can just throw away for "modern UIs". This looks super interesting, but if it can't be used in an isomorphic way I'm afraid it's not going to cut it for many people for a modern framework. IMO Isomorphic is the last truly hard problem to solve in client side frameworks. |
|
-1 for isomorphic if it is a requirement for use. Seriously let us focus on getting a stable, documented initial release out to the community, and build awareness and momentum behind Rob and the team. Maybe expand the framework to have an optional component that allows a full isomorphic implementation later, for those that want that pattern of usage, but do not allow this to affect the clean way that the core has been constructed so far. Isomorphic only suits some scenarios well, so don't limit its audience from the get go before people even hear about it. Not every project is a green-field startup in SF. I work a lot with clients that have a web interface as one of several for their applications, which will include native IOS and Androd apps, and they want a single code base for this which works with their existing investment. If I was to present an isomorphic-only Aurelia as a solution, that meant a new architecture, and changing and then resubmitting their apps to Apple, they would think I was crazy and just continue to use Angular for their web interface. |
|
@mcquiggd Not having a server rendering strategy renders getting those things hacky at best. I'm not suggesting the need to go full-on Meteor with full Database bindings, I'm saying that there needs to be a way to render on the server and pick up again in browser. Pure client-side rendering doesn't allow for those things, and pre-rendering in phantom.js is a hack and a half (which is the generally accepted solution now) |
|
It's funny how, when people say respectfully, they rarely mean it. I digress. What you're missing there is shared views and controllers, meaning that that business logic and templating is duplicated twice; IMO a maintenance burden and a big one at that. But, if it works for you, that's great. I'm neither suggesting you get rid of the way you're working nor suggesting that isomorphic is the only way that this should framework should function. What I'm suggesting is that it needs to be able to be rendered server side if one chooses as not everyone is willing to take on the maintenance overhead of maintaining two separate systems doing identical things in different languages in order to serve a single page. |
|
@mcquiggd T4 templates to synchronize my client side logic! Bro you are a genius! Thanks for the tip. |
|
And BTW I think that isomorphic approach is a short live thing, the web platform is evolving super fast lately and I am sticking with using the server for most data retrieval task and rendering some initial HTML. If you need to render your SPA face for SEO there are good solutions out there AND I think that some search engines crawler are already doing that for you indeed, that to me is a natural evolution. |
|
@mcquiggd again, thanks for sharing such knowledge, I'm a hard core .NET developer and I get your point. I was using T4 templates to accomplish other tasks in the way you have explained but honestly I didn't thought about using it to generate static client side resources, this approach have open up my mind to accomplish some things that I have in the works. Thank you sir. |
|
Hi, I don't have too much spare time available right now but I can try. In other order of ideas I was exploring the internals of material.angularjs.org in order to have a better idea of how much work would be required in order to make a port for aurelia, honestly I'm more interested on that :-) just to let you know. |
|
And sorry for my weird "English" |
|
@mcquiggd - I am doing the same T4 stuff right now at work. I might be interested in collaborating. Here is an example of a very simple seed to test out a few technologies: Using Angular 1.x is unfortunately a requirement for us right now (legacy, right?), but I'd love to make a similar (but even better) seed, using a few cooler technologies (like Aurelia, another view engine, maybe some fun mapping stuff with XSLT, some examples of how I currently combine server-side rendering with microdata, exposed as a slow data service to the SPA, etc). Having some better, more lightweight T4 templates in there would surely interest me, and I'd be willing to invest some time into it. |
IMHO - FULL ACK on the above. We're thinking about using Aurelia for our project and forcing the use of a certain backend to use Arelia - a backend, which we aren't using - would mean a total no-go for Aurelia for us. You'd also basically be locking out probably more than 95% of the rest of the web devs with this idea. You know, the ones who don't use NodeJS! If at all, being able to use Arelia as a back-end framework should be completely optional. Scott |
|
👍 on that @smolinari. The .NET-solution wasn't an official solution of course, and it's obviously not for everyone. Server side rendering for metadata would be a big plus for me (and also is much easier to implement than full page rendering). Imagine a content-creation/sharing app like Youtube without the ability to implement Open Graph, Twitter cards, applinks etc... This is common and I wouldn't want to use prerender.io or similar CPU-eaters for this. I think the biggest issue for full server side rendering is Aurelia's internal usage of a web component compatible format (for partials). The web component spec deals with view rendering logic (shadow dom) and is afaik agnostic to data. You can pass data to the component as a text node, child-elements or attributes, which is the way to go if you want to make them crawlable. Example from https://css-tricks.com/modular-future-web-components/: <img-slider>
<img src="images/sunset.jpg" alt="a dramatic sunset">
<img src="images/arch.jpg" alt="a rock arch">
<img src="images/grooves.jpg" alt="some neat grooves">
<img src="images/rock.jpg" alt="an interesting rock">
</img-slider>But you don't have to do this. Aurelia doesn't pass data this way (and also doesn't use shadow dom). Aurelia instead uses javascript (es6) classes as controllers/viewmodels and passes no data to the custom elements. Example from https://github.com/aurelia/app-contacts <contact-list></contact-list>If server side rendering is implemented, the custom elements would have to be pre-populated. A web component with data is like a function with an argument. Populating them with a pre-rendered view would be like passing the return value to a function. It wouldn't work, or at least violate the spec. This isn't the only way out of it of course, but I think any other solution would imply deviating further from the web component spec and probably stop using the term web components. Meteor also doesn't do server side rendering of pages unless you use a third party package. But they do it for metadata. PS: I'm not working for or with Aurelia and may have misrepresented the issue (unintentionally). |
|
My stuff can be easily rewritten in Roslyn, but I understand it can be painful for complex templates that are rewritten on the fly. Honestly, I don't like writing T4 templates, but they are just so damn useful that I do, losing them might be bad. |
|
+1 on this issue. Hopefully it'll land. |
|
I think that if we could run some parts of the framework server side, it could be pretty easy. These modules should be abstracted from the DOM and the browser. |
|
-1 for this. Overcomplicating the core for edge cases makes no sense. Just expose an API with Swagger and generate a JavaScript client. Many languages are better on the server. |
|
So, just to clarify, we would like to have isomorphic support. It probably won't make it into v1 though. However, we have a multi-phased plan to get there. There are a couple of use cases that are nice to have on the way to full isomorphism. For example, pure unit testing without needing karma, pre-compilation of views (as part of bundling), etc. Many developers don't realize how difficult it is to write a fully isomorphic app, even with a framework that supports it. Usually, it means you can't use any 3rd pary libraries. You have to write everything from scratch and it's very framework-specific code you have to write. It can be time consuming and very costly. We do understand there are some developers who need or want this so we would like to support it. But, we want to get our core runtime feature set in place first, and make sure that it's performance optimized and compliant with web standards first. |
|
Great to hear, @EisenbergEffect. Really looking forward to this – with full respect for the difficulty involved. |
|
Great to hear about that. I'm looking for isomorphic solution to deliver a simple view when JS is not enable, not to bring the nice UI experience that Aurelia will deliver tho |
|
-1 Concerned this will complicate what was a promising framework. Bad decision. |
|
We aren't doing it for v1, but are considering a plugin for a point release later. We won't do it if it ends up causing a complexity explosion, especially since isomorphic solutions are only a temporary workaround while we await native web components and associated browser technology. Also, very few developers actually need isomorphic solutions and most don't realize how complicated it is to achieve, even with a framework that fully supports it. We don't want to rush into it, so after v1 release we are going to carefully evaluate. But we think we can do it without complicating the core framework. |
|
Thank you. This is so good due to simplicity and efficiency and clean architecture. It should compete with mainstream like Angular (99%) not niche like Meteor (1%). |
|
Thank you for the encouragement. We are working hard and want Aurelia to be the best solution now and in the future. To do that, we have to be very strategic. It's important to know that once we hit v1, we've got plenty of other things we want to build :) So, it's an ongoing process for us. We do have to "lock down" a v1 some time though...since many companies use that as an indicator for when to adopt. |
|
Please don't spend too much (if any) time on making Aurelia Isomorphic. There are plenty of good server options for rendering the initial templates. Currently I use marko templates from e-bay ;) |
|
It could be nice for a blog post maybe with isomorphic third party view integrations before built-in isomorphic features completed. |
|
Why all the negativity? We're talking about a feature with clear benefits, which most major SPA-frameworks either have or are currently working on, to possibly be released in the future, and if it will be it'll be optional. Surely it's a poor reason to keep you (plural) up at night. |
|
With the owner and author of Aurelia clearly stating that Isomorphic is a difficult, and somewhat pointless enterprise, I have no idea why people continue to push for it like it is some sort of noble quest that must be accomplished for kudos, no matter how futile. If the proposition that many major SPA frameworks are already working on Isomorphic is true, well, then great! No need to advocate here, go and enjoy! :-) |
|
@EisenbergEffect any roadmap plan on when will the server rendering be integrated? |
|
We are working on it but don't have a timeline for that. It's difficult to make projections like that with most open source projects. If you want server rendering though, there's no reason you can't work on it and then bring your prototype to the table to assist us in building the official version. That's the beauty of open source. You don't have to wait for the "official" team to do anything. You can work on it and make it your contribution t the global community. |
|
@EisenbergEffect First thing, much thanks for bringing such beautiful framework as Aurelia! You rock! As I understood, official deadline or milestone are not set for this feature, aren't they? Any chance to have SSR in the nearest future? |
|
It's already working on a branch. We're just trying to repackage it now.
…On Mar 28, 2017 12:02 AM, "Dmytro Yurchenko" ***@***.***> wrote:
@EisenbergEffect <https://github.com/EisenbergEffect> First thing, much
thanks for bringing such beautiful framework as Aurelia! You rock!
As I understood, official deadline or milestone are not set for this
feature, aren't they? Any chance to have SSR in the nearest future?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#72 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAIBnY2aej-YG1uxiFIwZv5-S4YmkLsBks5rqLB3gaJpZM4D2GN_>
.
|
|
Any update on this availability? |
|
It should currently be available when using the Webpack skeleton. Improved SSR is a priority for the team currently. |
|
Is there any docs on it? Does it work with asp.net javascriptservices? |
|
There are no docs currently as it is still pre-release and subject to change (as far as I am aware). |
|
Thanks! Looking forward to it becoming more solidified and fully working with JavaScriptServices! |
|
any update on this? |
|
It's actually fully functioning. I think we just need to figure out what the best way to ship it is. @JeroenVinke Where are we on this? Do you need me to set up any repos or approve any other PRs that are blocking the core release? Let me know. Thanks! |
|
@EisenbergEffect this is where I got stuck: aurelia/binding#610 (comment) While it's nice if we could disable two way binding entirely, it would be enough to somehow disable the dirtychecker. |
|
Hi Aurelia team, Glad to hear this is almost ready. We've been considering porting to React or Angular to solve our load time issues. Moving over to Webpack gives us a big jump but we're afraid it won't be enough and so would like an SSR solution. Would like to start getting something going with the pre-release. @AshleyGrant @niieani Just want to confirm that this is what I should be working from? Last commit was in January. |
|
@davidpurkiss I would recommend to wait a little while longer, I wouldn't use the skeleton that you're referring to. After we get the two-way binding problem out of the way (see my earlier comment) we will create a skeleton that you can use. I should have some time to work on this in 2 weeks. |
|
@JeroenVinke Thanks! If there's anything I can do to help or move things along quicker, let me know. My knowledge of the core framework is not extensive but have been using it since beta. |
|
So, more than two years ago I asked for this server rendering feature. In these two years we have seen growing many alternatives, like React and his performant derivatives (Preact, Inferno), VueJS and even Angular now supports universal rendering. At that moment I was interested by Aurelia embracing ES6 new JavaScript standard and beeing modular. Now, all the mentioned frameworks (and even Meteor) can work in a modular way and embraces the new JavaScript. I think that client facing websites with strong performance needs are not the goal of Aurelia. Maybe I am wrong, but otherwise I think it's fair to close this. |
|
@anaibol Excuse me, but why did you close this again?! We very much need server rendering to work. We can debate whether full blown isomorphism is needed, but the basic rendering absolutely needs to be there - and it needs to be documented. @EisenbergEffect What's your take on this? |
|
@thomas-darling either this one will be re-open or a new one will be made, work on this feature is not dropped. |
|
Ok, I reopened then, maybe you are right, but this doesn't seem a priority at all or doesn't seem the focus of Aurelia. |
|
There are many priorities which all compete with each other for resources, like on any project. This is being worked on and there should be a solution available soon. |
|
@EisenbergEffect You've mentioned that it's almost done, awaiting integration or something similar. Is there any place I can get a look at this? I may be able to help with low-hanging fruit. Thanks! |
|
@jhanschoo yep we're putting the final things in place. There's one bug that popped up (rather late in the process) that we have to look at, but once it's fixed we'll release a skeleton thats preconfigured for ssr which you can look at and experiment with |
|
@JeroenVinke , linking to the issue might attract people helping out |
|
Definitely. I have made an issue here: aurelia/router#552. |
|
with release of ssr |
|
Shipped! |
and others
Hi, I am very interested on Aurelia. I would like to ask if is there a plan to add an isomorphic architecture on it. We would have models, routes and templates on both sides, and we could render pages from server side. I think that's an important point today on Javascript frameworks.
Thanks!
The text was updated successfully, but these errors were encountered: