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
[ 6.2 ms ] story [ 105 ms ] threadI 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.
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?
Then why do you use it?
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.
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.
And the world would be 10000 times better off for it.
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.
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.
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.
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.
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?
I mean, you can see clearly why we came from jQuery, to AngularJs, then Angular/React/Vue, there was a 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.
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.
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.
Which is another way of saying, don't talk to me about being tired of javascript...