Comments 31
>>Поддержка разных языков: ES5, ES6, TypeScript, AtScript и CoffeeScript
жесть вообще, на это надо куча времени
жесть вообще, на это надо куча времени
Сарказм? Для ES6 нужна лишь поддержка ECMAScript 2015, а для всего остального и старого доброго ES5 хватит, ведь все это семейство *Script без проблем построцессируется в старый (ES5), ванильный Javascript.
Нет, почему же. Поддержка, насколько я понимаю это слово, означает что будут версии на этих языках и люди смогут их использовать (как есть angular-dart). Если же это будет просто библиотека по типу jquery, какой смысл тогда рассказывать об этой поддержке? Реально будет интересен только язык разработки и поддержка некоторых фич (типа наследования)? И было бы классно, если бы это был только ES6, а ES5 версия тогда была бы просто «скомпилированной»
Пример кода с Get Started:
Но ведь ровно также можно писать уже сейчас на ангуляре, для $inject ровно также, как далее в доках использую
И в конструктор все инжектится.
export class Welcome{
constructor(){
this.heading = 'Welcome to the Aurelia Navigation App!';
this.firstName = 'John';
this.lastName = 'Doe';
}
get fullName(){
return `${this.firstName} ${this.lastName}`;
}
welcome(){
alert(`Welcome, ${this.fullName}!`);
}
}
Но ведь ровно также можно писать уже сейчас на ангуляре, для $inject ровно также, как далее в доках использую
static $inject() {
return ['$http', '$sce'];
}
И в конструктор все инжектится.
Как раз на этом коде у меня случился ступор. Точнее на словах «It's plain vanilla JavaScript».
Подумал что я что-то пропустил в мире IT. Проверил в дев-консоли — а нет, все по-старинке.
Подумал что я что-то пропустил в мире IT. Проверил в дев-консоли — а нет, все по-старинке.
Это “plain vanilla JavaScript” из ECMAScript 2015.
Вот здесь можно побаловаться
Проверьте в дев-консоли Chromium Canary :)
Ну это не новость :)
Chrome 42 там еще не добавили. В нем многое появилось.
Вот тут можно следить за обновлением фич www.chromestatus.com/features
Проверил в дев-консоли
А с 'use strict'?
(function () {
'use strict';
return class Welcome{
constructor(){
this.heading = 'Welcome to the Aurelia Navigation App!';
this.firstName = 'John';
this.lastName = 'Doe';
}
get fullName(){
return `${this.firstName} ${this.lastName}`;
}
welcome(){
alert(`Welcome, ${this.fullName}!`);
}
}
})();
Как у него с производительностью? Сходу не нашел.
В данный момент не понятно, потому что это превью
Rob дал FAQ почитать пока еще не выложил его.
What is performance like?
First, it's important to note that there are different aspects of a framework like Aurelia which exhibit different performance characteristics. I'll list a few below along with comments on each.
To summarize, some things are quite fast and some aren't but we've barely even begun work on performance, so expect big improvements in the coming months.
What is performance like?
First, it's important to note that there are different aspects of a framework like Aurelia which exhibit different performance characteristics. I'll list a few below along with comments on each.
- Initial Render — The amount of time it takes to initially render the UI. In this area we aren't nearly as fast as we'd like to be. You probably won't notice it on desktop, but you probably will on mobile. We haven't focused on this at all yet, but we do have a solid list of known improvements that should yield massive improvements. Expect to see lots of work in this area soon.
- Data Updates — The amount of time/work it takes to update an existing UI based on changes in data. Here we are quite fast. This is because we have an observer system that batches changes on the browser's Microtask Queue. As a result, we can easily out-perform a dirty checked system or a virtual DOM system.
- Animation — Smooth, native-like animations. Aurelia doesn't have animation features built in just yet (aside from what you can do with straight CSS). That's one reason why we aren't at Beta. So, «animation performance» technically doesn't apply to us. However, we hope to integrate with a number of popular animation libraries and we'll work on making that as efficient as possible.
To summarize, some things are quite fast and some aren't but we've barely even begun work on performance, so expect big improvements in the coming months.
Когда разработчики «мега фреймворков» задумаются о рендринге на сервере без костылей!
Это клиентский фреймворк. Задача рендерить на сервере перед ним не ставится.
Это не отменяет того что он мог бы отрисоваться на севере, потом выплюнутся на клиент и сразу инициализироваться нужным состоянием и в такой «хотелки» есть вполне обоснованная потребность.
Я понимаю что у вас есть некие потребности. У меня, например, таковых нет.
Этот фреймворк можно рассматривать как WPF для веб. MVVM, Two way binding, Value converters. Вот это всё.
Мне, например, кажется странным желание рендерить XAML на сервере.
Тут решаются другие задачи. Люди пытаются довести разработку веб приложений до уровня разработки десктопных приложений.
Их цель, имхо, это enterprise, с кучей CRUD и горой кода.
Этот фреймворк можно рассматривать как WPF для веб. MVVM, Two way binding, Value converters. Вот это всё.
Мне, например, кажется странным желание рендерить XAML на сервере.
Тут решаются другие задачи. Люди пытаются довести разработку веб приложений до уровня разработки десктопных приложений.
Их цель, имхо, это enterprise, с кучей CRUD и горой кода.
Если вы делаете веб приложение которое доступно после авторизации то особо проблем с этим нету. Если вы делаете публичный сайт, то этот фреймворк не для этого, тут лучше как и раньше всё генерировать на сервере, будет проще и быстрее.
Вы всегда можете рендерить React через React.renderToString на сервере без костылей, а в качестве абстракций для роутинга, работы с данными и прочим взять любые импонирующие вам решения.
вот только я не видел еще ни одного до конца продуманного решения кроме fluxible от yahoo. Fluxible от yahoo неплохое решение, но оно очень узкоспециализировано и клепалось под Express, плюс имеет довольно развесистое API. Других реализаций доведенных до ума, я еще не видел.
К сожалению я еще не встречал нормального решения для рендера больших React приложений на сервере.
derbyjs.com уже пару лет как все рендерит и на клиенте и на сервере
Мы сначала создаём себе проблемы, а потом героически их решаем.
Если у вас приложение то вам не нужно, что то рендрить на сервере.
Если у вас публичный сайт, то вам не нужны MVC на клиенте, это медленно и непрактично (SEO как минимум).
Если скрещивать ужа с ежом будет больно. Причём кажется понятно откуда такое желание, но от этого не легче.
Если у вас приложение то вам не нужно, что то рендрить на сервере.
Если у вас публичный сайт, то вам не нужны MVC на клиенте, это медленно и непрактично (SEO как минимум).
Если скрещивать ужа с ежом будет больно. Причём кажется понятно откуда такое желание, но от этого не легче.
Как я понял его durandal js не взлетел и он начал пилить новый фреймворк.
Вы не правильно поняли.
Это логическое продолжение Durandal написанное на ES6 и ES7 и использующее их фичи, собранное под «evergreen» браузеры. Так же они выкинули Knockout и написали свои байндинги, на подобии тех, что есть в Angular (используются Object.observe и Array.observe, если доступны, иначе dirty checking).
Это логическое продолжение Durandal написанное на ES6 и ES7 и использующее их фичи, собранное под «evergreen» браузеры. Так же они выкинули Knockout и написали свои байндинги, на подобии тех, что есть в Angular (используются Object.observe и Array.observe, если доступны, иначе dirty checking).
Sign up to leave a comment.
Aurelia — новый современный JS-фреймворк