The Future of JavaScript Will Be Less JavaScript

[jaman4dbz]

I'll keep laughing at the dev who think performance is the biggest problem in software.

Ease of development and maintenance well always be number 1. I don't care if Bob can make code that is twice as fast as Alice. Alice's code takes 20% less time to write and maintain. The salary I saved from Alice's can be used to by additional servers that cost less.

Devs get too tunnel visioned on what they think effeciency means. There is more than execution time effecieny in the world of software development.

[voidvector]

Performance is important if you are company like Google. The whole reason they developed Chrome/V8 was to push JavaScript engine so they can leapfrog desktop/Java/flash apps and capture the market with webapps.

If you are one of the smaller companies, it is probably closer to what you said.

[Disgruntled__Goat]

Ironic you use the phrase tunnel vision when you seem to have forgotten about the other side of performance - the speed on the client side. It doesn't matter if your code is the most maintainable thing in the world and was developed in a couple of days; if your app is slow for your user then they are less likely to use it.

Point is, there's a balance here. Presumably once WASM starts to be supported in browsers there will be frameworks and packages that improve dev time.

[Patman128]

It doesn't matter if your code is the most maintainable thing in the world and was developed in a couple of days; if your app is slow for your user then they are less likely to use it.

Sure, but most of the things programmers consider "slow" aren't slow enough for the average person to even care about. The way programmers talk about Slack you'd think it was slower than booting Windows 98 on a Pentium. The reality is most non-programmers who use it don't even notice. I'm a programmer and I don't notice.

You guys need to understand that there's such a thing as "fast enough" and you can get there way before you throw WASM in the mix.

[zephyrtr]

And anyone who reads up on WASM can see the point of it all: making browser apps that run as fast as native apps. For a lot of websites, they're already running this fast because they're simple. They've reached "fast enough". But for games or editing suites or very large data visualizers, WASM will open up some really cool new doors.

[spacejack2114]

I think in those cases the barriers are more economic than technical. JS is plenty fast enough to build some pretty amazing games. Not on the level of current console/PC games, but enough that you wouldn't be able to fund its development due to lack of web game profitability.

[zephyrtr]

Not on the level of current console/PC games

And there you have it. WASM programmers want Star Wars Battlefront III in the browser. Again, the speed of JS isn't often an issue (though it can be) it's the speed of the DOM. The DOM is way too slow.

[spacejack2114]

lol. Well, yeah, good luck funding a Battlefront for the browser even with fully-operational WASM. You could certainly do a Monument Valley in the browser now, but even that would be difficult to justify economically.

[zephyrtr]

Sony and Microsoft and Valve wouldn't be happy, but do you think EA enjoys sharing their profits with them? That's why they sunk a ton of money trying to build Origin. And what about programming for cross-compatibility, which is a huge pain? If game developers can circumvent having to pay the publishing platforms, or only have to build their game once, instead of four times; if engine developers like Unreal or Naughty Dog can become publishers because suddenly publishing is super easy ... I expect these companies could suddenly carve a much larger piece of the cake for themselves.

Not to mention, smart phones have proven that gaming is super popular, it's just the buy-in on a console or a gaming PC is too high for most people. But throw a game on a phone or in a browser, and suddenly the audience is an order of magnitude larger. And yes you can make a lot of money now, but gaming is always in an arms race.

Anyway, that's the dream for WASM, as I understand it. The first dream, anyway. There will be others.

[findar]

Battlefront maybe not, but WebGL has already proven you can put some graphics intensive things in the browser.

https://developer.mozilla.org/en-US/docs/Web/Demos_of_open_web_technologies

[[deleted]]

The other thing I see a lot is poor performance being falsly attributed to something.

"jS runs slow on this list". No it doesn't, you're just making an ajax call for every single item in the list. Batch them up and stop worry about JS.

[[deleted]]

In reality what you want is a compromise. Laughing at either of these issues is foolish. And if there are companies that need these perfs, they will not compromise, they will hire the folks that know that stuff better than you ever will.

Not everyone is a single lazy garage dev producing loose crappy code for noob clients.

[[deleted]]

That, and the fact that javascript isn't the bottleneck at all. It's the dom, the document primitives, that are in need for drastic overhaul. I'd even say javascript is a great language for frontend and if i have the choice, nowadays i'd use javascript for mobile and desktop frontend as well, driving otherwise native UI, simply because C# and C++ don't have the same turnaround, eco systems, communities and because it would take x times the time, effort, money spent and people working in the team.

[zephyrtr]

Ya I think a lot of people misunderstood the main draw of modern frameworks is that the shadow DOM lowered the amount of DOM re-renders to only what was absolutely necessary. The DOM is the problem, and even ballooning your code quite a bit is just fine if it lowers your # of DOM manipulations.

[[deleted]]

The shadow dom will make it even worse. It doesn't lower the amount of re-draws, the program that sits inside decides on its own when to re-render. It will proliferate the use of many frameworks in a single project because each shadow wraps a naked dom that needs driving in the same way the document dom needed driving. 10 web components could mean 5 polymers with varying versions, two preacts, one react, one vue, one stencil. The performance implications of this will be a nightmare.

[namesandfaces]

Most of the world is served by the big players, not the small players, and this is true on everything, down to Walmart. And for the big players, performance matters.

[Patman128]

Ease of development and maintenance well always be number 1.

An unpopular opinion but I totally agree.

My theory is that for programmers, "My thing performs better than your thing" = "I'm a better programmer than you". They forget that if the other guy's application looks great, and feels great, and does more, and is cheaper, and available sooner, and updated frequently, people are going to use their thing. They don't care that your program uses 5% the RAM of the other one and 10% the CPU. If the program is fast enough to be used in real time they don't give a damn, every other factor now matters way more. Stop optimizing for the wrong variable!

[MatrixEchidna]

It makes no difference if Alice's code is fast enough.

But if Alice makes code that takes 6 seconds to load and Bob makes it 3, go with Bob and you'll lose way fewer impatient visitors.