×

Frameworkless JavaScript

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

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

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
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

Если мы говорим о 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 точно зайвий.

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

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

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

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

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

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

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

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

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

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

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

А вы попробуйте написать, например тасклист (с отдельным шаблоном задачи) на реакте и на ес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 запросов с фронта летят, пару метров кода, тьма ресурсов и дальше по списку, и да- в недрах есть реакт, хотя так и не понял какую часть они реактом рендерят. А страница с пары форм и графика.
Для всяких реактов и прочих есть готовые сборки, склонировал и вперед писать шаблончики, выходит якобы занимаешься как раз тем что нужно, да и все ровно никто не разбирается как там интегрируются компоненты сборки между собой, в принципе не надо знать что там под капотом и как эта «магия» работает. Проблемы могут начаться с нестандартными задачами.

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

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

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

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

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

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

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

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

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

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

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 потому что он уже знаком был с ним на момент создания проектов

Чи можливо в пізньому 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я что-то пропустил? Не припомню чтобы браузеры умели 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#

Т.е. фронт и бэк на 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, тому що по інакшому не можна. More choices, understand?

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

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

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

ігор

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

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

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

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

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

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

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

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

флешу

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

Коментар порушує правила спільноти і видалений модераторами.

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

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

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

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

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

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

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

No Frameworks, No NPM, No Dependencies

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

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

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