Tired of outsourcing? Get hired at a top product startup from Silicon Valley 🚀
×Закрыть

Frameworkless JavaScript

Панове фронтендери і наближені до фронта, так як Гугл видає не самі свіжі і самі релевантні результати, а статті в інтернетах здебільшого пишуться заради галочки в ЧСВ пісатєля, а не користі, маю до Вас кілка питань
* Чи можливо в пізньому 2018му році при розробці малих і середніх веб аплікух обійтись без 100500 фреймворків/бібліотек, а покластись на штатні можливості ES6/HTML5/CSS3(ну можливо jQuery для швидкої імплементації UI свістєлок для MVP і Вебпак для збірки)?
* Хіба не буде більш ефективним займатися розробкою саме того шо потрібно, а не намагатись криво інтегрувати черговий «дуже важливий» фреймворк і розрулювати залежності?
* Поділіться, будь-ласка, гарними статтями по темі
* Які найбільші проблеми стоять на даному шляху. Кривість рук кодерків і можливість застосувати правильно шаблони розробки не в рахунок?
* Поділіться, будь-ласка, Вашим досвідом розробки веб аплікух без зайвого «сміття»
Дякую!

LinkedIn

Лучшие комментарии пропустить

Любой хороший инструмент делает сложные вещи реальными, а простые оставляет простыми. Современные фреймворки — это хорошие инструменты. Это означает что чем больше у вас задача тем больше вы получите пользы от использования фреймворков. В то время как отказ от них задачи не упростит

В мире где у всех прямые руки фреймворки позволяют эффективно бороться со сложностью и забирают на себя часть рутины

Начнем со сложности. Если вы не используете никакие фреймворки — у вас в том-же приложении будет значительно возрастать сложность. Единственный эффективный способ бороться со сложностью — абстрагирование. То есть вы будете создавать свой фреймворк. Так как мы тут в волшебном мире прямых рук — вы, наверняка, напишете что-то лучшее чем за +/-5 лет накатали гугл, фб и открытые сообщества. Но только вы снова оказываетесь с фреймворком. Только его никто кроме вас не знает, а значит растет стоимость расширения команды и падает ваша стоимость как специалиста

С рутиной все просто — это источник багов, это код которые требует поддержки, это демотивация делать одно и то-же, а все вместе это возрастающая стоимость разработки

И да, jquery это не фреймворк, это библиотека. То есть он забирает на себя рутину, но не влияет на сложность

P.S. ES6 и фреймворки это вещи вообще параллельные и никак не взаимозаменяемые. Вы, наверно, имеете ввиду Browser API

Кстати, вот такое введите в консоли браузера и посмейтесь с результата )))) [6,2,-2,-7].sort()

Хіба не буде більш ефективним займатися розробкою саме того шо потрібно, а не намагатись криво інтегрувати черговий «дуже важливий» фреймворк і розрулювати залежності?

Обычно те кто так говорят и без фреймворка не могут, и с ним.

Зависит от размера приложения. Если там один экран — можно и без фреймворков. Если полноценное SPA с роутингом — то без фреймворка в конце-концов будешь писать аналог фреймворка. Только фреймворкам популярным по несколько лет и над ними работали команды инженеров. А сам будешь наступать на грабли, которые можно обойти.

Поділіться, будь-ласка, Вашим досвідом розробки веб аплікух без зайвого «сміття»

Клепал я веб-приложение с 2010 года. Фреймворки тогда ещё не были на слуху, да и планов наперед не было (то есть я не знал примерно во что тот проект вырастет). Ну я и клепал на php да jquery. Потом оно стало расти. Стало расти и количество костылей. Сейчас код того проекта мне показывать стыдно, хотя оно до сих пор работает и доход заказчику приносит. Теперь я знаю что нужно заранее узнавать масштабы проекта, да и вообще если там есть хотя бы 2 экрана и роутинг и это должно грузиться аяксом — лучше сразу пилить SPA на фреймворке.

Я работал с реактом, писал проекты на ангуле. Я готов официально заявить: ES6 покрывает абсолютно весь скоуп задач который, ЯКОБЫ решают фреймворки.
Если вам, конечно, нужно решать задачи, а не ходить по модным тусовкам где модники на гироскутерах ласкают друг-другу ЧСВ.
В мейнстрим тусовке судя по всему никто и не поймет о каком это ES6/ES8 вы говорите. Что за фреймворки такие? Есть модуль для вебпак?

Написав проект на ES6 я точно знаю что:
1. Он нативен и любой человек мало-мальски знающий жабаскрипт разберется
2. Он не аутдейтнится через ГОД как вонючий... кхм. [insert framework here]. А будет жить минимум 10 лет
3. Он быстрый. Никакого оверхеда, загрузок, злогребучих
4. Разрабатывать на ES6 (внимание!) гораздо быстрее чем на говнофреймворках. No, really я написал и отдал рабочую альфу (админка с фичами) на экме на 1 месяц.
На ангуларе мне понадобилось 3(!) для приблизительно такого же проекта.

Роутер — если правильно спроектировать приложуху, то роутер можно накатать в пару строчек.
Ад коллбеков — Господа. просто научитесь работать с fetch(), Promise, Promisa.all.
Темплейты — это отдельная тема и то, что делает реакт — не вызывает никаких эмоций кроме фейспалма. css в жабаскрипте? серьезно?
Вот вам загрузчик:

async function load(url) {
    let data = await (await (fetch(url)
        .then(res => {
            return res.text();
        })
        .catch(err => {
            console.log('Error: ', err);
        })
    ))
    return data
};

async function include(link, input) {
    let data = await (await (load(`${link}.html`)
        .then(data => {
            var newData = input;
            tpl = '`' + data + '`';
            return eval(tpl);
        })
    ));
    return data
};
Вот вам темплейт в файле list.html
${(() => {
    var lol = '';
    newData.blabla.map(item => {
        lol += `
        <li>
        <a href="#blabla,${item.id}" title="${item.name}">
            <span class="id">${item.id}</span>
        </a>
        </li>
        `
    })
    return lol
})()}

Достаточно научиться работать со сраными кавычками [``]. И самое главное никакиж .jsx, никаких pug’ов, интерпритаторов и прочего мусора. Чистый js и html.

Я переписал абсолютно все свои проекты на экме, теперь заказчик даже не заикается о фреймворках.
Чаще всего на фреймворках пишет фронтендщик, который ничего не изучал кроме этих самых фреймворков или программисты на копипасте со стаковерфлоу.
Они же внедряют какю-то дичь с периодичностью раз в год (для того чтобы переписывать проекты и небыть уволенными).

Дякую тоби боже шо я не фронт-энд девелопер :-)

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Завжди свій код з часом перетворюється на фреймворк... Тому я одразу пишу свої фреймворки. :D

Хіба не буде більш ефективним займатися розробкою саме того шо потрібно, а не намагатись криво інтегрувати черговий «дуже важливий» фреймворк і розрулювати залежності?

Обычно те кто так говорят и без фреймворка не могут, и с ним.

Зависит от размера приложения. Если там один экран — можно и без фреймворков. Если полноценное SPA с роутингом — то без фреймворка в конце-концов будешь писать аналог фреймворка. Только фреймворкам популярным по несколько лет и над ними работали команды инженеров. А сам будешь наступать на грабли, которые можно обойти.

Поділіться, будь-ласка, Вашим досвідом розробки веб аплікух без зайвого «сміття»

Клепал я веб-приложение с 2010 года. Фреймворки тогда ещё не были на слуху, да и планов наперед не было (то есть я не знал примерно во что тот проект вырастет). Ну я и клепал на php да jquery. Потом оно стало расти. Стало расти и количество костылей. Сейчас код того проекта мне показывать стыдно, хотя оно до сих пор работает и доход заказчику приносит. Теперь я знаю что нужно заранее узнавать масштабы проекта, да и вообще если там есть хотя бы 2 экрана и роутинг и это должно грузиться аяксом — лучше сразу пилить SPA на фреймворке.

Двести метров джавпскрипта грузит текста триста байт, я элита программистов, а не какой-то раздолбай!
Полную версию слухать тут: soundcloud.com/...​z-kun/kolkhoznyy-frontend

Вообщем прибежали джуниоры и начали рассказывать что фреймворка не нужны, прибежали троли — покидались какашками.
Но в целом какой топик такие и комменты

А мне импонирует вот такой подход: micro-frontends.org
Вот статья как без лишних фрейморков можно делать приложение/игру : bakhirev.biz/book/index.html#fOJqD

розробки веб аплікух без зайвого «сміття»

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

Які найбільші проблеми стоять на даному шляху.

Нет понимания чем отличаються тот или иной фреймворк. Нет т.з. — результат хз

Любой хороший инструмент делает сложные вещи реальными, а простые оставляет простыми. Современные фреймворки — это хорошие инструменты. Это означает что чем больше у вас задача тем больше вы получите пользы от использования фреймворков. В то время как отказ от них задачи не упростит

В мире где у всех прямые руки фреймворки позволяют эффективно бороться со сложностью и забирают на себя часть рутины

Начнем со сложности. Если вы не используете никакие фреймворки — у вас в том-же приложении будет значительно возрастать сложность. Единственный эффективный способ бороться со сложностью — абстрагирование. То есть вы будете создавать свой фреймворк. Так как мы тут в волшебном мире прямых рук — вы, наверняка, напишете что-то лучшее чем за +/-5 лет накатали гугл, фб и открытые сообщества. Но только вы снова оказываетесь с фреймворком. Только его никто кроме вас не знает, а значит растет стоимость расширения команды и падает ваша стоимость как специалиста

С рутиной все просто — это источник багов, это код которые требует поддержки, это демотивация делать одно и то-же, а все вместе это возрастающая стоимость разработки

И да, jquery это не фреймворк, это библиотека. То есть он забирает на себя рутину, но не влияет на сложность

P.S. ES6 и фреймворки это вещи вообще параллельные и никак не взаимозаменяемые. Вы, наверно, имеете ввиду Browser API

якщо це не нагружений SPA з кучою скрінів, евентів, API звернень, то з головою досить звичайного js і якихось пари бібліотек для моб оптимізації/ефектів.. перевірено, працює )

Если мы говорим о 3+ страниц то одним

ES6/HTML5/CSS3

 — это больно)

Возьмите библиотеку React)
Там нет ничего сложного)

Тема чисто ради срача, чтобы js-хейтеры смогли поисхдоить на г...

Чи можливо в пізньому 2018му році при розробці малих і середніх веб аплікух обійтись без 100500 фреймворків/бібліотек, а покластись на штатні можливості ES6/HTML5/CSS3(ну можливо jQuery для швидкої імплементації UI свістєлок для MVP і Вебпак для збірки)?

Вот серьёзно? Спрашивать о том, можно ли заменить фреймворки нативным кодом и тут же предлагать использовать jQuery, который как раз уже давно можно полностью заменить ванилой?

Они ж древние как продукт жизнедеятельности мамонта, и таки же страшненькие на вид

Да конечно можно. Все зависит исключительно от того, что вы хотите сделать. Почему-то все фреймворко-ненависники считают, что фреймворки используются просто потому что это модно, и принято пихать их где-попало (возможно, какая-то часть так и делает, только их явно не большинство). Тут ведь проблема не в том. Если вам нужен условный лендинг, на чем проще, на том и делайте. Но если вы вот пришли, и решили написать сложное приложение — без глубоких знаний js у вас это просто не выйдет. А если и выйдет, то это будет мало похоже на то, что бы вы хотели видеть. В то время, как фреймворки позволяют строить сложные приложения без изучения дебрей языка. Потому что с фреймворком вы будете концентрироваться на том, что именно вы хотите сделать, а не на нюансах взаимодействия с браузером. Если же у вас тонна знаний и опыта, и вы считаете что все фреймворки говно — в сложной системе вы рано или поздно начнете писать свой.

В то время, как фреймворки позволяют строить сложные приложения без изучения дебрей языка. Потому что с фреймворком вы будете концентрироваться на том, что именно вы хотите сделать, а не на нюансах взаимодействия с браузером.

Ага, а потом бегают 100500 реакт/ангуляр-формошлепов которые нихрена ни языка ни окружения не понимают. Какие такие есть дебри в JS что фреймворки проще кажутся?

Давайте начнем с того, что эти самые фреймворки как минимум покрывают потребности бизнеса, иначе уже давно бы загнулись.
Заметьте, я нигде не писал о том, что фреймворки простые. А лишь о том, что они позволяют концентрироваться на других, более нужных вещах — а именно, разработке самого функционала. Самые популярные react и angular в первую очередь покрывают взаимодействие с dom и вопросы архитектуры. Кроме того, когда уйдет человек, написавший приложение, в случае фреймворков вам всего-то и надо найти одного из этих 100500 бегающих формошлепов, который достаточно быстро вьедет в то, что происходит, и начнет себе педалить дальше. В случае же с уникальной системой, которая очень круто работает, вам сначала надо будет вообще в принципе найти того, кто согласиться с ней работать, а потом ждать кратно большее количество времени, покуда человек во всем разбереться, да еще и напишет в таком же стиле, а не на jquery сбоку кусок прилепит. Потому что простой она быть априори не может, если обладает возможностью масштабироваться и действительно эффективно работает. Спрос порождает предложение

Давайте начнем с того, что эти самые фреймворки как минимум покрывают потребности бизнеса, иначе уже давно бы загнулись.

Ок, я полностью поддерживаю необходимость фреймворков. Против них я и слова не написал.

Меня реально пугает тенденция учить готовые решения. Человек берет фреймворк, заучивает соновные паттерны применения и готово. А что и как работает под капотом и главное как может быть по другому уже не волнует. Докатились до того что фронтендщики начали дома бояться. Собеседовали недавно реакт-мастера одного, лида в чик-чик-продашн тиме. Спрашивали как элемент из дома вытянуть. Как бедняга пыхтел рассказывая что в реакте это не нужно.

Окей, я и сам не пойду на проект где нет более-менее известного фреймворка. И если мне нужно будет по быстрому собрать MVP, то я буду использовать реакт или вью но я достаточно хорошо могу понять КАК та или иная тулза решает проблему и предпочту работать с людьми которые тоже это понимают. Тогда внезапно оказывается, что ты не занимаешь компоговкой нескольких десятков плагинов/либ и поддержкой их хороших отношений, а педалишь работающий код.

Тенденция хоть и пугающая, но вполне понятная, не новая и ничего с этим не поделать. Кстати, это не исключительно украинский «тренд»

Кстати, это не исключительно украинский «тренд»

Ага. Аутсорс и дедлайн не украинцы же придумали. Да и больше всего текста во славу этой тенденции от англоязычных «гуру».

Якщо проект маленький і не буде рости то можна, але jQuery в пізньому 2018 точно зайвий.

почему? всяко $(’#id’) лучше чем document.getElementById(’id’)

window.$ = (selector) => Array.from(document.querySelectorAll(selector)); ??

document.querySelectorAll возвращает не массив, а NodeList, итерабельный объект, у которого из методов «массива» можно использовать только .forEach, и то не во всех браузерах. Array.from() делает его массивом. Так же можно использовать типа [...document.querySelectorAll]

NodeList, итерабельный объект, у которого из методов «массива» можно использовать только .forEach,

всегда интересовало почему дум интерфейс такой черезжопный

потому что NodeList это вообще-то прокси с итератором, а не массив. это означает, например, возможность иметь живые коллекции. думаю, querySelectorAll возвращает именно NodeList вместо массива для совместимости с другими механизмами прохода по дереву. Например, .childNodes

І так потроху свій Jquery написати. Clever!

ну жаловались на отсутствие сахара я и показал как трудно его сделать

круто
осталось запилить весь оставшийся сахар и сделать свою жиквери

Так не надо, он вам скорее всего не нужен

хз, может быть
я тут еще в es5 застрял :( со всем сопутствующим

Уже не помню где видел\читал про игру, на англ яз было — участник загадывает слово, если есть фреемверк с таким именем то он пьет алкоголь и так дальше по кругу участников.
Можно пробовать даже ругательства или пошлые слова — работает!

Лол, фпеймворки дозволяють пришвидшити розробку, збирати докупи всі веб-вишеньки і робити великий торт. А так, то код увесь всеріно пишемо в es6 typescript, тільки фреймворк пришвидшує розробку, дозволяє юзати новинки (вбудовані транспілятори) і тд. І взагалі питання саме дивакувате. То то саме, шо запитати, а нашо юзати авто, якшо можна пішки йти...:)

Єдине що пришвидшують фреймворки — ступінь зростання відвідуваності стаковерфлоу. А ось швидкість вирішення завдань опускається в рази

Можете примерчик уменьшения быстроты выполнения задач, используя фреймворк?

alert("Hello World");

Без фреймворків, написано за секунду.

Классные у вас задачи на проекте

Ні. Ще у мене на проекті використовується prompt. Живу без фреймворків і не тужу!

Пустил жалобную слезу от зависти

А вы попробуйте написать, например тасклист (с отдельным шаблоном задачи) на реакте и на ес6. Незабудьте учесть установку и настройку фреймворка. А затем сравните вес приложения и время на написание... Конечно это работает, если у вас достаточный скилл в ес6.

Сейчас все топ-3 фрейворка предлагают базовую, подходящую для простых проектов настройку с помощью одной команды в терминале. Установка и настройка фреймворка под небольшой проект это пара секунд, зависящих от мощности компа и скорости интернета + скорость вашей печати

Которая будет оверхэднута более, чем полностью. А теперь внимание: для начала проекта на ес6 вам НЕНУЖНО ВВОДИТЬ КОМАНД и тянуть миллион зависимостей. Ну и как бы итоговый проект на чистой экме будет чище, быстрее, легче. Просто попробуйте.

А чой это вы на вопрос о быстроте разработке пишете какие угодно другие аргументы, кроме тех, что касаются вопроса?)

Давайте опустим дискуссию по остальным параметрам. Вы сказали, что быстрее на ваниле, что долго устанавливать и настраивать фреймворк. Я говорю, что установка и настройка — это вопрос пары строчек в терминале.

В чём скорость разработки «в разы» быстрее? Ответ только об этом, пожалуйста.

для начала проекта на ес6 вам НЕНУЖНО ВВОДИТЬ КОМАНД

ну, как минимум, вам нужно создать несколько разных файлов, инициализировать гит. Вот вам и команды.
хз, насколько у вас важна поддержка старых браузеров, но если важна, то какой-то конвертер современного ES вам тоже понадобится — бац, и dev-зависимость, для которой нужно ещё и npm инициализировать.

В чём скорость разработки «в разы» быстрее? Ответ только об этом, пожалуйста.

Как миниму потому что нужно использовать левые, не нативные методы.
Как я предлагал:

попробуйте написать, например тасклист (с отдельным шаблоном задачи) на реакте и на ес6

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

Как миниму потому что нужно использовать левые, не нативные методы.

лолчто?) как использование ненативных методов замедляет разработку? ТИпа если их не знать?

А теперь попробуйте переиспользовать тасклист, и так, чтобы это было понятно и тасклист можно было как-то усовершенствовать, подстраивать под себя.
Чтобы это было читаемо, скорее всего придется использовать WebComponents — технологию, которая еще в целом не совсем созрела, не поддерживается очень многими браузерами, инфу найти невероятно сложно, нужно использовать полифиллы, и то не факт что везде заведется. При этом вы будете писать, по сути, тот же код, что и в реакте, но немножко посложнее, и некоторые важные базовые вещи будете писать сами.
Можно конечно же это писать на чистом джаваскрипте, но это очень быстро превращается в кашу. Если у вас есть готовый проект, который вы написали на чистом джс-е, и в нем у вас нет таких вещей как копипаста, все компоненты максимально сильно разбиваются на еще более мелкие реюзабельные компоненты, и при этом сохраняется гибкость, расширяемость того или иного компонента — скиньте мне линк, будет интересно почитать

а на кой хер вы для таск листа фреймворк используете???

кейс не валиден

Вопрос зачем. Посмотрите на Vue это фреймворк с которым хочется работать. Все начиная от доки и собсно работы приятно и интуитивно. Плюс тонны полезных плагинов (awesome vue). Опционально vue router и vuex для данных. Если хочется быть ближе к es6 можно заюзать vue custom elements wrapper.

Я работал с реактом, писал проекты на ангуле. Я готов официально заявить: ES6 покрывает абсолютно весь скоуп задач который, ЯКОБЫ решают фреймворки.
Если вам, конечно, нужно решать задачи, а не ходить по модным тусовкам где модники на гироскутерах ласкают друг-другу ЧСВ.
В мейнстрим тусовке судя по всему никто и не поймет о каком это ES6/ES8 вы говорите. Что за фреймворки такие? Есть модуль для вебпак?

Написав проект на ES6 я точно знаю что:
1. Он нативен и любой человек мало-мальски знающий жабаскрипт разберется
2. Он не аутдейтнится через ГОД как вонючий... кхм. [insert framework here]. А будет жить минимум 10 лет
3. Он быстрый. Никакого оверхеда, загрузок, злогребучих
4. Разрабатывать на ES6 (внимание!) гораздо быстрее чем на говнофреймворках. No, really я написал и отдал рабочую альфу (админка с фичами) на экме на 1 месяц.
На ангуларе мне понадобилось 3(!) для приблизительно такого же проекта.

Роутер — если правильно спроектировать приложуху, то роутер можно накатать в пару строчек.
Ад коллбеков — Господа. просто научитесь работать с fetch(), Promise, Promisa.all.
Темплейты — это отдельная тема и то, что делает реакт — не вызывает никаких эмоций кроме фейспалма. css в жабаскрипте? серьезно?
Вот вам загрузчик:

async function load(url) {
    let data = await (await (fetch(url)
        .then(res => {
            return res.text();
        })
        .catch(err => {
            console.log('Error: ', err);
        })
    ))
    return data
};

async function include(link, input) {
    let data = await (await (load(`${link}.html`)
        .then(data => {
            var newData = input;
            tpl = '`' + data + '`';
            return eval(tpl);
        })
    ));
    return data
};
Вот вам темплейт в файле list.html
${(() => {
    var lol = '';
    newData.blabla.map(item => {
        lol += `
        <li>
        <a href="#blabla,${item.id}" title="${item.name}">
            <span class="id">${item.id}</span>
        </a>
        </li>
        `
    })
    return lol
})()}

Достаточно научиться работать со сраными кавычками [``]. И самое главное никакиж .jsx, никаких pug’ов, интерпритаторов и прочего мусора. Чистый js и html.

Я переписал абсолютно все свои проекты на экме, теперь заказчик даже не заикается о фреймворках.
Чаще всего на фреймворках пишет фронтендщик, который ничего не изучал кроме этих самых фреймворков или программисты на копипасте со стаковерфлоу.
Они же внедряют какю-то дичь с периодичностью раз в год (для того чтобы переписывать проекты и небыть уволенными).

Я работал с реактом, писал проекты на ангуле. Я готов официально заявить: ES6 покрывает абсолютно весь скоуп задач который, ЯКОБЫ решают фреймворки.

то есть ЕС6 дает какие-то возможности для создания компонентой модели? (не, ее можно самому запилить но это уже будет ваш кастомный фреймворк)

А вы попробуйте объяснить самому себе что такое компонентная модель и какие задачи она решает. А затем почитайте про ес6 классы. Классическое программирование нагнет вашу гравицыпу с миллионом обвязок и по скорости разработки и по удобочитаемости. Ненадо писать фреймворков. Нужно решать ЗАДАЧИ. Один проект — это скоуп задач. И решать их используя нативные инструменты гораздо удобнее, быстрее и надежнее. Никакая мифическая «компонентная модель» не даст вам того что даст элементарное ооп.

я прекрасно знаю что такое компонентая модель и для чего она нужна, и знаком с тем чем являются ес6 классы

это если у вас лендинг пейдж — тогда конечно компонентная модель создаст излишнюю сложность, и оно вам не надо

если вы делает приложение — то она вам понадобится т.к. вам понадобится логическая абстракция

Ок, говоря вашим языком: ES6 это фреймворк обладающий всеми фичами любого другого но нетребующий доп. библиотек. Просто попробуйте сами написать приложение (например задачник) на чистом ес6. Увидите сами насколько это удобнее и быстрее. А любой фронтенд
фреймворк как-бы в итоге приводит к логическим абстракциям сам являясь таковой.

Ок, говоря вашим языком: ES6 это фреймворк обладающий всеми фичами любого другого но нетребующий доп. библиотек.

нет. ES6 — это стандарт языка. есть понятия стандартная библиотека (понятие «класс» в нее не входит). ES6 — внес — Promise, Set, Map, WeakMap, Symbol + новые методы в Array, String, + функции доступные в Object (может еще что о чем забыл).

ничего из этого не создает фреймворк.

АПДЕЙТ: только Promise можно отнести к абстракциям

сударь, да у вас самоцель работать именно с ФРЕЙМВОРКОМ или создавать его. Это болезнь всей мейнстрим тусовки. «Мне не нужно решать задачи, мне нужен ФРЕЙМВОООРК». Так что полный вперед.

Так собственно для этого и нужны фреймворки — чтобы решать задачи а не играться в создание минимально необходимой структуры.

А на фремворке вы не создаете структуру?. Вы знакомы с проектированием приложения? Я говорю именно о том, что ES6 уже имеет все фичи и создание как вы говорите «инфраструктуры» — это зачастую пару строчек (пример выше).
Я предложил вам попробовать написать самому небольшую аппликуху, а затем ее же на реакте или ангуле. Я предлагаю, потому что сам прошел фреймворки.
Но, как говориться, не спорь с фанатиком. Религия непозволяет писать грамотно без гравицап — тусовка непоймет)

ну фанатик тут явно не я :)))

я писал приложения даже на ES3, и с тех пор, по сути, ничего не изменилось (синтаксический сахар и утилитные методы я не считаю за изменения), так что можешь мне не рассказывать что обладаешь каким-то особенным опытом.

есть понятие дизайн системы — на нее фреймворки в реальности не влияют.

фреймворк реашет базовые проблемы с которым сталкивается обычно разработчик.

То что было приведено выше, далеко не инфраструктура.
Вот представьте что перед вами стоит задача написать SoundCloud, вам предстоит решить ряд серъезных вещей, включая правильное кеширование, работа с HTML5 историей, навигация, и это все динамически.
Фреймворки и библиотеки позволят ускорить написание подобной системы, предоставляя готовые решения для ключевых проблем.
Вы конечно можете написать все сами с нуля, но для этого вам придется создать собственный фреймворк и потратить намного больше времени.

. Нужно решать ЗАДАЧИ. Один проект — это скоуп задач. И решать их используя нативные инструменты гораздо удобнее, быстрее и надежнее.

Вот насчёт «быстрее» сильно сомневаюсь. Говорю как человек, максимально далёкий от всяких хипстерских тусовок и похвальбы использованием тех или иных сторонних решений. Фреймворки и библиотеки тем и полезны, что там множество типовых задач уже решены за тебя. Вместе с тем, о чём бы я действительно дважды задумывался — стоит ли применять так называемые opinionated фреймворки, которые загоняют разработчика в жёсткие рамки картины мира их авторов. Иногда это может быть и благом, но порой может иметь смысл пойти по пути linux way и собрать решение из большего количества компонентов, каждый из которых решает строго свою задачу.

стоит ли применять так называемые opinionated фреймворки

если у вас команда из солнечной Индии — то чем сильнее рамки, тем лучше

кастомный фреймворк

Це зараз так називається використання парочки шаблонів проектування?

рекоммендую ознакомится чем является фреймворк и для чего он нужен

А давно это EcmaScript и JS-фреймворк взаимоисключающие вещи?

>написал альфу админки за 1 месяц
npm install —save ngx-admin
а я за 30 секунд.
P.S. Если не умеешь ездить на велосипедах, то это не значит, что они медленные.

Могу поспорить, что реализация механизма виртуальных деревьев потребует от Вас от полугода до года. Или так и не сможете в приемлемую производительность Вашего

$(<li>)
Вот вам загрузчик

Ну а на ES5 мы бы XMLHttpRequest заюзали- не намного больше кода, а еще раньше вообще костыли с script/iframe, где предел? Все ровно тот код оформлен в функцию для переиспользования, так же само если бы она была вынесена в third party библиотеку, которая при предоставлении определенного уровня абстракции будет называться фреймворком... То бишь суть не с/без фреймворка, а в адекватном выборе его под задачу.

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

Разрабатывать на ES6 (внимание!) гораздо быстрее чем на говнофреймворках. No, really я написал и отдал рабочую альфу (админка с фичами) на экме на 1 месяц.

Админки бывают разные, требования могут менятся быстро, сроки ограничены, то что подходит для простых задач не подходит для сложных.

PS: Я сам тот еще любитель «своих велосипедов», но это когда время есть ))

Справедливости ради, все полезные инструменты, это чей-то «свой велосипед»

Використовувати eval і казати, що код буде швидким доволі спорне рішення. Так само як використовувати template strings для створення повноформатних темплейтів, оскільки перший же невалідний об’єкт навидає undefined і null на сторінку.
Насправді, коли діло доходить далі альфи, як вже казали в треді, то діло зводиться до свого міні фреймоврку. І вот коли ти влазиш в ті міні-фреймворки, то починаєш розуміти, що то не погані програмісти розробляли фреймворки, а це ти не бачив багато use-case’ів.

Чем 2018 год отличается? В es6 никаких возможностей, что покрывают архитектурные задачи библиотек и фреймворков не добавляли, а значит все ровно придется строить минимальную архитектуру и опять выйдет минимум бекбон (mv* + events observer+router) + UI библиотека.
Если аутсорс, кто будет с этим заморачиватся и, главное, зачем? Да можно просто взять фреймворк по проще, но не писать же все с нуля? Если ради легковесности и производительности кода, то с таким не особо заморачиваются даже продуктовые компании, которые пилят свой код годами. Вон смотрел в одной там 130 запросов с фронта летят, пару метров кода, тьма ресурсов и дальше по списку, и да- в недрах есть реакт, хотя так и не понял какую часть они реактом рендерят. А страница с пары форм и графика.
Для всяких реактов и прочих есть готовые сборки, склонировал и вперед писать шаблончики, выходит якобы занимаешься как раз тем что нужно, да и все ровно никто не разбирается как там интегрируются компоненты сборки между собой, в принципе не надо знать что там под капотом и как эта «магия» работает. Проблемы могут начаться с нестандартными задачами.

Поднакину, для фана, вот депенденси из пакаджа моего проекта который мне пилят, 10-15% там легаси мусора который нужно убрать, но не суть — я как прикину что мне бы пришлось оплачивать разработку всего того функционала, который достаточно быстро был вытащен напрямую из фреймворков... да ну нафиг, это могут себе позволить либо богатые компании — которые в итоге просто создают N+1 фреймворк, как оно и было с текущими, либо энтузиасты которые просто любят основательно писать проект ради удовольствия

„dependencies”: {
„@nivo/bar”: „^0.33.0”,
„@nivo/pie”: „^0.33.0”,
„arui-feather”: „^12.6.1”,
„axios”: „^0.18.0”,
„bcrypt”: „^1.0.3”,
„bluebird”: „^3.5.1”,
„body-parser”: „^1.18.2”,
„concurrently”: „^3.5.1”,
„cookie-parser”: „^1.4.3”,
„css-loader”: „^0.28.8”,
„express”: „^4.16.3”,
„express-ipn”: „^1.0.3”,
„express-session”: „^1.15.6”,
„extract-text-webpack-plugin”: „^3.0.2”,
„file-loader”: „^1.1.11”,
„forever”: „^0.15.3”,
„globalize”: „^1.3.0”,
„html-react-parser”: „0.0.4”,
„html-webpack-plugin”: „^3.1.0”,
„immutable”: „^3.8.2”,
„jquery”: „^3.2.1”,
„material-ui”: „^0.20.1”,
„materialize-css”: „^0.100.2”,
„moment”: „^2.22.1”,
„mongoose”: „^4.13.5”,
„node-sass”: „^4.7.2”,
„nodemailer”: „^4.4.0”,
„nodemailer-smtp-transport”: „^2.7.4”,
„nodemon”: „^1.17.2”,
„passport”: „^0.4.0”,
„passport-local”: „^1.0.0”,
„password-hash”: „^1.2.2”,
„paypal-ipn”: „^3.0.0”,
„paypal-rest-sdk”: „^1.8.1”,
„pm2”: „^2.10.4”,
„querystring”: „^0.2.0”,
„react”: „^16.3.2”,
„react-autosuggest”: „^9.3.4”,
„react-beautiful-dnd”: „^2.5.0”,
„react-big-calendar”: „^0.19.1”,
„react-burger-menu”: „^2.4.4”,
„react-d3-tree”: „^1.10.6”,
„react-dnd”: „^2.5.4”,
„react-dnd-html5-backend”: „^2.5.4”,
„react-dom”: „^16.2.0”,
„react-flexbox-grid”: „^2.1.0”,
„react-notification”: „^6.8.2”,
„react-paypal-express-checkout”: „^1.0.4”,
„react-rangeslider”: „^2.2.0”,
„react-redux”: „^5.0.7”,
„react-redux-toastr”: „^7.2.3”,
„react-responsive-carousel”: „^3.1.37”,
„react-router-dom”: „^4.2.2”,
„react-share”: „^2.1.1”,
„react-spinners”: „^0.3.2”,
„react-svg”: „^2.2.10”,
„react-toastr”: „^3.0.0”,
„recharts”: „^1.0.0-beta.10”,
„redux”: „^3.7.2”,
„redux-burger-menu”: „^0.2.7”,
„redux-thunk”: „^2.2.0”,
„request”: „^2.87.0”,
„resolve-url-loader”: „^2.3.0”,
„sass-loader”: „^6.0.7”,
„sendmail”: „^1.2.0”,
„shufflejs”: „^5.0.3”,
„style-loader”: „^0.19.1”,
„svg-inline-loader”: „^0.8.0”,
„toastr”: „^2.1.2”,
„uglifyjs-webpack-plugin”: „^1.2.4”,
„url-loader”: „^1.0.1”,
„uuid”: „^3.2.1”,
„uuid-v4”: „^0.1.0”,
„vis”: „^4.21.0”

интерфейс к макдональдсу ? :-)

Редакс сообщество решило свою бургерную открыть Redux Burgers, вот готовят платформу для захвата рынка!

Хотелось бы поюзать это замечательное приложение

бггг ожидайте, работаем над мвп

вот если интересно мой бажный пи о си, еще без ML но с NLP, и с маркетинговой лычкой AI =D
youtu.be/n-atcemXuXQ

Посмотрел. Не понял что оно делает, и зачем так много джаваскриптов

Помогає в жизні оберати тьощу. А тим хто вже має помогає жити з тьощою.

ОК, сколькими бы ты пакаджами обошелся на мерн апликухе, и какими?

:)
Не знаю.
Даже при беглом просмотре видно, что тут винегрет из разных пакаджей... Например 2 бургер-меню.
Сколько это все вместе весит?

Я ж написал что 15% легаси не зачищено ставились или для сравнения или уже не актуально

10-15% там легаси мусора который нужно убрать
Не знаю

Ну и ладно, закрываем тему)

Тут ещё вопрос в том, насколько быстро ваше приложение превратится в адище из коллбеков. Имхо лучше изначально взять какой-нить условный реакт, на нем тоже можно очень быстро налабать.

Проміси в ES6 з коробки. Реакт це всього навсього шаблонізатор, обрісший екосистемою сторонніх і не дуже костилів, і до колбек хела ніякого відношення не має

ну ок, не будет callback hell, буид promisehell вместо него)

лепят порой «авось оно поможет и код заработает» так же как до этого лепили колбеки или вкладывали без конца зены. Штука безумно крутая, как и генераторы, но говнокодинг никто не отменял и с ними. Ессно фигней страдать можно и на ангулярах, но в некоторых случаях фреймворки/библиотеки позволяют срезать углы, оперативно отлавливать ошибки. Пилить на нативке что-нибудь большое — заняться примерно тем же, что и делают за тебя фраймвoрки. Только кастомно.

лепят порой «авось оно поможет и код заработает» так же как до этого лепили колбеки или вкладывали без конца зены.

Может, тогда проблема не в коллбэках?

Промисы они конечно из коробки, но jquery поощряет код вида .then(() => { .then(() => { .then() , увы. Энивей, нафига вам именно jquery?

Может
returnPromise()
.then(() => { ... })
.then(() => { ... })

Может, но в jquery так не принято :D

img-fotki.yandex.ru/...​0_facfe_46f0772c_orig.jpg
PS: Накидать MVP на одном из популярных фреймворков(React/Angular/Vue) гораздо быстрее чем делать все руками, но нужно будет инвестировать немного времени в изучение этого фреймворка да.
PPS: Порождая самописные либы (а именно это и будет происходить при написании «веб аплікух без 100500 фреймворків/бібліотек») сильно проседает карма.

Попробуй hyperapp, ручной фреймворк 400 LoC

Кстати, вот такое введите в консоли браузера и посмейтесь с результата )))) [6,2,-2,-7].sort()

прікольно...
хоча, якщо вдуматись — жопа же

Да, вызывать сортировку без функции сравнения — жопа, и вправду )

якщо подивитесь доку до команди sort — побачите, що всі елементи спочатку приводяться до типу string, а потім вже порівнюються.

Дарма так публічно.
Кращого питання для вичісування об кандидатів ЧСВ годі й шукати )

в консоли браузера

это вообще что?

пкнопка F12 на клавиатуре, в хроме, и там вкладка Console, там копипастишь эту строку и жмешь Enter — все, ты фронт энд девелопер! :-)

кстати скопипастить не даёт говорит вы хотите украсть мою identity... х.з. что это значит...

введи руками )) там не долго

уже )) я умею кодить руками не только копипаст ща пойду резюме писать ))

все ты фронт энд девелопер! :-)

ага... а «фронд энд девелопер» и «веб девелопер» это разные вещи? т.е. я «фронт энд» а не «веб» так?

Отличная пятница сегодня столько нового день прожит не зря! (кстати а почему нет)

а «фронд энд девелопер» и «веб девелопер» это разные вещи?

В общем-то да.

Нажмите F12 в любом браузере и откроется дивный новый мир (если вопрос был всерьез)

о я нашёл! я теперь веб девелопер!!!

Array(4) [ −2, −7, 2, 6 ]

— а что должно было вывести? в чём фишка?

Немного странно, что сортирует по возрастанию и −2 меньше чем −7, не? :)

читай стандарт — стандартный sort преобразовывает все элементу к строке и потом сравнивает

Это я уже понял, мой комментарий это был корявый ответ на вопрос выше :)
Кстати, я с этим раньше не сталкивался, доу образовательный, блин

Насколько мне известно, js вообще все к строке приводит, это его особенность. Одна из особенностей. Но могу и ошибаться...

Что значит «всё к строке приводит»? О_о

let num = 3 * ’3′
let num = 2 — ’1′
let num = +’3′

Спасибо, буду знать. В любом случае я использую parseInt(). Хотя интересная особенность конечно.

язык со слабой типизацией, как и php

Угу, только выполняется по-разному sandbox.onlinephpfunctions.com/...​c83f2f9a555d448cec5e1ee7a

По разному приведение типов работает.

Никто ж и не говорит что будет одинаково. А о том что оно скрестит бульдогов с носорогами и выдаст «корректный» по своим правилам результат.

Тут дело даже не в типизации, а в том что плюс по разному определён для строк и чисел. А строки идут по дефолту. Остальные операции опеределены только для чисел и потому преобразуют всё к числам, даже строки.

Ctrl+Shift+I и набрать
’2′ - ’1′

Вот как раз из-за типизации (слабой) оно и работает, а не падает как в питоне и руби. То что срабатывает переопределение операции — это уже следствие.

Тут видимо проблема в том, что в js плюс это еще и оператор конкатенации.

о! чёрт! не заметил. ЗачОт! Спасибо!

фишка в том что человек ожидает сравнение на основе реального значение а представление в виде string

я еще нету в стандарте точности то ли stable sort, то ли unstable sort

потому и запилили lodash

И после вот этих каментов хахаха ктото думает что на Доу сидят программисты?
Да фик там, эти люди даже документашку ниасилили. developer.mozilla.org/...​Global_Objects/Array/sort
Если функция сравнения compareFunction не предоставляется, элементы сортируются путём преобразования их в строки и сравнения строк в порядке следования кодовых точек Unicode. Например, слово «Вишня» идёт перед словом «бананы». При числовой сортировке, 9 идёт перед 80, но поскольку числа преобразуются в строки, то «80» идёт перед «9» в соответствии с порядком в Unicode.

Есть поведение, которое разработчик интуитивно ожидает, отсюда и столько какашек в сторону JS.

И после вот этих каментов хахаха ктото думает что на Доу сидят программисты?

Да, потому что программисты умеют отличать хороший API от плохого.

Потому что правильно надо вот так.
[6,2,-2,-7].sort((a, b) => a - b)

Гениально! У меня сработало как надо. Прямо никуда без ада callback’ов

Ну вот с одной стороны поорать вроде и есть с чего. А с другой — в MDN написано:

compareFunction OptionalSpecifies a function that defines the sort order. If omitted, the array is sorted according to each character’s Unicode code point value, according to the string conversion of each element.

А то что кто-то ожидал другого результата — так доки читать надо ))

вполне себе можно.
Один мой знакомый ©
разработал для себя несколько saas проектов на TS c небольшим вкраплением jquery- и живёт радуется себе.
Но вот если идти на дядю работать- то ни-ни-ни. Любой чих через 100-500 фреймворков.

А можно поинтересоваться, зачем jquery?

знакомый говорит- jquery потому что он уже знаком был с ним на момент создания проектов

т.е. querySelector он неасилил?

Чи можливо в пізньому 2018му році при розробці малих і середніх веб аплікух обійтись без 100500 фреймворків/бібліотек

Нет, на фронтенд тусовках тебя засмеют.

А вообще сходи сюда за относительно чистым JS www.polymer-project.org.

Незнаю, когда оно будет внутри из коробки, но последний раз когда я ее смотрел, этот чудо-«полифил» весил как пару Ангуляров.

Только что проверил полифилы весят 96 KB. Сжатые — 29 KB. Вот недавно мелькала новость, что Edge начал разрабатывать поддержку веб-компонент.

В моем пет-проекте лендинг завесил 356 KB в хроме, едж какую-то чушь показал, но пусть еще + 96 KB. Это без компрессии. А вообще где-то смотрел, что голая либа сжатая то ли 7 то ли 15 KB.

Сам ангулар раза в два тяжелее, наверное.

Дякую тоби боже шо я не фронт-энд девелопер :-)

У меня вопрос, в каком языке не так и все пишут на нативном?
В питоне в котором фреймворков и либ столько что уже в пакеты пакуют?)
Чего то пригорает у всех только по поводу джса

— Бекенд рішення зазвичай не породжують для клієнта стільки сміття і сайд ефектів як фронтендовий джаваскрипт
— На багатьох бекенд платформах в заложностях починає зароджуватись хаос вже на старті простого проекту?
— IMHO більшість фронтенд рішень не такі вже складні, не потребують замороченої архітектури/структури і досить легко можна побудувати на базі стандатрних можливостей ES6/HTML5/CSS3
(про великі проекти з великою кількістю різношерстого народу в тімі мова не йде)
— good javascript — not written javascript

Чего то пригорает у всех только по поводу джса

А разгадка на самом деле проста: ДЖс — это язык-ущерб, язык-калека, язык-однопоточник, язык-микроцефал.

это уже не по теме, мы про фреймворки которые есть в изобилии во всех язхыках а не про градацию языков

Если конкретно о фреймворках, то пригорает только потому, что их авторы — это, как правило, аттеншнвхоры, не знающие, как заявить о себе миру. Они лелеют надежду, что их фреймворк вдруг выстрелит, чтобы потом как-нибудь на собеседовании на вопрос «А знаете ли вы %framework_name%?» иметь возможность ответить «ДА Я ЕГО НАПИСАЛ!!!»

Легче дождаться пока webasm не убьёт все это безумное буйство мысли в виде тысяч фреймровков на js.

Слышал звон, да не знаю, где он

А шо не так? Вебасемблі дозволить пилити фронт на будь чому. Повна свобода. А там дивиш го прийде і порядок наведе © Правда тоді прийдеться всім бомбити від го. Ох щит...

с DOM будете все равно через js разговаривать, внимательнее стандарт почитайте

Це лише тимчасово. Зробити прямий доступ до DOM було в планах ще пів року назад коли я дивився. А вам принципово щоб інші були змушені на js писати?)

нет конечно) вебассембли конечно круто, но лучше бы джс довели до ума и быстрее фичи доставляли в браузер.

Краще б накінець доробили васм і дали нормальну конкуренцію на фронті як це є на беку. А не годували усіх одним сортом кхм.

верстать тоже на go будете?

хы.. ну порт Qt на wasm я уже где-то видел, и форму на оном сделанную...

Боже у меня аж браузер подвис))) Да еще и вырвиглазное шо ппц)) Короче вместо того чтобы превратить джс в «нормальный» язык, пишут кучу оверхеда на оверхед)) Ок)

Навіщо стільки перетворювати джс в щось, коли можна просто дати свободу вибору мови і хай все само по собі живе і розвивається? Ця монополія в вебі дістає. Напевно треба подякувати Мозіла корпорейшон які вмудряються у себе навіть на вебасемблі пейджі вести агресивну піар кампанію джса і те як васм ні ні не потіснить жс. Мені дуже цікаво яким чином на цих всіх мовах і фреймворках рублять бабос, але судячи з того що баталії йдуть серйозні і кожен намагається свою технологію пропихнути, то суми там нормальні. А девелопери для цих компаній це клієнти, чи то агенти які клієнтам впарюють ці технології.

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

Тому, чому і не можна щоб на ринку була одна компанія — монополія. Монополія це абсолютне зло. Потім не існує єдиного вірного підходу, не існує срібної кулі. Кожна мова має свої плюси, як і мінуси. Так і фреймворки. І лише вільний ринок може, ну, хоч трохи адекватно все розставити. Кращого не придумали ще щоб всі були задоволені.

Как быть с обратной совместимостью?

Для чого коли в браузері раниться і джс і вебасемблі? Кожен ап девелопер сам буде вирішувати що юзати. А на початку будуть юзати оба, доки екосистема конкурентів не виросте. От і рішення сумісності.

Зачем делать из браузера ОС с приложениями?

Для того що веб ап це вже давно не сайт, а додаток. До речі цікаво буде, якщо все таки зявляться хороші уі фреймворки під васм, мобайл розробка практично зникне, як зникла десктоп після появи вебу?

Почему любители других языков захотели делать фронт?(это скорее риторичекси)

Тому що фронт != JS. Фронт це програмування інтерфейсів для юзвіря. І він не має бути завязаний на одній мові чи фреймворку. І тут кожен розробник має мати вибір який інструмент йому оберати, а не користуватися тим що надано конторою(мозілою). Писати на тому на чому подобається є набагато продуктивніше. А примус це контрпродуктивно і викликає лише вигорання девів(привіт пхп).

которых кстатит возрастет если количество языков будет куча

Ну на беку люди якось живуть. Під кожну мову буде свій головний(лідируючий) фреймворк. А коли зявиться кращий то він буде замінений кращим. Все природньо.

Главное чтобы потом в веб асембли не сделали супер веб асембли чтобы можно было запускать браузер, а в нем приложения на веб асембли)
Надеюсь все это выростет без того оверхеда что есть и не придется крутить кучу llvm чтобы почитать очередную статейку на dou

Гірше вже не буде. Джсники довели вже фронт до стадії метастаз мільйонів депенденсей)) А як все романтично починалося: програмуємо одразу в браузері без компіляцій і іншої туфти11. Ну це все логічний розвиток коли скрипт переростає в повноцінний апп. Тут або мільйон депенденсей, або жирний фреймворк з усім на борту.

Пхп от теж продовжує трансформовуватися в джаву, крива едішн)) Ору з цього

Тут соглашусь) один leftpad чего стоит) подключишь что то а в нод мудулс уже 2к пакетов всякой херни)

Главное не подумайте что я против, я не только на js пишу и знаю о его многочисленных проблемах. Просто мне не нравится то как их сейчас решают)

Всі ми маємо свого любимчика на якому хочемо писати код) Я не проти джс. Я проти монополії джс. Це те як в фрілансі на беку сидить пхп на троні, і навіть ті кого нудить від пиха змушені на ньому писати. Хоча на апворку вибір ширший, і вже якось потроху зявляється вибір окрім пхп і джс. Навіть новоспечений нет кор вже має вакансії, що теоретично можна знайти собі роботу(в даний момент я постійного клієнта переводжу з ларавель на асп.нет кор).

П.С. а так важлива річ що більшість мов і фреймворків реалізують схожі ідеї і між ними не так важко перескакувати. Той же MVC. Правда імхо це якась примітивна концепція, бо є набагато більше компонентів ніж прості моделі, моделі розбиваються на сервіси, хелпери і т.д.

Я проти монополії джс

А что вы скажите, если WebAssembly взлетит? Монополия МС вас устроит больше?

А де там монополія МС? Вебасемблі це договорняк між всіма головними гравцями в вебі — Гугл, Мозіла, МС, Епл. По суті усі дядьки що володіють браузерами зібралися і вирішили почати вести чесну гру. Якби вони не домовилися то ніякого вебасемблі тут би і не було. Проблема не так в технологіях як в бажанні попилу ринку.

бажанні попилу ринку

бажанні попилу ринку MC. Я поправил :)

Посмотрите кто был инициатором, и почему первый язык который стали поддерживать, стал именно язык от МС. И да, сама дока как-бэ намекает webassembly.org/...​started/developers-guide кто и зачем. Очень надеюсь что очередную подделку все вскоре просто забудут. Нам хватило Secure boot. Пускай они лесом идут с такими «инновациями».

Не треба бачити зраду там де її нема. WA це не про МС, це про пісочницю в якій можна ранити все що душі забажається на близькій до нативної швидкості. Лібералізація вебу)

Если это так, я только за. Время покажет. Пока что я вижу попытку монополизации со стороны МС. И да, насколько я понял в итоге это компилится в угадайте что? Вы угадали, в javascript...

насколько я понял в итоге это компилится в угадайте что? Вы угадали, в javascript...

Wrong. Компілиться в байт-код: en.wikipedia.org/...​ebAssembly#Representation

JS тут взагалі відношення не має ніякого і не є необхідним в Webassembly програмі. Крім може маніпуляції з DOM, якщо пряму з Webassembly ще не запилили.

Пока что я вижу попытку монополизации со стороны МС

Це неможливе, так як участь беруть усі компанії-власники браузерів. Там без компромісу не могло обійтися.

Компілиться в байт-код

Я что-то пропустил? Не припомню чтобы браузеры умели C++ парсить...

JS тут взагалі відношення не має ніякого і не є необхідним в Webassembly програмі

blog.logrocket.com/...​-how-and-why-559b7f96cd71

„What WebAssembly enables you to do is to take things like C, C++ or Rust code and compile it into what is called a WebAssembly module. You can load that into your web application and call it from JavaScript.”

„It’s not a replacement for JavaScript, it works alongside JavaScript.”

„You need HTML and JS files because WebAssembly doesn’t have direct access to any platform APIs — the DOM, WebGL, WebAudio etc.”

Очередная ненужная прослойка. Кому-то пора завязывать с абстракциями...

„Think about the cases where you need to use software outside of the browser: video games, video editing, 3D rendering, or music production. These applications do a lot of calculations and require a high degree of performance.”

Нужен он как машине 5 колесо в 99% задач. Очередная попытка перенести все вычисления на клиент(фейспалм)

Це неможливе, так як участь беруть усі компанії-власники браузерів. Там без компромісу не могло обійтися.

Ну конечно. У МС просто подгорает немного. Они даже браузер новый выпустили, а веб для них по-прежнему непостижим. Вот они и бесятся ;)

Не припомню чтобы браузеры умели C++ парсить...

Для цього і зроблений WA. Щоб компілити С++ і ранити в браузері.

You can load that into your web application and call it from JavaScript.«

Тут мається на увазі що не обовязково увесь ап робити на іншій мові з Webassembly, а що можна ці компоненти запускати з JS як звичайні модулі.

«It’s not a replacement for JavaScript, it works alongside JavaScript.»

Мозіличі в це вірять. А як буде насправді подивимося. Вже зявляються фреймворки для реплейсменту джс і програмуванння і фронту і беку на одній мові, наприклад з використанням C#. Що точно це всілякі ігри будуть без використання JS, бо в ньому не буде вже сенсу.

«You need HTML and JS files because WebAssembly doesn’t have direct access to any platform APIs — the DOM, WebGL, WebAudio etc.»

Це поки що, так як команда WA спочатку працює над кор речами. АПІшки на підході.

webassembly.org/docs/future-features

А конкретно оця:

github.com/...​sembly/design/issues/1079

reference DOM and other Web API objects directly from WebAssembly code;
call Web APIs (passing primitives or DOM/GC/Web API objects) directly from WebAssembly without calling through JavaScript;

=)

програмуванння і фронту і беку на одній мові, наприклад з використанням C#

Т.е. фронт и бэк на js это буэ, а фронт и бэк на C# это норм? Ну ок. Спорить не буду. На вкус и цвет...

без використання JS, бо в ньому не буде вже сенсу.

Satya Nadella перелогиньтесь пожалуйста :)

Вот вам еще одна цитата с reddit www.reddit.com/...​/?st=jng7g0np&sh=8f959115

«wasm does not try to bring a new set of capabilities to browsers: everything that wasm can do could also be written in JS»

что подтверждает сказанное мною ранее

Нужен он как машине 5 колесо в 99% задач.

В общем и целом, как Вы и сказали

А як буде насправді подивимося.

P.S. главное чтобы телеметрию незабыли всунуть туда, а то не МС тру вэй какой-то будет :)

everything that wasm can do could also be written in JS

Тут лишь речь о том что webasm не будет иметь какой-то дополнительный функционал который отсутствует в JS. Тоесть не планируется делать ещё одни апплеты.

Вообще чем искать что-то что отдаленно вроде бы поддерживает твою идею о компиляции в JS — почитай оригинальный сайт
webassembly.org/docs/binary-encoding

Ок, без проблем. Вам виднее. Я говорю лишь о том, что для себя не вижу в нем никакого смысла. Во всяком случае пока что. Возможно в будущем он появится, но сейчас это выглядит как-то сомнительно все.

Якби в ньому не було сенсу — його б не імплементували в браузер. А це реальний технологічний прорив, а не просто можливість написання фронту на інших мовах. Ця можливість є лише сайд ефектом. З самого початку васм задумовувався як альтернатива js для важких задач як то ігри, онлайн фото і відео едітори, ну і що там ще. Тим не менш я вас підтримую що перетягати всю логіку на фронт не є розумним. З іншої сторони, перетягти туди все те що роблять в мобайл апах це доцільне. І воно вже робиться технологією СПА, але через тормозні джс фреймворки, які валять типовий смартфон, або як мінімум грузять його по дикому. Тому так, краще я в смартфоні буду запускати додатки ніж оце СПА.

Т.е. фронт и бэк на js это буэ, а фронт и бэк на C# это норм?

Норм це коли ти обераєш ті інструменти з якими тобі працюється найкраще, а не js, тому що по інакшому не можна. More choices, understand? Крім того це лише один з можливих розвитків. Інший це прихід сильного конкурента js.

everything that wasm can do could also be written in JS

І? Can це can, але логіки в написанні браузер ігор на повільному JS замість almost native speed мови і фреймворку під wasm нема. Всі захочуть грати в потужніші ігри в браузері з більшою їх продуктивністю. Ба навіть не сильно наворочені ігри якщо стануть в рази легшими це відкриває нові дуууже серйозні можливості. Уявіть як на цьому можна бізнес побудувати — у тебе будуть продукти кращі за ті що у конкурента. Це ж золота жила)

что подтверждает сказанное мною ранее

Це абсолютно нічого не підтверджує і не спростовує. Це що зветься КЕП.

P.S. главное чтобы телеметрию незабыли всунуть туда, а то не МС тру вэй какой-то будет :)

«WebAssembly (Wasm, WA) is a web standard that defines a binary format and a corresponding assembly-like text format for executable code in Web pages. It is meant to enable executing code nearly as fast as running native machine code.»

При чому тут взагалі телеметрія? Як і фреймворки якісь? Це стандарт під який можна компілити будь що. Що поставите юзеру те і буде. Хоч віртуальну машину джава пихайте, хоч го, хоч пхп)

Норм це коли ти обераєш ті інструменти з якими тобі працюється найкраще, а не js, тому що по інакшому не можна. More choices, understand?

Не совсем. Звучит как «Не хочу гвозди молотком забивать, хочу микроскопом и все тут» :)

прихід сильного конкурента js

Вы перелогинитесь или так и будете не от своего имени писать? :)

ігор

А кто заставляет игры в браузере писать? Зачем вообще это делать? Да и не играми едиными. А перевернуть все с ног на голову ради игр... Ну даже не знаю...

При чому тут взагалі телеметрія? Як і фреймворки якісь?

А при том, что куда ступает нога МС там войны, хаос, бедность ничего хорошего быть не может по-определению. Единственный продукт, который мне нравится это VS Code, но это какой-то не МС продукт, слишком юзерфрендли, если не считать телеметрии.
А теперь вот они и до веба добрались, на святое позарились...

Це стандарт під який можна компілити будь що.

Вот это и пугает... В первую очередь как пользователя.

Ну це не значить що буде доступ до файлової системи юзера. Так чи інакше такі речі робляться через APIs. А в пісочниці можна будь що компілити. Це до речі суттєва перевага над джава аплетами, васм не дає жодного доступу до машини юзера окрім дозволеного самим браузером. Він працює в браузері.

І це нічого хорошого не принесло в нашу дискусію) Ви продовжуєте видавати бажане за дійсне. Думаю нам варто закінчити.

Солидарен. Спасибо за интересную, хотя возможно и не совсем продуктивную беседу :)

You can load that into your web application and call it from JavaScript.

К аплетам и флешу тоже можно было обратиться из javascript. И что?
Ну и из аплета тоже можно было вызывать JS на станице.

флешу

Не вспоминайте пожалуйста. Я как разработчик с ним не был знаком, но как пользователь, очень рад что его наконец-то выпилили. Он у меня даже в браузере выключен.

А в мене він вилітав регулярно...

Тому, чому і не можна щоб на ринку була одна компанія — монополія.

Т.е. анархия лучше?

Ви з крайності в крайність

Ну на js не верстають і на го думаю не будуть. Верстають на html. Хоча от підсказують що вже ведуться роботи по портуванню повноцінних уі ліб як Qt. Роботи будуть йти і самої різної направленості бо webassembly це революція в браузері.

Чувак ты просто не понимаешь что главная проблема в мире фронта это дом апи само по себе

Я думаю кожен сам вирішить собі що в нього є головною проблемою. Не джс боям відтепер буде вказувати на чому фронт писати =)

П.с. памятаю про Typescript аналогічні викиди були. І як бачимо Ts вистрілив, що б там різні експерти не прогнозували. Треба просто поважати інших і їх вибір і бажання, а не вести бойові дії з усіма хто не вважає js хорошою мовою чи безальтернативною мовою в фронтенді.

Прямий доступ(Direct access) до дума(DOM) вже запилили(implemented)? Лінь читати статтю. Останнє що було коли цікавився то це коли(calls) до джс(JS) через брідж(bridge).

* Можно
* Зависит от скилов. Некоторых лучше загнать в рамки фреймворка и пусть кодит с запросами в гугл " how to «. Если со скилами и здравым смыслом все норм, то рано или поздно родится своя небольшая либа или фреймворк, который потом будет переиспользоваться.
* Сложно, все забито ширпотребом для «некоторых» из 2-го пункта. Но в целом посыл озвучен вот в этой небольшой статье medium.com/...​-is-the-best-b6b0aac2fd64
* Наличие большого количества адептов, которые верят, что если они перепишут с фреймворк/либа_1 на фреймворк/либа_2, то это решит их проблемы. Это очень влияет на релевантность поиска.
* Я в основном по части бекенда, но и там часто бывает, что приходится выгребать всякое гавно типа babel-я и других бесполезных штук, которые другие обычно ставят потому, что это было в первых 5 ссылках поисковой выдачи гугла. Поэтому стараюсь придерживаться принципа, что если ставишь какую-то зависимость, либу, фреймворк, то надо быть готовым ее поддерживать вместо автора.

ну можливо jQuery для швидкої імплементації UI свістєлок

ну все, ховайся.....

Дякую! Ще б по фронту шось подібне.

No Frameworks, No NPM, No Dependencies

не хватает только No Javascript.

Один день сложно было подождать?

Подписаться на комментарии