4 ms·

Because...you know...SOA and N-tier systems didn't exist before Node. So what's the name of the anti-pattern where a recent grad stumbles into an enterprise cod

Because...you know...SOA and N-tier systems didn't exist before Node. So what's the name of the anti-pattern where a recent grad stumbles into an enterprise codebase for the first time and has a panic attack because the system architecture doesn't rely on whatever's hot that month in Silicon Valley tech blogs?

lkrubner 10y ago
Still, when something succeeds beyond my expectations, I encourage myself to ask myself why that has has happened. On the one hand, I strongly agree with the sarcasm of this: "Because...you know...SOA and N-tier systems didn't exist before Node. " That is well said. On the other hand, something must explain the continued rise of Node and Javascript. Since 2010 I've been a huge fan and promoter of Clojure. I keep thinking it is going to sweep the startup world. And that keeps failing to happen. And I keep wondering why. Last year I worked at a startup that was in the startup incubator run by NYU in New York. The incubator is an office at 137 Varick street, and there are something like 20 to 30 startups up in there (the number varies a lot as students of NYU are allowed to use the space for short periods). One thing that surprised me was how completely Node had gained the support of the newer startups. It was definitely the hot new thing. Some of the older startups were using Rails, the rest were using Node. And Node very much has the fire that Rails had 10 years ago. My startup used a mix of Clojure and Java but we were a rare thing (I wrote about this elsewhere). None of the startups were using Groovy or Java or Scala or Clojure -- the vast resources of the JVM were largely ignored. Nor do I recall any of the startups using C#. Why is that? I am not sure, but I can make a few guesses. You mention SOA. The culture that grew up around industry standards such as WSDL lead James Lewis and Martin Fowler to complain about “a complexity that is, frankly, breathtaking“: "Certainly, many of the techniques in use in the microservice community have grown from the experiences of developers integrating services in large organisations. The Tolerant Reader pattern is an example of this. Efforts to use the web have contributed, using simple protocols is another approach derived from these experiences — a reaction away from central standards that have reached a complexity that is, frankly, breathtaking. (Any time you need an ontology to manage your ontologies you know you are in deep trouble.)" They then linked to this to make their point: http://wiki.apache.org/ws/WebServiceSpecifications http://wiki.apache.org/ws/WebServiceSpecifications Arguably, Node offers an easy approach to "SOA lite". Consider how forbidding the previous link is, and then consider how friendly an approach is offered by a company such as LSQ (which started off specializing in Node): https://www.lsq.io/ https://www.lsq.io/ Especially since LSQ is about to roll out an automated processes for microservices on a stack to discover one another (which app runs on which port), a relative novice can get much of the benefits of SOA, quick and easy. Also, of course, Javascript can be used on the frontend and backend, and nowadays there are a lot of programmers who start off as frontenders and then later learn the backend, and want to bring their favorite language with them. I could counter-argue that Clojure has Clojurescript and Om-Next, both of which are very, very cool, but I must admit that the JVM has no on-ramp as easy as what Node offers (and programmers who use Clojurescript, but not Clojure, have been rare, at least till very recently). Also, I've wrestled with enough too complex build scripts that I now appreciate how simple "npm install" is. So maybe some programmers, who are still in the early phases of their career, are over enthusiastic about Node/Javascript. We should all still admit that what Node achieved in terms of ease of use is fairly impressive.
- jmspring 10y ago
  Node/JavaScript cater to those who also know a bit of front end. Node has its uses for prototyping and quick projects, at least for me. I honestly spend about 1/3 of my time in the Java ecosystem -- it has its uses, I've done a lot of it (dev and operations), but I personally dislike the general weight of dealing with server side Java - app servers, etc. Language and ecosystem, for me, are dictated by the needs of the particular project. I said 1/3 Java above, the other 2/3 for me (right now) are C and Node... Across 4 projects.
- vessenes 10y ago
  I'm on the other side of that one, which is to say I don't like the JVM, (I think of maven and have a bad, bad feeling) and inre: WSDL, and SOAP, I prefer something much, much simpler than anything that came from XML-RPC folks. I guess if you think back, JSON has the same story that the node story you tell has; it was easy to work with for developers and didn't require a lot of theory or tooling. That makes sense to me as a great pattern to get adoption. The much larger point though is that we should be able to talk over pluses and minuses in different ecosystems without calling somebody outdated or too old or too slow.
- knieveltech 10y ago
  That is an amazing reply to what was intended to be simple sarcasm. Ease of use/adoption is king in my book, although it's interesting to note php doesn't get any points despite its well-documented low barrier to entry.
- smoyer 10y ago
  I think the difference between the Java (let's say EE) ecosystem and the NodeJS ecosystem is how you learn them. In a typical Java EE system, you have to learn a lot about the architecture, available libraries and practices before you can really start. With the NodeJS ecosystem, you can get something running in very short order - but while the education is incremental, you still will end up learning a lot of new libraries to build anything substantial. When I built a PoC copy of an existing (and complicated) system, I ended up building most of the functionality of a Java EE application server out of NodeJS components. As an aside, don't confuse Java EE with J2EE - the new enterprise Java system is a far simpler development environment than the old (I almost gave up on enterprise Java myself before this transition).

lkrubner 10y ago

Still, when something succeeds beyond my expectations, I encourage myself to ask myself why that has has happened. On the one hand, I strongly agree with the sarcasm of this: "Because...you know...SOA and N-tier systems didn't exist before Node. " That is well said. On the other hand, something must explain the continued rise of Node and Javascript. Since 2010 I've been a huge fan and promoter of Clojure. I keep thinking it is going to sweep the startup world. And that keeps failing to happen. And I keep wondering why. Last year I worked at a startup that was in the startup incubator run by NYU in New York. The incubator is an office at 137 Varick street, and there are something like 20 to 30 startups up in there (the number varies a lot as students of NYU are allowed to use the space for short periods). One thing that surprised me was how completely Node had gained the support of the newer startups. It was definitely the hot new thing. Some of the older startups were using Rails, the rest were using Node. And Node very much has the fire that Rails had 10 years ago. My startup used a mix of Clojure and Java but we were a rare thing (I wrote about this elsewhere). None of the startups were using Groovy or Java or Scala or Clojure -- the vast resources of the JVM were largely ignored. Nor do I recall any of the startups using C#. Why is that? I am not sure, but I can make a few guesses. You mention SOA. The culture that grew up around industry standards such as WSDL lead James Lewis and Martin Fowler to complain about “a complexity that is, frankly, breathtaking“: "Certainly, many of the techniques in use in the microservice community have grown from the experiences of developers integrating services in large organisations. The Tolerant Reader pattern is an example of this. Efforts to use the web have contributed, using simple protocols is another approach derived from these experiences — a reaction away from central standards that have reached a complexity that is, frankly, breathtaking. (Any time you need an ontology to manage your ontologies you know you are in deep trouble.)" They then linked to this to make their point: http://wiki.apache.org/ws/WebServiceSpecifications http://wiki.apache.org/ws/WebServiceSpecifications Arguably, Node offers an easy approach to "SOA lite". Consider how forbidding the previous link is, and then consider how friendly an approach is offered by a company such as LSQ (which started off specializing in Node): https://www.lsq.io/ https://www.lsq.io/ Especially since LSQ is about to roll out an automated processes for microservices on a stack to discover one another (which app runs on which port), a relative novice can get much of the benefits of SOA, quick and easy. Also, of course, Javascript can be used on the frontend and backend, and nowadays there are a lot of programmers who start off as frontenders and then later learn the backend, and want to bring their favorite language with them. I could counter-argue that Clojure has Clojurescript and Om-Next, both of which are very, very cool, but I must admit that the JVM has no on-ramp as easy as what Node offers (and programmers who use Clojurescript, but not Clojure, have been rare, at least till very recently). Also, I've wrestled with enough too complex build scripts that I now appreciate how simple "npm install" is. So maybe some programmers, who are still in the early phases of their career, are over enthusiastic about Node/Javascript. We should all still admit that what Node achieved in terms of ease of use is fairly impressive.

jmspring 10y ago
Node/JavaScript cater to those who also know a bit of front end. Node has its uses for prototyping and quick projects, at least for me. I honestly spend about 1/3 of my time in the Java ecosystem -- it has its uses, I've done a lot of it (dev and operations), but I personally dislike the general weight of dealing with server side Java - app servers, etc. Language and ecosystem, for me, are dictated by the needs of the particular project. I said 1/3 Java above, the other 2/3 for me (right now) are C and Node... Across 4 projects.
vessenes 10y ago
I'm on the other side of that one, which is to say I don't like the JVM, (I think of maven and have a bad, bad feeling) and inre: WSDL, and SOAP, I prefer something much, much simpler than anything that came from XML-RPC folks. I guess if you think back, JSON has the same story that the node story you tell has; it was easy to work with for developers and didn't require a lot of theory or tooling. That makes sense to me as a great pattern to get adoption. The much larger point though is that we should be able to talk over pluses and minuses in different ecosystems without calling somebody outdated or too old or too slow.
knieveltech 10y ago
That is an amazing reply to what was intended to be simple sarcasm. Ease of use/adoption is king in my book, although it's interesting to note php doesn't get any points despite its well-documented low barrier to entry.
smoyer 10y ago
I think the difference between the Java (let's say EE) ecosystem and the NodeJS ecosystem is how you learn them. In a typical Java EE system, you have to learn a lot about the architecture, available libraries and practices before you can really start. With the NodeJS ecosystem, you can get something running in very short order - but while the education is incremental, you still will end up learning a lot of new libraries to build anything substantial. When I built a PoC copy of an existing (and complicated) system, I ended up building most of the functionality of a Java EE application server out of NodeJS components. As an aside, don't confuse Java EE with J2EE - the new enterprise Java system is a far simpler development environment than the old (I almost gave up on enterprise Java myself before this transition).