Earlier quoted context omitted.
This isn't always a useful way to look at it. For a startup or small team especially, any time spent learning a new programming language is time spent not working on the core product. Yes, you might be better off in the long run using a more foreign programming language, but then again the business might not survive that long if you aren't actually building anything. Also, it's easy to learn a language's syntax over…
As I said above: hire someone new or invest the time to learn the language. Just because someone knows how to make a cute scarf using duct tape, safety scissors, and Elmers glue doesn't mean they should be building your backend driving the company 95 mph with seatbelts, airbags, and a chassis with crumple-zones.
The melting pot of JavaScript (2017)
91–100 of 200 posts
Re: The melting pot of JavaScript (2017)
#92Earlier quoted context omitted.
No. And that is also why JS is successful. Newbies with little oversight create new tools. Of thousands of them, one or two become popular because of non-functional reasons (right blog post, right fit, easy use, ..). Welcome to the mess :)
Tech pop-culture... Navigating these technology growth explosions is like searching for solid reference architecture in a booming shantytown. Some parts of these settlements eventually get things like running water, working sewage, urban planning.
Re: The melting pot of JavaScript (2017)
#93I personally think that the JavaScript community is doing a great job with its tooling and approach. Compared to other language environments I’ve worked with (C, C++, Python), most common JS tools work in predictable, user-friendly ways...also they frequently have good documentation and “getting started” tutorials. It is good to see that the community is open to introspecting and improving even further
>also they frequently have good documentation and “getting started” tutorials. I tried making a TypeScript react app around Christmas, I found a tutorial, the commands did not work, I do not remember the details but it was using some bundler and probably the tutorial was a bit old and packages updated in npm. I found a different tutorial, to use create_react_app, I seen it uses npx(not sure when this tool appeared) i…
That’s hardly unique to Javascript. Back before the internet even existed I’d seen out of date make files which did nothing but spit out linker errors due to API changes in libraries.
Re: The melting pot of JavaScript (2017)
#94Earlier quoted context omitted.
Java uses reflection and annotations to support all kinds of language extensions. Js has a lot of nasty issues with the "prototype chain" and annotation support is still experimental. For example, in java, scanning your classes and their annotations to generate code for them at compile time is a standardized feature. Maybe I'm just complaining that JS is too dynamic, but being able to generate code at compile time wi…
Do you have any concrete example for "For example, in java, scanning your classes and their annotations to generate code for them at compile time is a standardized feature"? Tip: in JS, I don't want OOP class. If you really want class, could you show me the intention behind it?
Re: The melting pot of JavaScript (2017)
#95Earlier quoted context omitted.
Java uses reflection and annotations to support all kinds of language extensions. Js has a lot of nasty issues with the "prototype chain" and annotation support is still experimental. For example, in java, scanning your classes and their annotations to generate code for them at compile time is a standardized feature. Maybe I'm just complaining that JS is too dynamic, but being able to generate code at compile time wi…
Do you have any concrete example for "For example, in java, scanning your classes and their annotations to generate code for them at compile time is a standardized feature"? Tip: in JS, I don't want OOP class. If you really want class, could you show me the intention behind it?
Re: The melting pot of JavaScript (2017)
#96Dart? Elm? Clojurescript? Objective-J?
Re: The melting pot of JavaScript (2017)
#97Earlier quoted context omitted.
My $0.02 but that is NOT a reason to use JS on the backend. That is an argument to cross-train or hire someone. It's like saying "We only had an expert on building houses made with straw so we chose straw." Because they know the language doesn't mean for one moment that that will make a good background there are so many concepts, services, paradigms and best practices that the language is probably the least of import…
Yea sure, but removing the language as a thing to learn makes it easier to learn concepts needed for programing on the backend. Besides were using Typescript, have automated tests, code reviews and Manual QA, I'm not worried about the code not being solid or robust.
Oh god...
Yeah, no. None of this stuff is a substitute for actual code quality. Give me a good engineer that refuses to write tests over a mediocre one that does TDD any day.
Re: The melting pot of JavaScript (2017)
#98Earlier quoted context omitted.
Yea sure, but removing the language as a thing to learn makes it easier to learn concepts needed for programing on the backend. Besides were using Typescript, have automated tests, code reviews and Manual QA, I'm not worried about the code not being solid or robust.
> Besides were using Typescript, have automated tests, code reviews and Manual QA, I'm not worried about the code not being solid or robust. Oh god... Yeah, no. None of this stuff is a substitute for actual code quality. Give me a good engineer that refuses to write tests over a mediocre one that does TDD any day.
Re: The melting pot of JavaScript (2017)
#99Earlier quoted context omitted.
>also they frequently have good documentation and “getting started” tutorials. I tried making a TypeScript react app around Christmas, I found a tutorial, the commands did not work, I do not remember the details but it was using some bundler and probably the tutorial was a bit old and packages updated in npm. I found a different tutorial, to use create_react_app, I seen it uses npx(not sure when this tool appeared) i…
> I found a tutorial, the commands did not work That’s hardly unique to Javascript. Back before the internet even existed I’d seen out of date make files which did nothing but spit out linker errors due to API changes in libraries.
Re: The melting pot of JavaScript (2017)
#100Earlier quoted context omitted.
In JS there is a lot of convention but on a micro level. The times of monolithic Rails apps which have strict conventions are over and it's good: Too much magic and strict conventions often forced devs into patterns which didn't match the use case. Even experienced Rails devs tried to solve every problem the same way. You also confusing matters. You need Webpack, Babel etc for the frontend not the backend. And even i…
First, Webpack and Babel are totally used for backend. If you look at a lot of Node libraries, they use ES6 modules in their [docs]( https://github.com/graphql/graphql-js ). While you could use mjs for this, it's still experimental. I do think create-react-app is a good innovation in the JS world. However, I've never found a good equivalent on the back end. Setting up even the most basic CRUD REST API requires a whol…
This is where services like Google Firebase Functions become useful.
I went from having never written a REST API in my life, to up and running in under 20 minutes.
First time I went to create some endpoints on my own server, wow, that was a pain.