Rosnąca popularność Node.js stanowi zagrożenie dla innych języków?

drorat1 napisał(a):

Czy może ktoś się wypowiedzieć np. na temat Leftpada i tych wszystkich zależności zależności?

https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/

Położyło ileś tam tys. projektów a kod tej funkcji leftpad jest prosty. Ile jest takich prostych kodów i funkcji zaciąganych nie wiadomo skąd?

Kod tej funkcji nie jest prosty. Jest banalny.
A że n projektów zależy od jedno-funkcyjnych projektów to akurat jest wada i brak myślenia ze strony twórców.
Powinien powstać projekt typu Boost czy Guava dla JavaScript (npm) - wtedy można by uniknąć takich problemów.

• lenistwo umysłowe ("nie chce mi się pisać funkcji, zainstaluję se bibliotekę, która myśli za mnie")
• brak umiejętności programistycznych (większość frontendowców jest bardzo słaba jeśli chodzi o ogólne programowanie).
• mit sprawdzonego rozwiązania (czyli: "lepiej nie pisać samemu kodu, tylko użyć sprawdzonego i przetestowanego rozwiązania" - o ile taka filozofia się sprawdza na większą skalę, czyli np. lepiej jest użyć Reacta niż pisać własnego - to jednak zastosowanie tej filozofii do jednolinijkowych funkcji to mocne nadużycie. Jest np. na npm pakiet is-negative do sprawdzania czy liczba jest ujemna - czyli wg tej absurdalnej filozofii nie mam prawa tak napisać if (i < 0) tylko muszę użyć biblioteki, żeby "nie odkrywać koła na nowo" (JavaScriptowcy zjadają własny ogon przez tego typu dogmaty. Bo oni na serio w to wierzą, i potrafią ewangelizować ludzi, że trzeba użyć czegoś gotowego zamiast napisać coś własnego).
• autokreacja autorów bibliotek (każdy JSowiec lubi tworzyć własne libki dla zabawy, choćby miały jedną linijkę kodu).

No cóż:

https://github.com/ljharb/is-negative-zero
https://github.com/kevva/is-positive
https://github.com/kevva/is-negative

I wszystko otestowane jak należy :)

overengineering xD najbardziej absurdalna jest liczba commitów. 22 commity is-negative, 59 commitów w is-negative-zero. Jak takie coś widzę, to zaczynam przypuszczam, że głównym celem pisania tych bibliotek nie jest wcale napisanie funkcjonalności a raczej to, że ktoś się po prostu szkolił w używaniu Gita, Githuba, NPM, travisa (nie wiem co to, ale tam są takie pliki) i w paru innych narzędzi, łącznie z Markdownem, w którym jest pisana dokumentacja.

Czyli to są chyba Helloworldy ludzi, którzy uczą się obsługiwać Gita czy inne narzędzia, żeby być atrakcyjnym na rynku pracy...

Ten kevva niniejszym spycha Yodę na drugie miejsce mojej listy autorytetów. Takie dwie fundamentalne biblioteki wykuł! ;P

No nie porównujmy jakiego tam gostka do mistrza Yody, bez przesady.

Sam uwazam, ze gdybysmy mieli zestawic n losowych frontendowcow z n losowymi backendowcami, to skille programistyczne mieliby lepsze ci drudzy. I tak mnie cieszy ze front idzie ku tej stronie bardziej inzynierskiej, bo jakby nie patrzec malo techniczne jest wykonywanie(wpinanie) slajderow czy single page'ow, dlatego tak duzo chetnych jest na front, bo maja teoretyczne wieksze szanse.
Super, niech ida, ida Seba01, Seba02, same klony do klepania.

Tylko ze tutaj mowimy o node, czyli o backendzie. Tylko, ze jest to jak ktos wspomnial, jest to na hypi'e wsrod hipsterow frontowych, dlatego b. czesto kod jest tragiczny. Naucze sie Reacta, Angulara, Vue, Node'a, przeciez kazdy front teraz musi to znac, a jak zapytasz co to event loop, digest cycle, virutal DOM, nie mowiac juz o takich rzeczach jak SOLID, DRY YAGNI etc.

Sa to powody dla ktorych np. nie chce byc "front end developerem". Node spoko, ale niestety nie nadaje sie do wszystkiego, dlatego jezyk enterprise tez warto znac.

Kto za tym nadąży, to już łatwiej ogarnąć Kotlin i Androida.

LukeJL napisał(a):

• lenistwo umysłowe ("nie chce mi się pisać funkcji, zainstaluję se bibliotekę, która myśli za mnie")
• brak umiejętności programistycznych (większość frontendowców jest bardzo słaba jeśli chodzi o ogólne programowanie).
• mit sprawdzonego rozwiązania (czyli: "lepiej nie pisać samemu kodu, tylko użyć sprawdzonego i przetestowanego rozwiązania" - o ile taka filozofia się sprawdza na większą skalę, czyli np. lepiej jest użyć Reacta niż pisać własnego - to jednak zastosowanie tej filozofii do jednolinijkowych funkcji to mocne nadużycie. Jest np. na npm pakiet is-negative do sprawdzania czy liczba jest ujemna - czyli wg tej absurdalnej filozofii nie mam prawa tak napisać if (i < 0) tylko muszę użyć biblioteki, żeby "nie odkrywać koła na nowo" (JavaScriptowcy zjadają własny ogon przez tego typu dogmaty. Bo oni na serio w to wierzą, i potrafią ewangelizować ludzi, że trzeba użyć czegoś gotowego zamiast napisać coś własnego).
• autokreacja autorów bibliotek (każdy JSowiec lubi tworzyć własne libki dla zabawy, choćby miały jedną linijkę kodu).

stary wywodzę się c++/c# piszę czysty kod w JS, uwielbiam ten język, jest elegancki i lekki. Wypaliłem się klepiąc ciągle w c#, miałem dość w JS, wróciła radość programowania. Serwer 5 min jest. Wzorce? Zawsze je stosuje. Pewnie nawet połowy stosowanych przeze mnie na codzień wzorców, w życiu nie zastosowałeś w praktyce. Owszem spotykam mnóstwo bardzo słabych programistów ale to wina ściągania ludzi ze wschodu oraz tekstu "kazdy może być programistą". Wrzuciłeś wszystkich do jednego worka, a może sam jesteś tak słaby w JS, że w ten sposób chcesz się odegrać?

I tak golang najlepszy.

Revenant05 napisał(a):

(...)
Frameworki: Loopback, Hapi, Sails?

Serwisy korzystające w większości z Node.js, m.in.: Netflix, Linkedin, Uber, PAYPAL(!). To są małe serwisy?

Era monolitu się kończy, teraz duże serwisy i tak buduje się w oparciu o mikrousługi, a Node do tego jest najlepszy.

GitHub Netflixa zawiera głównie projekty Javowe: https://github.com/Netflix
Np https://github.com/Netflix/conductor - Conductor is a microservices orchestration engine - https://netflix.github.io/conductor/

LinkedIn? Oto artykuł o architekturze: https://engineering.linkedin.com/architecture/brief-history-scaling-linkedin

By using JSON over HTTP, our new APIs finally made it easy to have non-Java-based clients. LinkedIn today is still mainly a Java shop, but also has many clients utilizing Python, Ruby, Node.js, and C++ both developed in house as well as from tech stacks of our acquisitions.

Do serwowania stron używają Play framework (napisany w Scali):

We’ve rethought our frontend approach, adding client templates into the mix (Profile page, University pages). This enables more interactive applications, requiring our servers to send only JSON or partial JSON. Plus, templates get cached in CDNs and the browser. We also started to use BigPipe and the Play framework, changing our model from a threaded web server to a non-blocking asynchronous one.

Playa chyba dość polubili
https://engineering.linkedin.com/blog/2016/12/pemberly-at-linkedin

We decided to build up a solution, dubbed Pemberly, combining open source software we were already using in the mid-tier (Play) along with a web framework (Ember) for JavaScript that would deliver strong conventions, easy ability to manage state, a robust build and testing methodology, and the delightful, app-like user experience we were targeting.

A Node to używają do server-side rendering:

The next piece of the architecture is the Base Page Renderer. The Base Page Renderer provides the head of the document and early flush capabilities. It also allows the app to load in several modes: Vanilla (browser does the heavy lifting), SSR (server-side render for DOM complete), and BigPipe (the ability to let the browser boot the Ember app while simultaneously streaming data and DOM to the browser by delegating that work to separate Node processes, which are running the Ember app).

PayPal używa Scali (chodzącej na JVMie) z Akką jako backendu:
http://highscalability.com/blog/2016/8/15/how-paypal-scaled-to-billions-of-transactions-daily-using-ju.html
https://www.lightbend.com/blog/how-reactive-systems-help-paypal-squbs-scale-to-billions-of-transactions-daily

Uber natomiast zaczął od Node.js i mają dużo starego kodu napisanego w Node.js, ale przesiadają się chyba na język Go. Używają także Javy dla wysokiej wydajności:
https://eng.uber.com/tech-stack-part-one/

At the lower levels, Uber’s engineers primarily write in Python, Node.js, Go, and Java. We started with two main languages: Node.js for the Marketplace team, and Python for everyone else. These first languages still power most services running at Uber today.

We adopted Go and Java for high performance reasons. We provide first-class support for these languages. Java takes advantage of the open source ecosystem and integrates with external technologies, like Hadoop and other analytics tools. Go gives us efficiency, simplicity, and runtime speed.

https://eng.uber.com/tech-stack-part-two/

Uber’s core trip execution engine was originally written in Node.js because of its asynchronous primitives and simple, single-threaded processing. (In fact, we were one of the first two companies to deploy Node.js in production.) Node.js gives us the ability to manage large quantities of concurrent connections. We’ve now written many services in Go, and this number continues to increase. We like Go for its concurrency, efficiency, and type-safe operations.

Wibowit napisał(a):

Revenant05 napisał(a):

(...)
Frameworki: Loopback, Hapi, Sails?

Serwisy korzystające w większości z Node.js, m.in.: Netflix, Linkedin, Uber, PAYPAL(!). To są małe serwisy?

Era monolitu się kończy, teraz duże serwisy i tak buduje się w oparciu o mikrousługi, a Node do tego jest najlepszy.

GitHub Netflixa zawiera głównie projekty Javowe: https://github.com/Netflix
Np https://github.com/Netflix/conductor - Conductor is a microservices orchestration engine - https://netflix.github.io/conductor/

To że Netflix używa node.js to pewne i jednocześnie nie koliduje z tym co napisałeś (więc po co to napisałeś?).

https://medium.com/netflix-techblog/making-netflix-com-faster-f95d15f2e972
https://blog.risingstack.com/node-js-examples-how-enterprises-use-node-in-2016/
https://thenewstack.io/netflix-uses-node-js-power-user-interface/

Odniosłem się do:

Serwisy korzystające w większości z Node.js

Z artykułów które podałeś wynika, że Node jest używany do frontu, a backend stoi na Javie. Node przydał się, bo zredukował duplikację kodu i pozwolił na server-side rendering przyspieszający ładowanie strony na urządzeniach użytkowników:

https://thenewstack.io/netflix-uses-node-js-power-user-interface/

Traditionally, Netflix has been an enterprise Java shop, but “as we migrated out of the data center to the cloud we moved to a more service-based architecture,” Trott said. The company is in the process of breaking up what used to be a monolithic Java application into a set of smaller services. Java still powers the backend of Netflix, but all the stuff that the user sees comes from Node.

https://medium.com/netflix-techblog/making-netflix-com-faster-f95d15f2e972

Node.js and React.js are natural fits for this style of application. With Node.js and React.js, we can render from the server and subsequently render changes entirely on the client after the initial markup and React.js components have been transmitted to the browser.

Renderowanie skomplikowanych JavaScriptowych stronek po stronie serwera w zasadzie wymaga użycia Node.js (inne rozwiązania są raczej niepraktyczne), ale samo w sobie to nie oznacza, że Netflix korzysta w większości z Node.js.

Sam Netflix na swojej stronie głównej na GitHubie http://netflix.github.io/ chwali się na nagrodą opisaną tutaj https://jaxenter.com/jax-awards-winners-announced-at-jax-2015-conference-116358.html

The winners of the 2015 JAX Innovation Awards were announced to an audience of over two thousand programmers at the JAX conference in Germany.

This year’s JAX Special Jury Award goes to… Netflix

The rate at which this entertainment game-changer has adopted new technologies and implemented them into its DevOps approach is setting new standards in IT. Java, Tomcat, Hive, MySQL, Gluster, Hive, Chukwa, Cassandra and Hadoop are just a few of the technologies being used by Netflix, which has made a significant contribution to the open source world in doing so.

Wystarczy zresztą poprzeglądać tę stronkę Netfliksa na GitHubie by zobaczyć że cały backend Javą stoi.

@Wibowit: z tego co zacytowales to Netflix stal na Javie. Oczywiscie w takiej sytuacji trudno powiedziec co u nich jest teraz wiekszoscia, ale to co u nich lezy teraz na github wg mnie o niczym nie swiadczy.

Tutaj cos nowszego:
https://medium.com/netflix-techblog/developer-experience-lessons-operating-a-serverless-like-platform-at-netflix-a8bbd5b899a0

Na razie w wątku mieliśmy jedną wypowiedź kogoś doświadczonego, ale w budowaniu API na Express js - a to przecież microframework jak Sinatra czy Slim. Do mikroserwisów na pewno się nadaje.

Jeśli stawiamy apkę webową i do tego chcemy prosty backend, to na pewno to stack idealny. Ale jakies korpo ERP na Oracle? To główne projekty dużych firm podnajmujących programistów w PL jak np. Epam.

Twardy Frank napisał(a):

tamtamtu napisał(a):

-Tez wywodze sie z czasow c++/c# - czasow gdy kazdy uwazal js za zlo (taki ficzer dla dzieci, ktorzy chca udawac ze znaja sie na programowaniu). Uwazam > > ze c# jest bardziej elegancki od js a ze mam wiecej doswiadczenia i stosuje wiecej wzorcow to jednak wychodzi ze ja mam racje a Ty sie mylisz :)

Na jakiej podstawie twierdzisz, że masz więcej doświadczenia i stosujesz więcej wzorców. Człowieku ty porównujesz jezyk dynamiczny do statycznego i ty mówisz, że masz doświadczenia... Gościu javascript jest dziś dużo bardziej zaawansowanym językiem. Dziś w tym jezyku napiszesz wszystko jest uniwersalny. I to jest odpowiedz dlaczego, za pare lat język ten wygryzie resztę z rynku. Oczywiście java, c# zostaną, ale stracą sporą część rynku. A wiesz dlaczego co poniektórzy uważali, że JS, jest dla dzieci czy jest zło jak to napisałeś? Bo go nie umieli i byli leniwi by się go nauczyć.

Gdybyś był "doświadczony" jak to piszesz, nie napisał byś takiego komentarza, bo jest on juniorski

A wiesz dlaczego co poniektórzy uważali, że JS, jest dla dzieci czy jest zło jak to napisałeś? Bo go nie umieli i byli leniwi by się go nauczy

Watpie, raczej dlatego ze byl to jezyk zupelnie oderwany od innych jezykow, strasznie dziwaczny. Jesli znales jakis jezyk backendowy, latwiej Ci bylo wejsc w inny (nawet znajac c# latwiej wejsc w php niz js) i wlasnie to denerwowalo, na kazdej drodze spotykaly Cie same WTF'y.

Wzorce? Zawsze je stosuje. Pewnie nawet połowy stosowanych przeze mnie na codzień wzorców, w życiu nie zastosowałeś w praktyce.

Stosowanie bez zastanowienia wzorców jest często gorsze niż nieznajomość wzorców w ogóle... Nie chodzi o to, żeby wpychać wzorce w projekt tak jak się wpycha wodę w wędliny, tylko, żeby wiedzieć, że pewne problemy można rozwiązać w pewien ustalony sposób. Generalnie to powinno się wzorować jak najmniej wzorców, byle tylko zachować te, które są niezbędne.

Gdybyś był "doświadczony" jak to piszesz, nie napisał byś takiego komentarza, bo jest on juniorski

Juniorskie komentarze jako oznaka nie bycia tru-programistą skryptów dżawy. Czegoś takiego jeszcze nie widziałem XD

Ja tam jestem słaby junior więc autorytet żaden, ale chyba nikt nie zaprzeczy że pod kątem pracy na najbliższe kilka lat, bez względu na wszystkie mankamenty, JS to wyśmienity wybór dla zaczynających programistów.

A dlaczego JS a nie TS? Jakbyn nial wybrac to bym wybral to drugie.

A co za różnica? TS to JS, tylko że ma dodatki. Tu nie ma co wybierać, bo typeof null dalej będzie "object" nawet w TypeScripcie, więc raczej nie usuwa ci żadnych WTFów z JSa.