4 ms·

The language doesn't matter, but the ecosystem does. It is when it comes to "non-CRUD apps" that an ecosystem will really start to matter. One is probably not b

by jeswin 10y ago

The language doesn't matter, but the ecosystem does. It is when it comes to "non-CRUD apps" that an ecosystem will really start to matter. One is probably not better than the other but getting started is hard. Take the case of Node and JavaScript itself. The ecosystem is huge. The tooling is complex. A newbie starting out will not even be able to get many examples to run without a mesh of transpilers and build tools. There are roadblocks everywhere; what's the type annotation there? What's with the strange JSX syntax? What's a transpiler? Add to that, EcmaScript itself is a moving target, more so than any other language. Similar issues exist in other languages. C# is a simple language to master, .Net is a huge ecosystem. There's not going to be a lot of resistance moving from C# to F#. But for the newbie, the challenges are daunting. Should you use Microsoft's preferred ORM which ships with .Net or write your own SQL? Which UI tooling should I use? There is plenty of advice on the web, yet it needs an experienced developer to make those decisions. Consider this. if you chose SilverLight a few years back, your product is soup today. Picking an ecosystem is not easy. Has never been.

TAForObvReasons 10y ago
> Consider this. if you chose SilverLight a few years back, your product is soup today. The amazing part about JS is that most of the code written for browsers a decade ago still works today. It is extremely unlikely that we will see a company outright ban JS in their web browsers in the same way that iDevices don't support flash.
- Silhouette 10y ago
  The amazing part about JS is that most of the code written for browsers a decade ago still works today. Yes, that is mostly true, but it glosses over two big problems with the JS ecosystem. The first is that longevity seems to be a dirty word. I have seen professional JS developers say, without a hint of irony, that their code only needs to last a year, maybe two, so it doesn't need to be designed for long-term maintenance or ongoing development. That same attitude exists in much of the library and tool development, which means while your code might still run in 2 or 5 or 10 years, the dependencies for your code might not have kept up. Even if they still run, they're stuck at whatever level of features and security and flexibility they had when they were abandoned, which might well have been only six months or a year after you added them to your project. Now you have a perma-brake applied to everything you do. The other big problem with the JS ecosystem is that JS itself is a moving target. Thanks to evergreen browsers, Node, and those controlling them, standardisation and stability also seem to be dirty words now. Your code from 10 years ago, using only basic JS language features, might still run. Unfortunately, your code from 2 years ago, using whatever alpha/beta quality JS features supported promises or observers or local storage at that time, might not. And the same goes for code in dependencies you introduced 2 years ago that are already abandonware. Multiply those two factors and you have a recipe for instability and frequent unexpected failures unlike anything I have ever seen on any other platform.
  - deleted 10y ago
    [deleted]
  - thesagan 10y ago
    Agreed. Adding to your point: If this were NASA, memories of Apollo 1 "go fever" would be a fitting analogy of our present circumstance. "Nothing we did had any shelf life" was one of the core problems identified by Gene Kranz in his "tough and competent" speech to his mission control team after the fire. I think it's a salient point. When all the parts are constantly churning, fires are to be expected. Progress is messy if we're not cautious, and I'm not sure if we are being cautious in the right places. We could learn from Mission Control. (Lots of room for debate, here! And I'm being purposefully vague.)
weberc2 10y ago
I will say that Go makes the default path pretty painless. If you can conform to the directory structure, you can build a binary for any platform from any platform with a single command--no metadata files or build scripts. From there, deployment is a matter of moving a single binary. No interpreter, no VM, no runtime dependencies. It's opinionated nature can be annoying, but it means a lot of choices are made for you. I'm not familiar with another language that offers such a fast path.

by jeswin 10y ago

TAForObvReasons 10y ago

> Consider this. if you chose SilverLight a few years back, your product is soup today. The amazing part about JS is that most of the code written for browsers a decade ago still works today. It is extremely unlikely that we will see a company outright ban JS in their web browsers in the same way that iDevices don't support flash.

Silhouette 10y ago
The amazing part about JS is that most of the code written for browsers a decade ago still works today. Yes, that is mostly true, but it glosses over two big problems with the JS ecosystem. The first is that longevity seems to be a dirty word. I have seen professional JS developers say, without a hint of irony, that their code only needs to last a year, maybe two, so it doesn't need to be designed for long-term maintenance or ongoing development. That same attitude exists in much of the library and tool development, which means while your code might still run in 2 or 5 or 10 years, the dependencies for your code might not have kept up. Even if they still run, they're stuck at whatever level of features and security and flexibility they had when they were abandoned, which might well have been only six months or a year after you added them to your project. Now you have a perma-brake applied to everything you do. The other big problem with the JS ecosystem is that JS itself is a moving target. Thanks to evergreen browsers, Node, and those controlling them, standardisation and stability also seem to be dirty words now. Your code from 10 years ago, using only basic JS language features, might still run. Unfortunately, your code from 2 years ago, using whatever alpha/beta quality JS features supported promises or observers or local storage at that time, might not. And the same goes for code in dependencies you introduced 2 years ago that are already abandonware. Multiply those two factors and you have a recipe for instability and frequent unexpected failures unlike anything I have ever seen on any other platform.
- deleted 10y ago
  [deleted]
- thesagan 10y ago
  Agreed. Adding to your point: If this were NASA, memories of Apollo 1 "go fever" would be a fitting analogy of our present circumstance. "Nothing we did had any shelf life" was one of the core problems identified by Gene Kranz in his "tough and competent" speech to his mission control team after the fire. I think it's a salient point. When all the parts are constantly churning, fires are to be expected. Progress is messy if we're not cautious, and I'm not sure if we are being cautious in the right places. We could learn from Mission Control. (Lots of room for debate, here! And I'm being purposefully vague.)

weberc2 10y ago

I will say that Go makes the default path pretty painless. If you can conform to the directory structure, you can build a binary for any platform from any platform with a single command--no metadata files or build scripts. From there, deployment is a matter of moving a single binary. No interpreter, no VM, no runtime dependencies. It's opinionated nature can be annoying, but it means a lot of choices are made for you. I'm not familiar with another language that offers such a fast path.