Мне кажется, значимость привязки server-side rendering к фреймворку переоценена.
У меня так получилось, что к angularjs SPA проще генерировать шаблоны на jinga2+pyjade, чем писать их целиком. В итоге, заполнить шаблон на сервере вместо форм данными модели или уже отдать заполненные формы — легче лёгкого.
И он тоже.
Ничто не помешает понаписать клиентов wayland-a, тормозящих не хуже современного окружения Х.
Зато помешает использовать удобное и юзабельное legacy.
Х — это очень быстрый протокол, на 256 цветах просто летает по 10Мбит сетке. Да, по VNC тоже цветокоррекцию не делают, если что.
Тормозить всё стало, когда вкорячили XRandr, который в 90% нафиг не нужен и перестали использовать битмаповые шрифты (которые главный конкурент использовал даже в Windows XP в основных виджетах).
Wayland хорош всем кроме поломатой совместимости с window менеджерами. E[0.17..0.21] хронически DR и с адским дизайном и выпиленными фичами, GNOME и без wayland вызывает желание не морочить себе и окружающим голову и использовать «десяточку».
Само собой. Но те же паблики — в текстовый файл с json, или любой другой сторадж.
Но у меня опыт маленький — я писал давно на php3 с перлом, а в отрасль вернулся только пару лет назад для своего проекта и сразу стал изучать питон и фласк, и даже картинки все у меня в базе.
А скажите, пожалуйста, зачем вам flask_restful?
Я вот обнаружил, что для простых случаев он не нужен, а для сложных — flask_potion удивителен и неповторим.
Ну и лично мне peewee ORM кажется намного более удобным при написании.
Веб-программирование прекрасно тем что оно в десять раз проще обычного классического,
Нет.
(на самом деле наоборот, результаты часто неожиданные по сравнению с классическим, и в итоге найти косяк гораздо сложнее, а опыта чтобы делать правильно, требуется сильно больше)
и не слишком высокие требование по продукту… просто оболочка
Такое впечатление, что вы таки Delphi не видели. Это был хит среди не умеющих программировать школьников. Т.е. даже веб-разработчику IMHO простооболочку быстрее сделать на незнакомом Delphi, а не из г… и палочек, найденных в npm.
А вот людей, знающих JavaScript и работу с браузерным DOM
По факту, на рынке масс факиров, знающих несколько приёмов магии с фреймворками и плохо представляющих, как сильно они шатают DOM.
Пускай C++ ошибок не прощает, но, следя за выделением памяти, на него легко переложить синхронные алгоритмы, которые встречаются в большинстве задач, в отличие от.
И сколько бы это писалось с помощью других инструментов?
Стесняюсь спросить… Вы Delphi видели? И родственников? Есть такой термин — rapid application development, и вот представленные web-технологии до си пор находятся на противоположном полюсе (хотоя связанные .NET, java/clojure почти Ok).
Хотя сам я для подобного использую кросс-платформенный wxPython, к которому быстро накидываю формы-интерфейсы в BoaConstructor (а чтоб был отзывчивым — использую threads)
"… Ну, потом его в дурку сдали конечно…"
Вы там совсем рехнулись с JS. Почитать мануал латеха и написать к нему любой скрипт на любом бэкэнде быстрее будет.
Да, и не хватает NoSQL со связями на стороне клиента.
Я не программист, я аналитик данных.
Программировать приходится на VBA, питоне, C#. Для пет-проекта — на JavaScript.
На любую поблему на SO первые несколько ответов — как минимум не оптимальные, но иногда и ошибочные (хотя проблему в частности решают).
Последнее впечатлило: в драйвере puodbc вставка данных в ms sql возможна только построчно.
Большинство ответов сводились к решению сделать огромный sql запрос с кучей insert, и переправить его серверу.
Я-то знаю про загрузку из csv, и понимал, что нужно искать (решение — модуль миграции данных odo). Но в целом уровень решений ужасен, на уровне «побить в бубен».
При этом, так как я не профессиональный программист, я без SO вообще программировать не могу. Другое дело, что возраст, образование и опыт позволяют понять где решение, а где ерунда.
Ох, прошу прощения.
Я про УПД. Ещё до его принятия даже был вариант одной бумажкой отделаться (но недолго, и я забыл детали).
Если нет нескольких платежей, или чёткой предоплаты, не вижу смысла использовать кипу бумаг.
Счёт -> оплата/товар -> УПД
1. Вопрос, с русификацией чего. Это изначально i18n система, база русских терминов заполнена, если чего-то не хватает, вписывается админом «на лету» (т.е. всё по-русски)
2. Первичка — это не наше изобретение. Да, есть монстры типа счёт+счёт-фактура, но и это: 1. отмерло 2. поддерживается. Если не хватает какого-то поля — добавить в модель очень легко (или вы про бумажные формы? см. 3-й пункт).
3. Склад. А что склад? В там склады с параметрами, со списаниями, заказами на отгрузку и производство, с печатью накладных и чего угодно. Так как всё это дело на питоне, есть интеграция с «безголовым» openoffice, в котором рисуются шаблоны форм документов для печати. Сообщество в России поддерживает актуальность форм документации.
4. В России — у внедренцев за деньги, импорт-экспорт входящей первички и синхронизация. Так как ничего, кроме задач фискальной отчётности от 1С не требуется, то всё не так сложно.
Ну, встроенный CRM, интернет-магазин, интеграция с asterisk телефонной станцией — это отдельные плюшки, которые, конечно, требуют донастройки под конкретные ситуации.
У меня так получилось, что к angularjs SPA проще генерировать шаблоны на jinga2+pyjade, чем писать их целиком. В итоге, заполнить шаблон на сервере вместо форм данными модели или уже отдать заполненные формы — легче лёгкого.
Ничто не помешает понаписать клиентов wayland-a, тормозящих не хуже современного окружения Х.
Зато помешает использовать удобное и юзабельное legacy.
Тормозить всё стало, когда вкорячили XRandr, который в 90% нафиг не нужен и перестали использовать битмаповые шрифты (которые главный конкурент использовал даже в Windows XP в основных виджетах).
Wayland хорош всем кроме поломатой совместимости с window менеджерами. E[0.17..0.21] хронически DR и с адским дизайном и выпиленными фичами, GNOME и без wayland вызывает желание не морочить себе и окружающим голову и использовать «десяточку».
Но у меня опыт маленький — я писал давно на php3 с перлом, а в отрасль вернулся только пару лет назад для своего проекта и сразу стал изучать питон и фласк, и даже картинки все у меня в базе.
Я вот обнаружил, что для простых случаев он не нужен, а для сложных — flask_potion удивителен и неповторим.
Ну и лично мне peewee ORM кажется намного более удобным при написании.
Мне кажется, какой-то синтетический случай. Такbе параметры у меня, если и захардкожены, то лежат вместе с моделями в models.py
Тссс!!! Этого не может быть, так как web-стек фронтенда это ТАК просто!
Нет.
(на самом деле наоборот, результаты часто неожиданные по сравнению с классическим, и в итоге найти косяк гораздо сложнее, а опыта чтобы делать правильно, требуется сильно больше)
Крутой поворот в контексте JavaScript с DOM. Или я не распознал сарказм?
Такое впечатление, что вы таки Delphi не видели. Это был хит среди не умеющих программировать школьников. Т.е. даже веб-разработчику IMHO простооболочку быстрее сделать на незнакомом Delphi, а не из г… и палочек, найденных в npm.
По факту, на рынке масс факиров, знающих несколько приёмов магии с фреймворками и плохо представляющих, как сильно они шатают DOM.
Пускай C++ ошибок не прощает, но, следя за выделением памяти, на него легко переложить синхронные алгоритмы, которые встречаются в большинстве задач, в отличие от.
Стесняюсь спросить… Вы Delphi видели? И родственников? Есть такой термин — rapid application development, и вот представленные web-технологии до си пор находятся на противоположном полюсе (хотоя связанные .NET, java/clojure почти Ok).
Хотя сам я для подобного использую кросс-платформенный wxPython, к которому быстро накидываю формы-интерфейсы в BoaConstructor (а чтоб был отзывчивым — использую threads)
Вы там совсем рехнулись с JS. Почитать мануал латеха и написать к нему любой скрипт на любом бэкэнде быстрее будет.
Да, и не хватает NoSQL со связями на стороне клиента.
Программировать приходится на VBA, питоне, C#. Для пет-проекта — на JavaScript.
На любую поблему на SO первые несколько ответов — как минимум не оптимальные, но иногда и ошибочные (хотя проблему в частности решают).
Последнее впечатлило: в драйвере puodbc вставка данных в ms sql возможна только построчно.
Большинство ответов сводились к решению сделать огромный sql запрос с кучей insert, и переправить его серверу.
Я-то знаю про загрузку из csv, и понимал, что нужно искать (решение — модуль миграции данных odo). Но в целом уровень решений ужасен, на уровне «побить в бубен».
При этом, так как я не профессиональный программист, я без SO вообще программировать не могу. Другое дело, что возраст, образование и опыт позволяют понять где решение, а где ерунда.
Я про УПД. Ещё до его принятия даже был вариант одной бумажкой отделаться (но недолго, и я забыл детали).
Если нет нескольких платежей, или чёткой предоплаты, не вижу смысла использовать кипу бумаг.
Счёт -> оплата/товар -> УПД
2. Первичка — это не наше изобретение. Да, есть монстры типа счёт+счёт-фактура, но и это: 1. отмерло 2. поддерживается. Если не хватает какого-то поля — добавить в модель очень легко (или вы про бумажные формы? см. 3-й пункт).
3. Склад. А что склад? В там склады с параметрами, со списаниями, заказами на отгрузку и производство, с печатью накладных и чего угодно. Так как всё это дело на питоне, есть интеграция с «безголовым» openoffice, в котором рисуются шаблоны форм документов для печати. Сообщество в России поддерживает актуальность форм документации.
4. В России — у внедренцев за деньги, импорт-экспорт входящей первички и синхронизация. Так как ничего, кроме задач фискальной отчётности от 1С не требуется, то всё не так сложно.
Ну, встроенный CRM, интернет-магазин, интеграция с asterisk телефонной станцией — это отдельные плюшки, которые, конечно, требуют донастройки под конкретные ситуации.