А почему вы уверены, что это было более болезненно? У всех свои особенности, свои слабые и сильные стороны. Вам как отличнице было тяжело одно, троешникам — другое, одаренным — третье. Редко кому вообще легко.
Ну и опять же, если человек не пишет и не говорит о своих переживаниях и трудностях, это не значит, что их нет.
Например, по Фаулеру, репозиторий — медиатор между доменным слоем и слоем датамаппера, обеспечивающий возможности выборки по критериям.
И где здесь о том, что репозиторий должен содержать все требуемые данные?
Как вы собираетесь делать выборки, если у вас доступна только одна таблица? Да никак, в любых случаях кроме самых тривиальных это просто не работает.
Очевидно же, путем запроса нескольких репозиториев.
DbContext, DbSet и прочий LINQ — это не классический репозиторий, это сущности, поддерживающие описание запросов к источнику данных на .NET совместимом языке. Он обязан иметь доступ ко всем возможным сущностям, т.к. неизвестно, какие будут запросы.
Вы уверены, что это нужно делать именно одним контекстом? У него не будет практически ни одного свойства, которое ожидается от контекста (транзакционность, трансляция LINQ в SQL). По-моему, такое нужно делать как можно более явным, а не инкапсулировать.
Не вижу там shouldComponentUpdate. Мне кажется, можно было бы реализовать его и проверять, изменились ли данные, возвращаемые monitor (а предыдущие сохранять в стейте, например).
Или, как вариант, возвращать true из shouldComponentUpdate каждые 16мс. forceUpdate, как по мне, не выглядит правильным решением.
Не совсем понял из статьи и из комментариев, почему нельзя оптимизировать перерисовку компонента до обновления только свойств top и left (или transform)?
Хотя веб, конечно, тот еще бардак, у него есть два огромных преимущества:
веб много лет эволюционировал для разработки UI. В результате в нем есть классные подходы типа FRP, которых нет (насколько я знаю) ни в одном десктопном фреймворке (кроме React Native).
компонуемость: практически нет ограничений на содержимое элемента, поэтому можно довольно легко делать очень сложные вещи, типа тех же гридов.
Как на Java FX сделать сложный грид? Как вывести туда данные? Можно ли сделать меню у заголовков столбцов?
Единственный, на мой взгляд, реальный конкурент веб-подходам на десктопе — это мобильные приложения, но им еще долго догонять веб-приложения по удобству разработки.
Уровень преподавания, студентов и преподавателей напрямую связан с полезностью и востребованностью образования.
Так же очень важен общий уровень мотивированности студентов, который поддерживается отчислением неуспевающих, и опять же, востребованностью образования.
В СССР технические специальности давали, насколько я понимаю, довольно актуальные знания, и выпускник, пришедший на производство, не чувствовал, что зря потратил шесть лет.
После СССР же эта связь нарушилась в большинстве специальностей, исключая, наверное, только медицину (да и там свои проблемы), ну и, в меньшей степени, госслужащих — адвокатов, судей и т.п.
А новые специальности, которые открывал каждый ВУЗ, они вообще зачастую оторваны от жизни.
Так вот, конечно же, не может быть массового, хорошего, но бесполезного обучения.
По-хорошему должен быть один-единственный canvas, на котором рисуется всё что нужно приложению любым нужным фреймворком.
Так это и сейчас можно. Только попробуйте продать такую разработку кому-нибудь. И дизайнера впридачу, т.к. на бутстрапе сверстать может даже программист, и от этого не будет тошнить, а рисовать на канвасе — это мы вернемся в век адских самописных утилит с джпег-картинками вместо кнопок.
а прижать футер резиновой высоты к низу страницы невозможно до сих пор (а с js нельзя, потому что будет мерцать из-за асинхронности)
Да вроде можно тем же флексом прижать, если устраивает скролл в рамках области контента
Были джава-апплеты. Не судьба. Был Сильверлайт. Был ActiveX. WPF в браузере. Даже Флеш — и тот отходит.
А отвратительный, старый, небезопасный веб, с ужасным Джаваскриптом, с пол-гигов памяти на вкладку — живет.
Делать интерфейсы как в играх — можно с бюджетами, как в играх. Впрочем, их можно в вебе делать и сейчас — да никто не делает. Потому что все описанное в статье — хорошо как теория, как идеальная картинка, но не как решение тех проблем, которые решает веб.
Реактивное программирование — парадигма программирования, ориентированная на потоки данных и распространение изменений. Это означает, что должна существовать возможность легко выражать статические и динамические потоки данных, а также то, что нижележащая модель исполнения должна автоматически распространять изменения благодаря потоку данных.
Не для спора, но в Реакте (да и везде) это есть — это поток данных из родителя в потомков через свойства. Тут, конечно, можно придраться к слову "автоматически" — Реакт распространяет изменения автоматически, но явным образом — через задание свойств каждого элемента. От неявного распространения — передачи данных через контекст — много проблем, поэтому от него почти все фреймворки уходят.
Послушайте, знает уже весь хабр про ваш mol. Честно говоря он ужасен и не уверен, что кто-то кроме вас его понимает и использует.
Он, похоже, весьма продвинут в плане внутренностей (и там даже есть вещи, которые нельзя реализовать в том же реакте), но синтаксис шаблонов ужасен. Нет, я уверен, что после изучения и подавления изначального впечатления, пользоваться им будет можно и, наверное, даже удобно. Но в том виде, котором он есть — не взлетит.
Одной строки, Карл! Какая вам разница асинхронное или синхронное значение выставляется? Разве не фреймверк должен заботиться о такой рутинной операции как разрешение промиса и запись в стейт? Сколько кода просто хломиться вот таким подходом.
А обработка ошибок? А индикатор загрузки? А перезагрузка?
Ради интереса: вы какие-нибудь фреймворки использовали в продакшн кроме Ext JS и UniGUI?
Реакт это каким образом слой абстракции над DOM? Оно же просто за шкирку берёт и мордой в свой псевдо-XML салат тыкает всю дорогу, причём ещё и в оторванный от HTML.
А что по-вашему тогда абстракция? А React Native тоже browser DOM использует? А серверный рендеринг?
Конечно, результат. Вы смотрите и видите, какая нода получилась. А потом, увидев ng-repeat, понимаете, что там не одна она такая, а их много. гляда на произвольный js-код в JSX вам надо в уме выполнить этот код, чтобы получить ту информацию, которая вслучае шаблонизатора есть сразу.
Ну так вы когда джаваскрипт код читаете, вы его в уме выполняете? С JSX все так же.
А почему вы уверены, что это было более болезненно? У всех свои особенности, свои слабые и сильные стороны. Вам как отличнице было тяжело одно, троешникам — другое, одаренным — третье. Редко кому вообще легко.
Ну и опять же, если человек не пишет и не говорит о своих переживаниях и трудностях, это не значит, что их нет.
И где здесь о том, что репозиторий должен содержать все требуемые данные?
Очевидно же, путем запроса нескольких репозиториев.
DbContext, DbSet и прочий LINQ — это не классический репозиторий, это сущности, поддерживающие описание запросов к источнику данных на .NET совместимом языке. Он обязан иметь доступ ко всем возможным сущностям, т.к. неизвестно, какие будут запросы.
Вы уверены, что это нужно делать именно одним контекстом? У него не будет практически ни одного свойства, которое ожидается от контекста (транзакционность, трансляция LINQ в SQL). По-моему, такое нужно делать как можно более явным, а не инкапсулировать.
Не вижу там
shouldComponentUpdate. Мне кажется, можно было бы реализовать его и проверять, изменились ли данные, возвращаемыеmonitor(а предыдущие сохранять в стейте, например).Или, как вариант, возвращать
trueизshouldComponentUpdateкаждые 16мс.forceUpdate, как по мне, не выглядит правильным решением.Не совсем понял из статьи и из комментариев, почему нельзя оптимизировать перерисовку компонента до обновления только свойств
topиleft(илиtransform)?Хотя веб, конечно, тот еще бардак, у него есть два огромных преимущества:
Как на Java FX сделать сложный грид? Как вывести туда данные? Можно ли сделать меню у заголовков столбцов?
Единственный, на мой взгляд, реальный конкурент веб-подходам на десктопе — это мобильные приложения, но им еще долго догонять веб-приложения по удобству разработки.
Вы согласны платить за мини-CRM цену Фотошопа?
Уровень преподавания, студентов и преподавателей напрямую связан с полезностью и востребованностью образования.
Так же очень важен общий уровень мотивированности студентов, который поддерживается отчислением неуспевающих, и опять же, востребованностью образования.
В СССР технические специальности давали, насколько я понимаю, довольно актуальные знания, и выпускник, пришедший на производство, не чувствовал, что зря потратил шесть лет.
После СССР же эта связь нарушилась в большинстве специальностей, исключая, наверное, только медицину (да и там свои проблемы), ну и, в меньшей степени, госслужащих — адвокатов, судей и т.п.
А новые специальности, которые открывал каждый ВУЗ, они вообще зачастую оторваны от жизни.
Так вот, конечно же, не может быть массового, хорошего, но бесполезного обучения.
Так это и сейчас можно. Только попробуйте продать такую разработку кому-нибудь. И дизайнера впридачу, т.к. на бутстрапе сверстать может даже программист, и от этого не будет тошнить, а рисовать на канвасе — это мы вернемся в век адских самописных утилит с джпег-картинками вместо кнопок.
Да вроде можно тем же флексом прижать, если устраивает скролл в рамках области контента
Были джава-апплеты. Не судьба. Был Сильверлайт. Был ActiveX. WPF в браузере. Даже Флеш — и тот отходит.
А отвратительный, старый, небезопасный веб, с ужасным Джаваскриптом, с пол-гигов памяти на вкладку — живет.
Делать интерфейсы как в играх — можно с бюджетами, как в играх. Впрочем, их можно в вебе делать и сейчас — да никто не делает. Потому что все описанное в статье — хорошо как теория, как идеальная картинка, но не как решение тех проблем, которые решает веб.
https://github.com/hshoff/vx
Не для спора, но в Реакте (да и везде) это есть — это поток данных из родителя в потомков через свойства. Тут, конечно, можно придраться к слову "автоматически" — Реакт распространяет изменения автоматически, но явным образом — через задание свойств каждого элемента. От неявного распространения — передачи данных через контекст — много проблем, поэтому от него почти все фреймворки уходят.
Он, похоже, весьма продвинут в плане внутренностей (и там даже есть вещи, которые нельзя реализовать в том же реакте), но синтаксис шаблонов ужасен. Нет, я уверен, что после изучения и подавления изначального впечатления, пользоваться им будет можно и, наверное, даже удобно. Но в том виде, котором он есть — не взлетит.
А обработка ошибок? А индикатор загрузки? А перезагрузка?
И именно этим он хорош!
Ради интереса: вы какие-нибудь фреймворки использовали в продакшн кроме Ext JS и UniGUI?
А что по-вашему тогда абстракция? А React Native тоже browser DOM использует? А серверный рендеринг?
Ну да, Реакт — он для программистов. Впрочем, утверждение, что шаблоны Ангуляра будет делать верстальщик — это, скажем так, самообман.
А изменение коллекции
@ContentChildrenкак-то повлияет на содержимое компонента?Ну так вы когда джаваскрипт код читаете, вы его в уме выполняете? С JSX все так же.
Более того, map — это джаваскрипт, npRepeat — это микроязык, свой для каждой директивы.