Войти
ПрограммированиеФорумВеб

Комфортный переход с С++ на javascript (3 стр)

Страницы: 1 2 3 4 5 Следующая »
#30
16:04, 7 июня 2014

Подскажите, пожалуйста, православный способ разбивать код на несколько js-файлов. инклудов/импортов нет. Неужто просто подключать все нужные файлы в html5-тегах?


#31
18:51, 7 июня 2014

MoKa
> В какой сфере ты работаешь?
не игровой, но с веб связанной.

MoKa
> По этому я не знаю о чём ты говоришь, мои 7 лет в этой сфере показывают о
> актуальности .prototype.
я пробовал разные подходы, вариант с примесями мне больше всего понравился. Используя этот подход мы получаем преимущества множественного наследования(для UI очень нужная штука тк фантазии заказчиков бывают особо извращенными) без потери производительности и без матрешек в прототайпах

AloneR
> Неужто просто подключать все нужные файлы в html5-тегах?
Можно так, можно requirejs, можно весь js одним пожатым файлом отдавать.

#32
19:37, 7 июня 2014

Mephistopheles
> Можно так, можно requirejs, можно весь js одним пожатым файлом отдавать.
Пожатый, в смысле после обфускации?

Я решил для удобства разработки писать в разных файлах, а в релизную версию скинуть всё в один файл и пропустить его через обфускацию каким-нибудь онлайн-сервисом. Этакий аналог "компиляции" и "линковки" :-D
Годно?

#33
22:12, 7 июня 2014

AloneR
> пропустить его через обфускацию каким-нибудь онлайн-сервисом. Этакий аналог
> "компиляции" и "линковки"

Вообще-то для подобного давно уже существуют локальные системы сборки (Grunt, Yeoman), которые и sass/less компилируют и обфусцируют, и javascript объединят и тоже обфусцируют, и тесты прогонят и много ещё чего полезного сделают.

#34
1:03, 8 июня 2014

$tatic
> sass/less компилируют и обфусцируют
Обфускация css это сильно)

AloneR
> Годно?
Есть недостатки, но вполне жизнеспособно, на работе так один большой проект работает(почти 2мб пожатого кода).

AloneR
> Пожатый, в смысле после обфускации?
обфускация+сжатие

#35
0:53, 10 июня 2014

AloneR
> Подскажите, пожалуйста, православный способ разбивать код на несколько
> js-файлов. инклудов/импортов нет. Неужто просто подключать все нужные файлы в
> html5-тегах?
Обычно разрабатывают в разных файлах и тестируют либо также (в разных), либо используют grunt и т.п. смотрителей (в больших проектах будут проблемы со скоростью), для релиза всё компилируют в один используя файл где вручную указывают поочерёдность загрузки, либо используя requirejs (бяка) и тому подобные бяки, чтобы последовательность загрузки вычислялась из зависимостей. И потом это дело сжимают (closure compiler имхо, самый годный).
Для релиза всегда рекомендуется один файл, или минимум если не весь JS нужен всегда. Если кода на 10+мб, и это single-page приложение, тогда рассмотри lazy loading. Но снова, это уже дело вкуса.
Лично я предпочитаю разраотку в удобстве в разных файлах, и контроль поочерёдности загрузки вручную, а сборка для релиза - дело мелкое. Главное удобство разработки.

Mephistopheles
> не игровой, но с веб связанной.
Я в разных, и сейчас в игровой, также и с вебом 70% отработал.

Mephistopheles
> я пробовал разные подходы, вариант с примесями мне больше всего понравился.
> Используя этот подход мы получаем преимущества множественного наследования(для
> UI очень нужная штука тк фантазии заказчиков бывают особо извращенными) без
> потери производительности и без матрешек в прототайпах
Ты говоришь о вкусах. Мульти наследние и расширения делаются с теми же .prototype весьма просто. При этом втой ООП должен быть ясным и чётким, а не с магией где не явно расширяешь объекты по пути выполнения кода - это большой анти-паттерн который сильно замедляет скорость разработки и деббагинг (визуализация дерева наследия и т.п. очень полезные вещи с prototype, чем расширения объектов не могут похвастаться), тем более расширение объектов многократно медленней, следственно для игр и других типов приложений с высокими требованиями к произвдительности - не подходит.

#36
9:22, 10 июня 2014

MoKa
> Если кода на 10+мб, и это single-page приложение
Кода существенно меньше и это html5-игра для мобайл браузеров)

>для релиза всё компилируют в один используя файл где вручную указывают поочерёдность загрузки
Как вручную указать поочередность загрузки?

Это ничего, если один из файлов js я беру сторонний (pixi.js, например, для графики), который уже пожат и обфусцирован, а потом скормлю его вместе с моими файлами в один, не упадет ли производительность? Тем более что делается для мобильных браузеров.

Спасибо за ответы!

#37
10:12, 10 июня 2014

MoKa
> а не с магией где не явно расширяешь объекты по пути выполнения кода
Те объявить объект в одном месте, а потом по всему коду в прототип ему насовывать нужные функции это норма?) Конечно есть случаи когда это удобно, но они редкие и ценность прототипа не повышают.

MoKa
> тем более расширение объектов многократно медленней,
Неа, когда методы лежат в обьекте, а не гдето в дебрях прототайма, то методы вызываются быстрее.

MoKa
> Мульти наследние и расширения делаются с теми же .prototype весьма просто.
Интересно на это посмотреть:)

#38
13:46, 10 июня 2014

Mephistopheles
> Те объявить объект в одном месте, а потом по всему коду в прототип ему
> насовывать нужные функции это норма?)
С .prototype нет, это не норма, и техническая композиция компонентов всегда должна быть явно отделена от логики приложения, следственно каши не будет.
Когда при расширениях объекта - это норма, чего я категарически против, т.к. это сильно херит всю композицию и возможность отлавливать конкретно от куда что исходит.

Mephistopheles
> Неа, когда методы лежат в обьекте, а не гдето в дебрях прототайма, то методы
> вызываются быстрее.
Если у тебя 64+ наследований, то стоит пересмотреть твою логику как таковой. Но ты мне покажи бенчмарки, и тогда поговорим.
Тем более скорость вызова функции напрямую и из прототипа неимоверно ничтожна. А вот скорость создания объекта с .prototype, мусоро сборка и количество расходуемой памяти, а также shadow class (то как броузеры пре-компилируют структуры объектов для оптимизации) - тут разница на столь колосальна, что даже на игре с танчиками и стрельбой и 128 танчиками на поле, ты уже видишь жестокие заморозки из-за сборщика мусора с твоими расширяемыми объектами, когда .prototype будет в таком случае просто ОК.

Mephistopheles
> Интересно на это посмотреть:)
Ссылку на инспектор структур давал уже ранее, читай внимательнее: http://www.objectplayground.com/
Посмотри конкретней на пример реализации Resig Inheritance. Я делал подобный фреймворк с наследованием классов: https://gist.github.com/Maksims/8070893
Выложи пожалуйста твои наработки и тесты по обоим случаям тоже, любопытно посмотреть, т.к. мнение у тебя звучит устоявшимся.

#39
18:49, 10 июня 2014

Если не сложно, ответьте на мой вопрос, пожалуйста.

#40
20:02, 10 июня 2014

MoKa
> Если у тебя 64+ наследований, то стоит пересмотреть твою логику как таковой.
если больше 3-4:)

MoKa
> Когда при расширениях объекта - это норма, чего я категарически против, т.к.
> это сильно херит всю композицию и возможность отлавливать конкретно от куда что
> исходит.
В команде от 3 человек такое расширение "норма":)

MoKa
> Тем более скорость вызова функции напрямую и из прототипа неимоверно ничтожна.
Напрямую то конечно, но тогда из без того куцое ООП в js сводится к процедурке. Что кстати довольно неплохо: пишем процедурку где к данным обращаемся через this и при вызове методов просто ставим нужный контекст в виде обьекта с данными.

MoKa
> Выложи пожалуйста твои наработки и тесты по обоим случаям тоже, любопытно посмотреть
Цикл копирующий поля из одного обьекта в другой явно не то на что действительно стоит смотреть)

Я не искал какой то сакральный смысл в языке для анимации кнопочек, просто копирую поля из родителя в предка. Всетаки js это write only язык и сильно заморачиваться архитектурой не смысла.

MoKa
> т.к. мнение у тебя звучит устоявшимся.
мнение насчет js у меня устоялось как только мне пришлось на нем писать:)

#41
21:11, 10 июня 2014

Mephistopheles
> В команде от 3 человек такое расширение "норма":)
Тут да, от команды всегда зависит, у меня бывало и с одним другим разрабом и уже ни в какую не удавалось сладить в плане идеологий..

Mephistopheles
> Напрямую то конечно, но тогда из без того куцое ООП в js сводится к процедурке.
> Что кстати довольно неплохо: пишем процедурку где к данным обращаемся через
> this и при вызове методов просто ставим нужный контекст в виде обьекта с
> данными.
Интересно что многим процедурка как раз и по душе, посмотреть на тот же lodash. Лично я против грубой процедурки и за динамику (право выбора). Но порой и так и так подходит, зависит от ситуации, главное чтобы была явная структура, и отдельно явная логика.

AloneR
> Кода существенно меньше и это html5-игра для мобайл браузеров)
Но если мобайл, то тут если js кода уже более 100кб, то стоит подумать о lazy loading, если совсем за производительностью гнаться, чтобы не заморачиваться можно грузить самое-самое необходимое чтобы на 10 секунд занять пользователя в менюшках или т.п. и позади грузить остальной код.
Но если у тебя когда после gzip'а в скомпилированном виде менее 200кб, не парься, грузи одним файлом.

AloneR
> Как вручную указать поочередность загрузки?
Ну тут тебе нужно будет написать маленький скриптик и отдельно файл. Скриптик будет грузить файл где будут на каждой строке прописаны путь к файлам, затем все это пихать в один файл и пропускать через компилятор и другие плюшки.

#42
21:21, 10 июня 2014

MoKa
> затем все это пихать в один файл и пропускать через компилятор и другие
> плюшки.
вот, кстати, асинхронный загрузчик для скриптов, особо нагрузкой его не гонял, но вроде работает.

+ это_не_правильный_код_ниже_правильный
#43
9:34, 11 июня 2014

Благодарю)

#44
12:03, 11 июня 2014

Упс я только сейчас заметил там баг:) Он может добавить в дом не загруженный скрипт) щас перепишу:)

+ исправленная_версия
Страницы: 1 2 3 4 5 Следующая »
ПрограммированиеФорумВеб

Тема в архиве.