search

aurelia / framework

The Aurelia 1 framework entry point, bringing together all the required sub-modules of Aurelia.
MIT License
11.75k stars 623 forks source link

Isomorphic / Universal #72

Closed anaibol closed 6 years ago

anaibol commented 9 years ago

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!

EisenbergEffect commented 9 years ago

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.

Snugug commented 9 years ago

:+1: 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.

Perambulator commented 9 years ago

-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.

Snugug commented 9 years ago

@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)

Snugug commented 9 years ago

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.

yv989c commented 9 years ago

@mcquiggd T4 templates to synchronize my client side logic! Bro you are a genius! Thanks for the tip.

yv989c commented 9 years ago

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.

yv989c commented 9 years ago

@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.

yv989c commented 9 years ago

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.

yv989c commented 9 years ago

And sorry for my weird "English"

SimonMeskens commented 9 years ago

@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: https://github.com/SimonMeskens/AngularMVCTypeScript

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.

smolinari commented 9 years ago
  • open, flexible, and backend agnostic, with one of the future backends being an extension of Aurelia into server side too, if people want to use that option.

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

friday commented 9 years ago

:+1: 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).

SimonMeskens commented 9 years ago

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.

martindale commented 9 years ago

+1 on this issue. Hopefully it'll land.

anaibol commented 9 years ago

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. Routing, dependency injection, templating and data-binding (?)

ghost commented 9 years ago

-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.

EisenbergEffect commented 9 years ago

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.

martindale commented 9 years ago

Great to hear, @EisenbergEffect. Really looking forward to this – with full respect for the difficulty involved.

killua99 commented 9 years ago

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

ghost commented 9 years ago

@EisenbergEffect

-1

Concerned this will complicate what was a promising framework. Bad decision.

EisenbergEffect commented 9 years ago

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.

ghost commented 9 years ago

@EisenbergEffect

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%).

EisenbergEffect commented 9 years ago

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.

kristianmandrup commented 9 years ago

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 ;)

JacopKane commented 9 years ago

It could be nice for a blog post maybe with isomorphic third party view integrations before built-in isomorphic features completed.

friday commented 9 years ago

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.

Perambulator commented 9 years ago

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! :-)

Perambulator commented 9 years ago

@kristianmandrup

I completely agree with you that it is not worth spending time on making Aurelia Isomorphic. Other projects have that covered for those that want it. By the time it could be achieved, it would be redundant, or as you point out, currently unnecessary.

killua99 commented 9 years ago

If you don't use / like Isomorphic that doesn't meant is worthless.

I know companies that are using ReactJS cause the Isomorphic options because it decrease extra setup and it doesn't add more complexity to project with "another tool". You can use mostly the same code without especial "env point".

That is so unmaintainable to just install + install + install to obtain same result with a single Nice tool like this.

I believe it's ok that Aurelia (and fit on the "moderns UI") to support Isomorphic, it doesn't mean they need to spend time now on that, but if they want to represent a serious solution for many, then yes, they need to support it.

Perambulator commented 9 years ago

@killua99

If ReactJS is already Isomorphic, why are you not using that instead? Or Meteor? Why insist on it on another project?

friday commented 9 years ago

@Perambulator: 1. React is only isomorphic if you want it to be. 2. The "If you don't like it here you can leave" argument can be used against any sort of progress and change. @EisenbergEffect Maybe it's a good idea to close the comments for non-team members? Then people could subscribe and notifications of future progress from the team if this issue is used, without getting opinionated "+1" or "-1" in their news feed and email?

Perambulator commented 9 years ago

@friday

Isomorphic JavaScript frameworks are largely trying to solve problems they themselves created, with the claim that JavaScript is somehow capable of everything that specialised languages were designed for, with enough hacks and patches stuck on it. Why not leave JavaScript to do what it does best, and treat the other, specialised languages with the same courtesy?

And let Aurelia be developed as it was intended, not try to bend it to situations that are unsuited for it?

Perambulator commented 9 years ago

Ok, lets continue on that positive note...

@EisenbergEffect

A couple of questions

Is there a cut off date for feature requests for v1?

Is there a feature set published somewhere that we can refer to?

EisenbergEffect commented 9 years ago

We are trying to lock things down within the next month. That doesn't mean we won't add anything after that, but we need to work towards stabilization, performance and solid documentation without distractions of lots of new features for a little bit.

Primarily, "isomorphism" isn't a use case we want to tackle for the initial v1 release. Again, that doesn't mean we won't do it later. But, we want to have a solid framework for browser-based apps as well as phone gap and electron/nwjs desktop apps first. That was our original goal and we want to make sure we handle those scenarios better than any other framework or library.

After that, we've got some other features we want to do, which are valuable in their own right, but will also take us closer to isomorphism.

  1. Enable all aurelia libraries to run on the server. This enables some new testing scenarios, so it's valuable if only from that perspective.
  2. Once code can run on the server, we can then implement server view compilation. This isn't isomorphic rendering, but rather the ability to run Aurelia's view compiler as part of your build and bundle process. This enables more work to be done ahead of time, as part of your build, and then it doesn't need to be done in the browser at runtime. So, this will improve the startup time for all apps and reduce initial render times for all components. It also will make it possible to store compiled views in browser local cache to improve performance of successive runs of the application.
  3. After both of those things are in place, then we can look at doing a full server render for each route. This isn't quite isomorphic in the truest sense, but it solves the SEO problem without needing 3rd party libraries. So, it's nice to have a solution there.
  4. Finally, we can then "sync" a server pre-rendered app with a stateful Aurelia app running in browser, giving us 100% isomorphic support.

So, those are the stages. The first two would be beneficial to all developers, even those who are not interested in isomorphic apps. The 3rd stage can be done today with 3rd party libraries, so this is a nice to have for us, for those who don't want an extra dependency. All of that leads into 4 which adds the final pieces.

We have already begun some of the work on 1. That might get into our first release. We aren't going to push it, but it's already in progress and we're looking for the problem areas so we can make it work. Steps 2-4 involve significant work. Really, we are talking about a collection of features here, each one being rather complex. So, those will probably come in stages after v1, as point releases.

We really don't want to do what Angular 2 has done. They have massively complicated their architecture...to the point that very few people will be able to understand it and developing applications with it has become much more complicated, with many nuances. We really don't want that, so we're focusing on the developer experience we want first, then we'll come back and see about isomorphic support (yes, we already have ideas how to do this cleanly, but want to give those ideas some time to mature). In all of this, our goal is to be modular. So, if you don't care about isomorphism, you don't have to think or worry about it. If you do, you would install the necessary packages, agree to the "constraints" of the system and be on your way.

So, to all who are interested in this topic, I would just ask you kindly to be patient. For those who aren't interested in isomorphism, don't worry, we aren't going to brake the developer experience on you. For those of you who want it badly, you will have to wait longer and it will come in stages and in modular pieces so as not to disrupt others.

Martin-Andersen commented 9 years ago

I don't like the word isomorphism, but I like the concept (-: I think Meteor is on the right track, we need tooling that embraces javascript all the way, the road to the database / storage is simple to long. We write models in typescript, domain models in C# and map them to a database. we sync, validate in JS and C# and there is just so much duplicated code. We don't need T4 templates, we need a real javascript development environment. But until we get that shinny white unicorn, I will but my money on Aurelia. We need a javascript framework like this. To take over knockout, backbone and Angular

Perambulator commented 9 years ago

I showed that last post to my team mates, and they stopped work and laughed.

I can just imagine the conversation with my boss:

Me: 'hey, we are going to rewrite everything in JavaScript!' Boss: 'why?' Me: 'then we only use one language' Boss: 'what about our native mobile apps that you said we had to use as Cordova is rubbish, you said we should write those in C# and Xamarin for the same reason?' Me: 'Nope, we wont have those. We will only use JavaScript!' Boss: 'And the reporting..?' Me: 'Well, we are only using JSON in Mongo, so it will be a bit different' Boss: 'You mean it looks like a childs drawing and takes days to return data?' Me: 'You are catching on!' Boss: 'So no more OLTP and data warehouse? Transactions? What about referential integrity? Historical data?' Me: 'Not my problem' Boss: 'What are we going to tell the customers?' Me: 'Tell them the system is now a perfect unicorn'. Boss: 'But it doesn't meet the requirements' Me: 'I dont care, it meets mine'. Boss: 'But we have 3 years of development, and we would have to retrain everyone' Me: 'I dont care, I will only use JavaScript. Anyway, I am busy, have to put Full Stack on my CV' Boss: 'Hey, what about our Universal Apps...' Me: 'Im outta here. Tell the next guy good luck from me.'

zewa666 commented 9 years ago

@Perambulator honestly I had to chuckle a little bit, reading your little story but, guys please lets stay constructive here. General discussion is best done in our official Gitter channel, Github issues should really be for tracking features and issues.

Perambulator commented 9 years ago

@zewa666

Vladin, I agree with you. This whole Isomorphic thing is always going to be divisive; to avoid further distractions, I would suggest closing this thread. Let's focus on release 1.

EisenbergEffect commented 9 years ago

This week's update includes the new Platform Abstraction Layer (PAL) integrated across all repos. The bootstrapper now uses pal-browser to configure the framework for running in browser. There is an empty repo named pal-nodejs that we plan to implement the server-side capabilities in. This is the core building block for "phase 1" as described above.

glen-84 commented 9 years ago

I just watched this video where Steve Sanderson demonstrates server-side rendering of Angular 2 and React applications from within ASP.NET (using NodeJS under the covers).

I'd love to see something like this for Aurelia, but I understand the complexity and completely agree that this should be done properly as opposed to quickly.

Keep up the good work.

EisenbergEffect commented 9 years ago

Yep, we'll have it. Just hang in there. Right now we are focusing on being the best client-side solution. We'll have some fun news about that in the near future. After that we'll focus on being the best server-side solution as well.

aelberone commented 9 years ago

Hi Rob,

First of all, welcoming you I would like to thank you for great job. I love Aurelia concept for beautiful simplicity being at the same time even more powerful (just as i love CoffeeScript).

I wolud like to share my thoughts on strategies ServerSide vs ClientSide (SS vs CS) in long term view. Please assume that's my thoughts not complete & ready solution & I don't now specificity of your vision of Aurelia. It's just my thoughts because I care.

It's meaningful for me to have possibility to render SS (as you said as a module of course). But I think it's not [0,1] problem but rather [0..9].

Lets imagine 4 simple cases:

  1. Wearable device with little memory and little processing power with good or bad internet connection.
  2. Tablet on trip to Africa when I have shared satellite internet connection 10kbit/s.
  3. Exactly like 2 but it's second trip half year later and I have app in local cache.
  4. My powerful desktop at work with fast net.

ad1. Wearable

ad2. Africa

ad3. Loyalty profit

ad4. Hedonistic UX

Before we choose right strategy we must ask Client (connection) for

Now we can choose right balance between SS..CS

Have a beautiful day

EisenbergEffect commented 9 years ago

@tombern Thank you for your thoughtful analysis and use cases!

friday commented 8 years ago

I have to agree with @mcquiggd.

I think there are valid cases for server side rendering already mentioned in this thread, and that the opt-in solution already stated by Rob is the best strategy we can hope for. Adding new features or over-specifying a roadmap when software isn't stable is going to increase the investment and the risk of failing. It's better to build from the ground up than top-down: https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar

Wearables: I can't imagine why you’d want to be carrying around a server with you. Your lifeband or iBraces is better off pushing and pulling data to/from an external and more accessible server (via bluetooth to your smartphone). It's less power-consuming and easier to produce in a small form factor, not to mention that it makes your device discardable without losing data. It's faster and easier for manufacturers to update without firmware flashing. It's also less hassle for consumers not having to worry about domain names, dyndns and ssh certificates.

10kbit/s Africa-flight: SSR is more performant on initial page load because the CPU does less work. This doesn't have anything to do with slow network speeds, unless more data has to be transfered (which might not even be the case considering Aurelia would likely already be cashed on a cdn url shared between other Aurelia apps). With gzip, bundling, minification or HTTP/2.0 this is a tiny problem. Media files requires substantially more space and that's where you ought to focus if you're optimizing for slow connections. If there is still much to gain by using SSR on Africa-flights, it's better to measure it than to guesstimate: http://c2.com/cgi/wiki?PrematureOptimization

Some better reasons:

Since Angular 1.x doesn't do SSR the suggested "solution" in the last link^ is to duplicate the client app on the server with PHP, which I think is a terrible idea for maintenance. Even if you can simplify this by using platform-agnostic templates you'll still have duplicate routing logic.

smolinari commented 8 years ago

+1 @friday

Scott

aelberone commented 8 years ago

Thanks for your answer,

Summarizing at the beginning:

I argue that:

  • First Page SSR is what I need today because it holds me to use Aurelia in my web page just tomorrow (and social as rightly pointed by @friday)
  • and while conceptualizing module for SSR it's worth to have in mind possible future applications.

@mcquiggd & @friday

Ok, I agree that in first three cases (wearables, Africa) you are right (especially from today's view).

But I look at Aurelia not only as solution for today's requirements but solution capable to solve future needs. I believe that people with vision, like Rob, creating solutions not only makes it ready for today or future - but themselves chart the standards for that future.

That's why I have chosen David over Goliath (a'ka Aurelia over Angular 2.0)

From long term view I think the better world would be when OS app, web app, native app, SPA, non SPA, etc. will be not different applications for different platforms but rather one application which can be parameterized (or by app designer, or by user, or both) in area of target platform (just like media selectors in today's css).

"If something can be done simpler, the nature wants it to do this that way".

Look at browser development (from html page reader to today's web apps environment), look at idea of electron, chromeOS. I believe future goes to blend them all into one.

I also absolutely agree with you that "architectural 'clearness'" is top priority.

I also hate compromise.

But I believe in Jim Collins's "Genius of the AND" principle (from "Built to last" - Yes. it's about organisations)

When you need to choose between two choices ... Good organizations always can choose that better. But great can always find a (beautiful and simple) way to achieve them both without compromise.

ps

Have beautiful day

aelberone commented 8 years ago

@mcquiggd

Ok, I would like to stop this discussion because its going to "who is right" problem and is non productive.

We talk about two different things. You talk about "lets make next step" and I talk about "lets see where we are going" - both are needed. And I end this by quote:

Action without vision is only passing time. Vision without action is merely a day dreaming. Action with vision can change the world. [from Japanese Proverb]

Benoit-Vasseur commented 8 years ago

Hello,

Any goods news about server side rendering and universal app :) ? Is it still planned ?

I really need a good solution to handle SEO. When I search "aurelia hub dependency injection" in google : the first link is the github project, the second is an issue on github and the third is the home of aurelia hub (so not the page I am looking for which is http://aurelia.io/hub.html#/doc/api/aurelia/dependency-injection/1.0.0-rc.1.0.0/overview).

So I am worried about the capability to have a site correctly indexed by Google with Aurelia for now :/ Aurelia really interests me but I need a nice SEO. Does anyone have some practicals tips to handle this question :) ?

Thanks.

EisenbergEffect commented 8 years ago

As stated in the Aurelia RC Announcement, preliminary work has started and the feature is planned for this year.

As always, the community is invited to participate in helping to build out this feature. We have someone from the community that built out our NodeJS platform abstraction and it only took them a few days. It would probably only take another week or so to get server rendering for SEO in place. However, our core team is working on other priorities now so we can't yet devote time to it ourselves. We'll be putting more resources on it at the end of the summer.

The best part about open source is that any community member can jump in and help out wherever they see a need. Many of Aurelia's cool features and support for various libraries and tools happened that way. Once things mature, we then take many of these directly into the core or under our organization so we can provide official support. But if there's a need you have, just build a solution. There's nothing stopping you.