With WebAssenbly Autocad has been able to port it’s main C software on the web. I doubt this would have been possible in JS 
4 Likes
Will it be used on low-end smart phone?
That is where things are headed.
1 Like
And there will be a MobileAssembly
JS world is moving too fast for my taste, every update is a pain. I use it because I have too, but if I could replace JS with Rust code, I would be tempted.
In contrast, my Elixir code does not change much. Maybe new OTP behaviour, but syntax is similar.
4 Likes
I’m not saying Web Assembly will have no impact - I just don’t think it will be what people are hoping for - i.e. some kind of developer nirvana. There is always some technology on the horizon that will solve all our problems - and then it doesn’t and adds some of its own.
JS world is moving too fast for my taste, every update is a pain.
I expect the same rate of change to transfer to anything Web Assembly related once it is more widely adopted.
The good thing is that WA can be used to augment existing web browser capabilities for application specific requirements and possibly to prototype future web browser capabilities (typically browser native capabilities should still be more performant and resource efficient).
Hopefully many bloated heavyweight JS-libraries will be replaced with lighter and more efficient WA-based libraries. However what concerns me there is whether everybody will sufficiently pay attention to any potential inter-op issues.
Edge Compute is another interesting application area to move processing closer to the consumer without burdening the device on their end.
The bad thing is the potential for “Tower of Babel” syndrome. “Now I don’t have to use JavaScript” can result in the same language fragmentation that already exists on the server side. What is seen by many as a win - “Now I can use my favourite X” will ultimately make collaboration for WA targets harder because all collaborators have to be competent in the source language - of which there will be many (like TypeScript needs to be a WA source language 
).
Maybe that is a sign that some of your front end dependencies impose too much maintenance overhead in terms of their sustained rate of change. Could you possibly deliver the same front-end functionality with fewer npm package dependencies in order to reduce the rate of change those dependencies impose on you?
3 Likes
It’s not only code change, but eco system change.
- babel.config.js instead of .babelrc.
- Switching from webpack 2 to 3 was also painful.
As I use React, updating from 16.7 to 16.8 includes hooks… this was also a lot of rewrite.
Touché. That’s 100% accurate.
Highly unlikely to happen retroactively however. IT is a cost center to most businessmen and they religiously cut costs. When a project is in a sufficiently working state the chances of it remaining untouched for a long time (or forever) are hovering around 99%.
Yep. So this will, as you yourself mentioned, bring out a host of all new and fresh problems to solve for consulting money. Sigh. I really liked what one sysadmin friend of mine used to say: “I am looking to automate myself into unemployment”. Whatever happened to “technology will improve lives”?
That’s inevitable and apparently we’re going to suffer through that phase as well. Unless the browser vendors only allow 3-4 of those new frontend languages, which I believe would be a really good decision long-term, albeit authoritarian / oligarchic.
(Nevermind that it’s high time the backend languages got a thorough sweep as well; we have way too many. Cutting them down to even 25 would hugely improve our profession in general. But yeah, never happening, I am aware.)
Technology changes. People in general don’t. The IT area has a long way to go still before it is less chaotic.
From what I observe, 80% uses NodeJs (
) and the rest is PHP and Java.
It stays chaotic as long as people with no technical knowledge (Management) wants to decide all the technical things based on edgy trends and ranking lists.
1 Like
https://trends.builtwith.com/framework/traffic/Entire-Internet
NodeJS has high visibility due to being at the core of JS asset building pipelines.
Here in Germany, a lot of startups just go with a full javascript stack, for everything.
I can’t confirm…
Here in Hamburg most offers I receive are Golang, Java or PHP, even C++ was offered more often than JS to me. I have to admit though, that I’m not watching the market, but am open to offers.
Are they startups? I am working in an agency, we worked for 2 startups with a full NodeJS stack and ohne with Golang. A friend of mine works in a bigger company with Java but they also got some new services in NodeJS. Another friend works in a startup, also with a NodeJS stack.
And my boss struggles to find any client that uses Elixir or would be open to use Elixir in the future.
Dreamviewer and Frontpage? Yep, sounds very German.
1 Like
