Ask HN: Is anyone else just tired of JavaScript?
I don't see what problems it solves. Rather, the "problems" that is solves are not really problems to me. I want to develop software in a stack that is entirely free of Javascript. Does anyone else ever feel this way?
46 comments
I don't care about JavaScript, but I love browsers as platforms; and as long as JavaScript is the de-facto language of the browsers, it will remain an important language.
My browser has essentially become my OS (ignoring gaming) Hell, I could even accomplish 95% of my software dev job fully within a browser with online IDEs like Cloud9.
I'm actually more excited than I have ever been in the JS ecosystem. Sure, there's framework fatigue, but ES6+ features have been a pleasure to learn and use, and picking up Typescript has been a serious boon to a more OO style approach to client side engineering. The previous two years have been refreshing.
Tired of JavaScript? Not particularly. Tired of the #hype around JavaScript and more specifically the constant frameworks of the week? Absolutely.
I don't think this is a problem unique to JavaScript, however. We see the same sort of thing around technologies. Right now it's ML and Blockchain, earlier it was Cloud and IOT. The industry in general appears to be mostly built on inventing problems that can be solved by the tech, framework, etc. rather than leveraging technology to solve an existing problem.
This may be part of why you're having a hard time finding the problems JavaScript may solve for you. Personally, I find it much easier to follow the "Just In Time Learning" model https://blog.codinghorror.com/keeping-up-and-just-in-time-le.... Find out what parts you need in order to solve your problems, learn how they work, and leave the rest until you need it.
I don't think this is a problem unique to JavaScript, however. We see the same sort of thing around technologies. Right now it's ML and Blockchain, earlier it was Cloud and IOT. The industry in general appears to be mostly built on inventing problems that can be solved by the tech, framework, etc. rather than leveraging technology to solve an existing problem.
This may be part of why you're having a hard time finding the problems JavaScript may solve for you. Personally, I find it much easier to follow the "Just In Time Learning" model https://blog.codinghorror.com/keeping-up-and-just-in-time-le.... Find out what parts you need in order to solve your problems, learn how they work, and leave the rest until you need it.
And I am tired of the "tired of JavaScript hype and new frameworks every week" speech.
It has a huge community, of course there will be new things created every week.
But, if it as bad you will not even hear about it, if you hear it is probably good or better on some aspects compared to others, who doesn't want that? do everyone wanted to be stuck with MooTools or JQuery forever?
It has a huge community, of course there will be new things created every week.
But, if it as bad you will not even hear about it, if you hear it is probably good or better on some aspects compared to others, who doesn't want that? do everyone wanted to be stuck with MooTools or JQuery forever?
The major problem is that when you learn something in this current crazy JS/Front world, your knowledge is deprecated 6 months later.
I know a developer should always stay up to date with technology by constantly learning, but if I compare what I learned 5 years ago in Python, I would say 95% is still relevant today.
But if I look at the JS "state-of-the-art" stack today, compared to the 2 years old, it's completely different.
It's very frustrating to invest time and effort to learn something and then hear recruiters tell you things like: "Hmmm no one uses that anymore".
Maybe because there is no need to evolve there?
I mean, you can see clearly why we came from jQuery, to AngularJs, then Angular/React/Vue, there was a need.
I mean, you can see clearly why we came from jQuery, to AngularJs, then Angular/React/Vue, there was a need.
This constant need to evolve is the exact definition of immaturity, for HTML/CSS/JS front-end.
I'm not a mobile dev, but I'm pretty sure when you make the front-end in an iOS app, you don't need to learn 3 languages + 2 frameworks + tooling to transpile + type checker + webpack...
Web front-end is completely broken because the foundation (HTML/JS/CSS) is not the right tool for the need.
I'm not a mobile dev, but I'm pretty sure when you make the front-end in an iOS app, you don't need to learn 3 languages + 2 frameworks + tooling to transpile + type checker + webpack...
Web front-end is completely broken because the foundation (HTML/JS/CSS) is not the right tool for the need.
Now that is a real problem, and it will not be fixed soon.
It is easy to a single company define how they want their platform to be, like iOS, but browsers are a different beast, as every change need to be agreed between several major companies.
It is easy to a single company define how they want their platform to be, like iOS, but browsers are a different beast, as every change need to be agreed between several major companies.
That's a totally reasonable sentiment and I can totally see how I didn't clearly articulate my feelings on the matter.
Of course we do want new tooling - ES6 and Angular in particular have worked well for me. Where I have some trouble is the tendency of some organizations to adopt these frameworks without considering whether the framework is actually solving a problem the have or expect to have in the near future. YAGNI is very tricky to get right.
Of course we do want new tooling - ES6 and Angular in particular have worked well for me. Where I have some trouble is the tendency of some organizations to adopt these frameworks without considering whether the framework is actually solving a problem the have or expect to have in the near future. YAGNI is very tricky to get right.
JQuery works fine for most stuff. Not every app needs to be implemented as a SPA app, in fact I think many are better of with a more traditional architecture and a bit of jQuery. These days even jQuery doesn't seem especially necessary.
JavaScript itself isn't the problem. The ecosystem is the problem. There is so much bad stuff out there that I stop reading articles about hot new software when they mention npm.
This is really vague. Javascript is necessary for building rich web applications. What are the uninteresting problems you see as Javascript's main purpose?
>I don't see what problems it solves. Rather, the "problems" that is solves are not really problems to me.
Then why do you use it?
Then why do you use it?
It solves the problem of "browsers need some form of embedded programming language". From there, it makes some degree of sense to also use it in the backend, to avoid multiple programming languages in the same codebase.
On the other hand, I've never written anything in Javascript. Maybe I'd have a lower opinion of it if my stack made heavy use of it.
On the other hand, I've never written anything in Javascript. Maybe I'd have a lower opinion of it if my stack made heavy use of it.
> I don't see what problems it solves.
It solves the problem of forcing a medium that was originally intended for documents and presenting information(the www) to support rich, interactive applications.
The whole html/css/js thing is a giant, ugly kludge, but it's what we're stuck with.
It solves the problem of forcing a medium that was originally intended for documents and presenting information(the www) to support rich, interactive applications.
The whole html/css/js thing is a giant, ugly kludge, but it's what we're stuck with.
I believe that's why Web Assembly (https://webassembly.org/) has been created. Eventually we will be able to use any language that can compile to Wasm.
Right now we can use any language which can be compiled to JavaScript. What will change? Wasm is not faster than JS.
For one thing, web assembly's architecture more closely matches the traditional backends that language designers are familiar with. Compiling to code to a byte code is a pretty much solved problem, and we have compilers that do this. Finally, while web assembly may not be faster than JS (although that really remains to be seen), it is faster to load.
AFAIK, today compilers are producing both asm.js code and Webasm binary. Webasm is for tomorrow, asm.js is for actual use, because it's backward compatible with any JS enabled browser.
Webasm is not so compatible. I tried to run random demo and got error message: CompileError: wasm validation error: at offset 8: binary version 0xd does not match expected version 0x1. WTF?
I tested https://webassembly.org/demo/Tanks/ demo, and on my system (Firefox, Fedora Linux 26), asm.js version is a bit faster to load than Webasm version. (Turn off support for Webasm in about:config to test). Asm.js: 1.57s to load from cache, Wasm: 1.82s to load from cache.
So what will happen when webasm finally more closely match traditional backends?
Webasm is not so compatible. I tried to run random demo and got error message: CompileError: wasm validation error: at offset 8: binary version 0xd does not match expected version 0x1. WTF?
I tested https://webassembly.org/demo/Tanks/ demo, and on my system (Firefox, Fedora Linux 26), asm.js version is a bit faster to load than Webasm version. (Turn off support for Webasm in about:config to test). Asm.js: 1.57s to load from cache, Wasm: 1.82s to load from cache.
So what will happen when webasm finally more closely match traditional backends?
Wait till you need to load a hundred binary dependencies and see if will load faster
My problem is not as much with the language but with the entire platform, I would like the DOM to evolve too, so far only the language was updated.
As a small example I would like to have a built-in dropdown/select that I can css it to my needs then to create my own using nested divs or use one made by others that may have corner cases or is not efficient.
I would also like some standard ways to show a modal, basically more standard APIs to be added to address the most needed things.
As a small example I would like to have a built-in dropdown/select that I can css it to my needs then to create my own using nested divs or use one made by others that may have corner cases or is not efficient.
I would also like some standard ways to show a modal, basically more standard APIs to be added to address the most needed things.
I’m tired of all the webpack crap, the endless battle of trying to match all its required plugins versions, 10000gb of node_modules and so on...
I feel the same way(js is fine for tying together a wbepage however).
I am now rewriting a startup's entire platform from PHP to js for no good reason. They claim they can't find any decent PHP developers and that js developers are easier to come by, yet here I am a PHP developer that has never wrote js outside the browser doing their js work?? Makes no sense.
I am now rewriting a startup's entire platform from PHP to js for no good reason. They claim they can't find any decent PHP developers and that js developers are easier to come by, yet here I am a PHP developer that has never wrote js outside the browser doing their js work?? Makes no sense.
I cant find any aspect of PHP being better than JavaScript
Time to re-skill?
To be fair, the language is in better shape today than it has ever been. The ecosystem, that is another matter.
Personally I'd love to completely ditch JavaScript. I'm eagerly following the progress of WebAssembly. I'm certain in 5 to 10 years the majority of front end dev will not be done in JavaScript.
Personally I'd love to completely ditch JavaScript. I'm eagerly following the progress of WebAssembly. I'm certain in 5 to 10 years the majority of front end dev will not be done in JavaScript.
JavaScript allows you to develop better UX for the user. Allowing for near-instantaneous feedback to the user.
No. Quite awake actually. JavaScript opens up a world of possibilities you cannot do with just HTML. It's the current platform of the browser app. If you are happy with static websites, that's great. Most people are not.
I mean... you could replace javascript with any other programming language and achieve the same thing. The choice of javascript as the language with which to access the standardized APIs is arbitrary. Browsers could have equivalently chosen any other sufficiently similar language, like Lua or Python.
You can still do that. There are many languages that compile to Javascript though I never saw the point in those (mostly because I'm very comfortable with JavaScript as a language)
If it wasn't because of Java the browsers language would be Scheme
> the browsers language would be Scheme
And the world would be 10000 times better off for it.
And the world would be 10000 times better off for it.
wounder if people would still complain
Of course they would. About the same things, in the same way.
Sometimes, but then I do some work in Java/.NET and part of me wishes I was using express/rails/django or something else lightweight. The grass is always greener
Yes. I'm tired of people getting so excited about using such a sub-par language in X environment.
Ignoring the browser side, show me a language that can do what nodejs can, as good as it can
not tired about JS, but in some cases I don't like that we keep reinventing libraries (for whatever reason), instead of contributing to existing ones to make them better.
ES7 and ES8 along with typescript are keeping things fresh IMO
Yes.
I am maintaining an Anglaur app just now. What a waste of effort. Everything would have been so much simpler if it was kept server side. Instead we have a ton of duplicated logic.
I am maintaining an Anglaur app just now. What a waste of effort. Everything would have been so much simpler if it was kept server side. Instead we have a ton of duplicated logic.
Stating the obvious, but that's the fault of whoever decided to do it in Angular and didn't understand the trade-offs of single page apps. If an app can be just as easily (or more easily) implemented server-side with no 'relevant' impact on UX, it probably should be.
It does give a bit more interactivity, but had it been up to me the majority of the logic would be server side with a bit of client side JavaScript. The amount of duplicated code for a very small amount of extra interactivity really doesn't seem worth the effort to me.
No
I once had to implement excel-equivalent UI functionality (resizable columns, etc) - using javascript - which needed to be compatible on both Netscape and Internet Explorer. Early 2000s, before jQuery or even prototype.js.
Which is another way of saying, don't talk to me about being tired of javascript...
Which is another way of saying, don't talk to me about being tired of javascript...