Let's say you'd like to write front-end code in a language that hides as much of the problems with JS as possible, preferably one that comes with a standard library, has elegant (or at least ergonomic) JS to interop and bridging, simplifies async code, and has a simple, integrated toolchain for targeting JS (all these amongst other things), what would you suggest? Basically what's the best language to write Javascrip…
The melting pot of JavaScript (2017)
161–170 of 200 posts
Re: The melting pot of JavaScript (2017)
#162I really like the kind of sanity that TypeScript brings to JS, super well designed and usually a pleasure to work with. That said, I've worked in many languages and I can't see any reason you would willing write your backend in JS or TypeScript. Java, C#, Rails, and to some extent Python are much saner choices. The massive churn of the JS ecosystem bleeds through to the backend, hard. JS could use a little more of th…
Sympathies to your valid concerns ... Though Java was 'designed', it was not 'designed' to be an http/web server. JS, particularly Node.js has really adapted itself to that well. And one small but massive difference: JSON is how data is passed and it fits seamlessly into Javascript, and doing JSON in Java is an ugly, ugly thing. As soon as you compare not JS/Java, but Java/Tomcat vs. JS/NodeJS - then you get a differ…
Why do you think so? Jackson and Gson work very well. Serialising and deserialising from/to POJO/JSON is trivial with them.
Re: The melting pot of JavaScript (2017)
#163Earlier quoted context omitted.
I've wanted to use Ember, but I've never bothered to sit down and learn it. What ever happened to Glimmer? I remember it being hyped up as a crazy fast virtual DOM, but I haven't heard anything recently.
It is super easy to pick up, you can understand the whole concept quite quickly. Follow one the tutorial and you will be ready to deploy new apps in days. One of my fav free tutorial: https://www.yoember.com
Re: The melting pot of JavaScript (2017)
#164Earlier quoted context omitted.
> I've found with experience and heavy linting you can avoid the vast majority of bugs. No, you can't. In fact, I can't even begin to see how "apply this specific standard to the code" (linting) is even remotely related to "know everything about this particular domain so you don't make any mistakes in creating an application for it" or "know everything about this particular system so that a given difference in config…
Linting is about so much more than code style and standards. Since we use auto format I have almost all the style checks off. What it does catch is hundreds of different types of potential bugs. Uninitialized variable. Missing null check. Deprecated or beta marked api used. Improper thread synchronization and double locking. Reassignment of parameters. Conditional check that's always true/false. This list is huge, an…
Re: The melting pot of JavaScript (2017)
#165Let's say you'd like to write front-end code in a language that hides as much of the problems with JS as possible, preferably one that comes with a standard library, has elegant (or at least ergonomic) JS to interop and bridging, simplifies async code, and has a simple, integrated toolchain for targeting JS (all these amongst other things), what would you suggest? Basically what's the best language to write Javascrip…
ReasonML
Re: The melting pot of JavaScript (2017)
#166True, maybe everything is different in large scale applications but I hate it if I find something interesting implemented in TypeScript and in 95% of cases I will just move on.
Javascript is not a beauty and any superset just seems like a facelift. The result looks like old and used car tires.
disclaimer: I am no web dev but somehow come in contact with JS frequently.
Re: The melting pot of JavaScript (2017)
#167Earlier quoted context omitted.
You never really learn javascript, you learn frameworks. I was a js developer about 7-8 years ago and dabbled with jQuery , dojo and the likes and then moved over to backend and mobile development. I tried getting back into javascript again and realized that I just could not get in and start coding. There are a lot more frameworks now that I have to learn to get started and I'm sure that a few years down the line, th…
Highly recommend vanilla JavaScript. With vanilla JavaScript you do not need any build tools. Instead of buying many different kitchen cutting and slicing tools - learn to use a knife.
Re: The melting pot of JavaScript (2017)
#168Earlier quoted context omitted.
> getting the return type of a method and getting the input parameter names (+ types) Type information literally doesn't exist at runtime, though. Isn't it kind of ridiculous to compare languages like that?
> Type information literally doesn't exist at runtime, though. Correct if I'm wrong, not all types get erased in Java. Doesn't type erasure only happen for generics? Say I have a non generic, plain Java class and want to inspect one of it's method's return types at runtime to see if it returns class A or class B. I can do that, right?
Re: The melting pot of JavaScript (2017)
#169Re: The melting pot of JavaScript (2017)
#170Earlier quoted context omitted.
> Java, C#, Rails, and to some extent Python are much saner choices. Python not as scalable, Rails is stagnating, the ecosystem doesn't evolve anymore/dying, doesn't play well with SPAs, C# weak to none ecosystem outside of Windows and devs earn a fraction, Java verbose and dev productivity subpar (there was a reason people came up with Scala), Java devs also suffer lower salaries
"Rails... ...doesn't play well with SPAs" Huh? Rails ships with built-in, no-config webpack support ( https://github.com/rails/webpacker#installation ) as well as install tasks for the most-popular front-end solutions ( https://github.com/rails/webpacker#integrations )