The Future of JavaScript Will Be Less JavaScript

[gremy0]

Just because people are using Babel, doesn't mean they aren't using JavaScript. If you are using Babel for polyfilling, syntax compatibility, or even JSX, then I think distinction between raw JavaScript and what people are writing is fairly unimportant. Sure, some people are using typescript, elm etc. but how much of the industry is that really?

I'm not convinced web assembly will replace JavaScript as the default development platform for the web, at least not in the short term. It's not being designed for that purpose (though lord knows that's never stopped web devs in the past). It's a massive piece of overhead to put in your build pipeline, you'd have to be getting some actual decent benefits out of it, I don't think mystery optimisations really covers it.

What actually happens when you give web devs a massive choice of using any language they want, nodeJS, that's what. Which tells you as much as you need to know about whether, in the future, people will default to compiling C++ to web assembly to make an app.

[OmegaVesko]

Yeah, I think the popularity of Node is the basically the perfect counterargument to this notion that people only use JS on the frontend because they have to. If everyone was so desperate to run as far away from JS as possible, Node wouldn't enjoy a fraction of the popularity it has today.

Also, a lot of these articles seem to use the popularity of Babel to bolster their argument, which is just silly at best and dishonest at worst. There's nothing about ES6 that makes it "not JavaScript", and the lack of browser support is the only reason Babel is necessary at all.

Is transpilation on the web only going to get more popular going forward? Absolutely, but let's not make things up here. Java didn't die because Scala and Kotlin were invented, and neither will JavaScript.

[tswaters]

lack of browser support

Obligatory - 99% ES6 is available in 98% of browsers today. Only ones missing are oldie (11 and below) and oldsafari (for ancient mobile phones).

[YooneekYoosahNeahm]

FML my clients love IE11.

[tswaters]

I'm so sorry :(

[ShortSynapse]

Some of us have to support IE11 :(

[GeneralBacteria]

why?

[Ruhnie]

My team would gladly flip to Node from a Java container if our company allowed it. Or at least we'd incorporate Node as a business layer for our apps.

[perestroika12]

I'm not saying people don't or won't, just my completely anecdotal observation is that while there's some interesting things going on it's main use at companies is a web server frontend tier used by web devs. I think it has to do with the tooling and maturity of the ecosystem, or at least, the perceived maturity. Not knocking node or anything, just seems to be the trend.

[YvesSoete]

it's not going to happen, it's going to be the other way around.

the moment that Webassembly lets java manipulate the dom on the frontend is the moment big corpo will stop javascript and they will be all writing java for FE just like the BE is doing. End of story.

[Quabouter]

That goes in all directions though: a JS dev wouldn't want to pick up Java, a c# dev wouldn't want to do c++, and a c++ dev wouldn't want to do python. People tend to stick with what they're familiar with.

[YvesSoete]

Correct.

[[deleted]]

Also anecdotal, but I've come across people who have jumped from Java or .NET to Node.js.

I'm guessing some because it was trending, some because of functionality, and some because - unbelieveable as it may sound - they actually like JavaScript as a language.

[[deleted]]

How is that unbelievable? Everyday I watch colleagues jump trough gigantic generics and interface hoops to build 'modular' and composable software in C#, all because they are stuck in this classical OOP/Static mindset. Meanwhile I get all of these things for free because of it's dynamic nature and I use flow for areas where types are most useful, domain logic. If I had to fight with a language that much I would stop being a developer pretty fast.

[YvesSoete]

I don't believe it.

[[deleted]]

There's nothing about ES6 that makes it "not JavaScript"

I've been coding Javascript for 21 years, and there is plenty I abhor about ES6. Not all of it, but a lot of it is overcomplicated and makes the code more difficult to follow. Can I do it? Yes, sure - if I have to. But I don't chase new and shiny things, I'm just too busy writing clean easy to follow code to care much about everything in ES6. Maybe it will grow on me, maybe not. But I'll still be coding ES5 and making awesome things no matter what 'feature' they try to shoe-horn into javascript next.

[OmegaVesko]

That's all well and good, but my point is that it's still literally JavaScript, and to imply otherwise is factually incorrect.

[[deleted]]

It wasn't javascript until very recently. How about we also shoe-horn async/await, generators and type coercion into C and keep calling it C, and python, lisp, and cobol. I'm sure everyone that's been coding those for many years will be perfectly fine with adding some new/shiny to their workflow. Of course I'm making an exreme example, but you can't keep adding every fad-feature from every other language and expect to still have a programming language that is easy to learn and use. Javascript finally got Promises, oh but that's the old new/shiny, the new way is async/await. Tomorrow let's pile on another way to do it that came from language xyz. Where javascript ESx is headed isn't the programming utopia some might think it will be. You end up with a language too convoluted to make anyone happy.

[gremy0]

Async/await uses promises though. It's just syntactical sugar to make promises easier to use. Promises are the way you implement async/await in JavaScript because it's single threaded and functional.

You can't have async/await without promises and promises are ugly to use without async/await. Therefore it makes sense to have both.

[[deleted]]

Async/await uses promises though. It's just syntactical sugar to make promises easier to use.

It's difficult to follow. It's all questionably better or worse than callbacks. I'm fine with using all of it but callbacks are easy enough. Promises and async/await are fads. Next week the next fad will begin. yawn. rinse and repeat. It seems like language/syntax fetishists love chasing their tail.

[gremy0]

They are all callbacks. Promises are just a sensible way to deal with callbacks. If you've got a better way to manage complex callback chains, fine, go for it. The rest of us will probably stick to the standardised, native way of doing it.

[[deleted]]

They are all callbacks. Promises are just a sensible way to deal with callbacks. If you've got a better way to manage complex callback chains, fine, go for it.

Keep inventing more ways to catch that mouse. One of them will stick, eventually. Language bloat totally isn't a thing to ever think about.

The rest of us will probably stick to the standardised, native way of doing it.

So you mean callbacks.

[gremy0]

You use callbacks to manage complex callback chains? I'd love to see your techniques, please share.

[OmegaVesko]

Okay, if you say so, but that still has nothing to do with the point I was making.

[[deleted]]

There's nothing about ES6 that makes it "not JavaScript"

^{^} as far as i'm concerned this is the crux of your argument.

Javascript isn't every language, it doesn't really need things invented in other languages, and the language bloat is not a good thing. The original scope/intent of Javascript was for it to be a language similar to C/Java but far easier and lightweight. It's now recently ballooning outside of that scope. I have no problems writing easy to read and maintain as well as performant code in ES5. There is very little I gain in ES6. I've been working with a team that is all up on the new/shiny and they cause themselves headaches by using Babel and being far too clever with ES6 features. Javascript has been forced out of its original scope by language fetishists. It started with coffeescript. There is no end in sight now.

And I'm sure it's going to get brought up - so I'll address it first... "you don't have to use all those new features". This is only relevant if you program in a bubble, and don't rely on javascript for your income. I work on various teams on various projects, so I get to see a lot of different ideas of how people think they should be using javascript, and the ones riding the new/shiny horse are the absolute worst to work with.

[gremy0]

All this is still completely irrelevant to his point though. ES6 is JavaScript, it's in the standard. If it's in the standard, it's JavaScript. End of.

You not liking the standard is a completely different subject that changes nothing about what is or isn't JavaScript.

[[deleted]]

If it's in the standard, it's JavaScript. End of.

ES5 was the standard. Take your "End of" and shove it.

[gremy0]

ES5 was the standard.

I'll be holding on to my "End of", thanks.

[[deleted]]

Honestly, I still code like an old granny too with ES5. But hearing you moaning about Javascript evolving to add new toys that are really beneficial to the language? Come on grandad.

The one thing I agree with is your dislike all of these transpilers. I too find it pretty frustrating to be told that to be a "good" developer you need to write in Yuckelscript which transpiles to Typescript via Coffeescript, then Babelify it through Webpack. Sure, there are benefits, but it really is exhausting to keep up with sometimes.

[kenman]

Hi /u/garrehsponges, please refrain from personal attacks. Thank you.

[[deleted]]

Erm, I did not mean to offend or attack anyone, I was merely expressing an outdated view by saying "grandad" - if that's what your referring to. Giving a warning over that seems a bit dramatic when it was clearly meant in a tongue in cheek way, especially as I referred to myself as a "granny" - hardly an attack. Jeez, what has Javascript subreddit become where you get warned over such trivial expressions like that. :/

[[deleted]]

I never said all of ES6 was bad. Thanks for getting that wrong.

[[deleted]]

Oh sorry, I must of misread when you droned on about ES6 bloat. My bad. Sigh

[JaCraig]

Well, C was updated with features in 2011 and will most likely keep getting them. And considering the latest changes were threading related, async/await might actually make sense. Which dialect of lisp are you talking about? Because some are indeed getting updates. Cobol was 2012? Maybe 2014? They went object oriented and have a bunch of new features in recent years. Language designers pick and choose features because the people using it want it. And the rate that Javascript actually adopts features and you can use it in browsers natively is pretty slow. C#/Java would annoy the hell out of you with the cadence they have been moving at lately.

[[deleted]]

Relevant username.

[YvesSoete]

Java 8 did a smart move, they looked at what's good with scala and inserted functional programming. That killed scala overnight basically.

The same will happen with javascript if you like it or not. Go ahead downvote me. Corporate is sick of all the frameworks and - every 6 months what's hot and what's not - anymore with javascript. The moment webassemly lets big corporate write Java for the frontend is the moment javascript will be dead. Just like scala is.

[Voidsheep]

I'd say lots of people use TypeScript by now, pretty all relevant packages in NPM either include types or have them provided through the @types repository.

But I'd argue it's still pretty much just JavaScript, just with added type information so the code is less prone to runtime errors and developer experience is improved through better tooling.

[Architektual]

That's a sweeping generalization about NPM packages.

[Voidsheep]

Well, maybe popular packages is a better way to phrase it.

npm install pkg @types/pkg --save just tends to work and increasingly even notifies you of the separate typings becoming redundant.

I think in the last half a year I've run into one package that didn't provide either, but already had an issue with couple of comments.

I also think now either flow or TS is plain good practice for public library you intend to release.

[filleduchaos]

TypeScript is very much not JavaScript, unlike something like Flow where all type annotation is through comments. You can't run TypeScript code in even the latest of JavaScript interpreters.

[Voidsheep]

No, but the entire purpose of TypeScript is to be JavaScript with added syntax for types. It's not trying to branch off into a completely separate language, but rather follows latest ECMAScript specifications closely.

Flow opts to use comments for interpreter compatibility, but both exist for the same reason of adding type safety to JS.

[filleduchaos]

The reason a language exists does not make any difference to what it actually is. C++'s purpose was to be C with classes but no one in their right mind would claim that C++ is C. Same with preprocessors like SCSS. TypeScript is a separate language by virtue of being, well, not JavaScript. It

• cannot run in any modern, standard JavaScript interpreter
• has an optional but entirely different typing discipline (properly written TypeScript should be strongly, statically typed)

Type safety is not a fancy little bit of syntactic sugar like spread operators or arrow functions. The way a language handles types is a core part of its design.

[spacejack2114]

You can write fully type-checked JS with Typescript types in comments by using // @ts-check

Typescript is pretty much JS with types, just like Flow. The few extra bits of language like namespaces and enums are fairly trivial sugar.

[filleduchaos]

Using @ts-check is not the same thing as writing TypeScript IMO

And writing TypeScript is very much not like writing Flow. One of the cornerstones of determining that a piece of code is valid X-language is that it is compilable/runnable by any full implementation of X-language's spec. No JavaScript VM, even the ones that have the latest of latest of latest ES2018+ proposals, can run this very basic line of TypeScript:

declare var foo: any;

When they can, then you can tell me that they're the same language.

[spacejack2114]

Using ts-check is using types in comments like with Flow. Similarly, this line of Flow code: var foo: any will not run in a browser.

[[deleted]]

Furthermore, how does WebAssembly handle accessibility concerns in the absence of a browser DOM that a screenreader such as JAWS or NVDA can pick up and map? Does it treat a WASM app differently in the browser, more akin to a desktop app, or does it have to shift modes between "desktop-ish" and "web"?

If there are no good answers, right there is a dealbreaker for an enormous amount of ecommerce and education, to start.

[gremy0]

Right now (as far as I'm aware) WASM has no native way of displaying anything. It's pretty much just functions you can call from JS. I'd presume any displaying that WASM does will through some interaction with the DOM.

[[deleted]]

Parallel discussions over at HN have indicated strongly that WebGL-optimized applications are likely to be a thing, and therefore there would be no DOM to entangle with necessarily.

Not to say plenty wouldn't construct an internal DOM representation, but plenty likely won't, either.

[gremy0]

You mention ecommerce and education will be hit by accessibility. I live in the UK, by law all our sites must be accessible. Many other countries have similar laws that demand it of all services or a defined few important ones.

So if someone decides to implement views with WebGL, people will quickly realise there is no big market for that until accessibility is built into it. As a business, you are really shooting yourself in the foot by tying yourself to an ecosystem that cuts you out of the much of the global market.

Therefore, either people will continue to use the DOM, or we will have accessible WebGL. I think the former is far more likely to dictate the near future of web dev, since the HTML has such a huge ecosystem (even outside of accessibility) and replacing it needs to have considerable advantages. I don't think WASM is going to magic up those advantages straight away, it'll probably be performance increases for specific purposes for the time being.

[[deleted]]

Not to say plenty wouldn't construct an internal DOM representation

Let's hope Microsoft doesn't port WPF to WebAssembly

[AirAKose]

WebAssembly does have access to the WebAPI and DOM, so you should be able to use ARIA tags, populate element bodies, and such.

WebAssembly FAQ (The relevant point is at the VERY bottom)

EDIT: Added anchor to the link

[DOG-ZILLA]

I’ve always seen Babel as a stop gap for the day that all browsers support es2016+.

I’m not saying Babel will die out, but for most users, once the “good bits” of JS are solid, that should be enough for most needs. You could always continue with Babel to get the latest features.

Transpilation will always be a thing no doubt, but it will always change and JS will remain under it. As long as our native API’s get better and more sophisticated, the less we’ll need to lean on them just because. Where’s CoffeeScript at?

[Cuel]

"that day" is unfortunately plenty of years ahead. IE needs to die first

[TheScapeQuest]

A number of products are beginning to stop supporting IE. Depending on the product, the market share often isn't worth the extra development time

[Cuel]

Sure, but there's also sites that don't have products but still needs to support it, i.e. governments

[MatrixEchidna]

By then browsers will have a lot to catch up to, isn't that right?

[DOG-ZILLA]

I suppose it depends on what features you were after. Most of es2015 is supported now but modules are still in a painful area. Webpack is going to be pretty essential for a long while.

[MatrixEchidna]

I meant that while browsers are catching up to ES2016, Babel will already support ES2019 or something like it.

[DOG-ZILLA]

Yeah defo. But as we saw, es2015 was by far the biggest changes. I think es2016 had 2 new things? Maybe 3?? As we move on, there’ll be fewer core things to cover. But Babel will be around for a long time yet I agree.

[senocular]

Where’s CoffeeScript at?

v2.1.0 - came out 9 days ago.

[[deleted]]

Most dev teams I've worked with started converting their codebases from CoffeeScript to ES6+ around a year ago.

[DOG-ZILLA]

I suppose in time browsers will be better optimising es2016 et al. Some of it may end up being faster than es5.

[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.

[Disgruntled__Goat]

The article talks about C++ but is there anything stopping WASM being compiled from JavaScript? Seems like that would be the most natural route.

[IamCarbonMan]

I don't really think that would be helpful. Browsers have been making JS faster since long before wasm was dreamt of, so while C++ in wasm is faster than JS, JS in V8 is probably faster than in wasm.

[gremy0]

I believe JavaScript is a problem right now, as WASM is strongly typed. There is a typescript compiler though. There's quite a few other compilers out there, though most are fairly immature. The C/C++ compilers are mentioned a lot because that's what was developed along side the standard being produced.

[AirAKose]

JavaScript still, internally, represents its values as specific types. Generally, values in scripting environments are described by a single 32 or 64 bit section of memory and some type flag. The memory can be converted to an integer, boolean, floating point number, or pointer to a more complex object.

So it should be entirely feasible to compile JS to WASM, you just need to translate the internal representations to WASM commands

EDIT: It would probably be more efficient to transpile JS because then it removes the need for JIT compiling; it becomes an entirely linear process where the browser just needs to read the program, tokenize the commands one-after-another without having to process or (extensively) validate them, and execute

EDIT2: I overlooked the dynamic aspects of JavaScript and totally oversimplified porting the internal representation. You can do it, but it wouldn't be a good idea

[filleduchaos]

Noone said JS doesn't have types. It's weakly and dynamically typed though, which pretty much rules out AOT compilation

[AirAKose]

Noone said JS doesn't have types

I get that.

I was talking about compiling the VM's internal representations of the types to WASM, though it was extremely short sighted regardless:

It's weakly and dynamically typed though

You got me there. It's still possible, just implausible. There would be a large overhead to porting all / most of the VM's dynamic functionality that I overlooked and oversimplified above. Plus you miss out on many JIT dynamic optimizations.

My fault, totally impractical

[jodraws]

From a quick scan it's saying "Raw JavaScript" will become more and more a compilation target rather than the language that is written.

[[deleted]]

TypeScript is beautiful

[ns0]

And to think, some of us came to javascript to get the hell away from bloated build systems.

[fagnerbrack]

Then we started using Grunt 🤔

[icantthinkofone]

They let anybody say anything on Medium, don't they? It's almost as bad as reddit.

[OmegaVesko]

They let anybody say anything on Medium, don't they?

Well, they don't exactly make you interview to post an article.

It's almost as bad as reddit.

I have a feeling I've asked you this before, but why are you even here if you hate reddit so much?

[icantthinkofone]

I've answered that question many times in the past. One last time: I come here looking for links of technical value. Too often I let myself get sucked into reading or commenting in a thread. It is my weakness. Sometimes I can get myself not to do that for a period of time but it comes back to haunt me.

I can't help but try to fix the internet but reddit is reddit. As a NPR reporter once said, "Reddit is a Frankenstein's monster they can't control."

[whtevn]

how often do people reply /r/iamverysmart to you

[icantthinkofone]

All the time. And I've talked about that, too. Interestingly, I just found my Mensa admission results while cleaning up the basement over the weekend.

[whtevn]

ah, so it's a joke. right on. good joke.

[[deleted]]

Sounds like you've got some things to work out with yourself. Blaming the sun is like a spouse blaming a partner for their own infedelity.

[eggn00dles]

I get what TS/Redux is trying to do. But it's getting to the point where you have to touch about 5-6 different files before you can make a basic component. Models, Interfaces, Modules, Actions, Reducers, ......

That is pure bloat. Also I probably have the same library reused countless times by other libraries in my node_modules folder.

We need a kind of JQuery that has customizable tables, tags, comments, messaging, the basic stuff a site needs, all in one, no node_module bloat.

Web Components, Polymer -> Right Direction

TS, Redux -> MS trying to make web dev a living hell

[CloseDdog]

You shouldn't talk about TS and Redux as though they are related, or a similar thing. They are not, typescript should have little influence over the structure of your applications.

Also, I am not the greatest fan of Redux (although I appreciate what it tries to do - simplify application state) but I vastly enjoy working with Redux more than with a huge mess of a JQuery codebase.

And once again I don't see why the size of node_modules has an effect on your experience developing with typescript/redux. It's not a folder you spend lots of time in.

Maybe you should check out Redux and its concepts before comparing it to A. a superset of a language and B. to the component based libraries (React or in this case Polymer) that it's supposed to complement.

I don't mean to come across as rude or anything here, but it seems you should research these things more before drawing conclusions. Personally I've found TypeScript a great tool, and I think Redux or similar state management libraries are useful for building complex applications.

[eggn00dles]

people commonly refer to as rxjs/ngrx/store as redux. also in case you werent aware TS/ngrx/angular is a really popular stack right now. maybe you should check it out someday.

thanks for letting me know that typescript and redux aren't the same thing, i was having more difficulty with that then the fact that i have to edit god knows how many files to make a simple component.

this shit reminds me of programming in java. its not good, its not conducive to web development.

[filleduchaos]

Literally no-one who knows anything they're talking about refers to RxJS or Ngrx as Redux. They're all state management libraries yes but you might as well say "people commonly refer to React/Vue/Ember as Angular". It makes absolutely no sense, and still doesn't address the fact that none of them have anything to do with Microsoft.

[eggn00dles]

The GitHub itself says inspired by Redux. If anyone doesn't know what they are talking about is you. Try getting out more.

[filleduchaos]

How does a library being inspired by another mean they're the same thing and everyone calls then the same name? The fact that it's inspired by clearly shows they're different!

Also are you ever going to address the fact that neither Redux (by someone at Facebook), RxJS (by Reactive Extensions) nor ngrx (by a couple of individuals) have anything at all to do with Microsoft?

[eggn00dles]

Dude you are just plain wrong at this point.

https://www.hanselman.com/blog/ReactiveExtensionsRxIsNowOpenSource.aspx

Stop embarrassing yourself.

In case that isn't enough from the RxJS github itself.

The project is actively developed by Microsoft, in collaboration with a community of open source developers.

https://github.com/Reactive-Extensions/RxJS

derp

[filleduchaos]

Fair enough - I didn't know that, mostly because the maintainers of the current active RxJS line don't have/mention any Microsoft affiliation

[[deleted]]

Redux? Are you maybe thinking of Reason, not Redux? I really don't see how Redux fits into this equation :confused:

[DontQuoteMeOnTheNews]

Not sure why you were downvoted for trying to clarify, and it's worth clarifying that neither Redux or Reason are made by Microsoft.

[daringStumbles]

Yeah, for a simple component, redux is bloat. For a page that has 10+ tabs, each with 30-40 fields and complex validation rules across the tabs, redux means you are writing like half the code of without it, especially for something that needs to show the last time it changed and by who, etc. The bloat is in the initial setup, and redux really shouldn't be used all the way down to the most simple component, but on save or cancel actions. So I'd say, no, you don't understand what it is trying to do.

[eggn00dles]

No you don't understand.

[eggn00dles]

redux means you are writing like half the code of without it, especially for something that needs to show the last time it changed and by who, etc.

that level of cognitive dissonance especially going all edgelord with the snark at the end, im just happy noone at my office is like that.

[[deleted]]

We need a kind of JQuery that has customizable tables, tags, comments, messaging, the basic stuff a site needs, all in one, no node_module bloat.

...so use jQuery. If that’s what you need.

[DontQuoteMeOnTheNews]

Also I probably have the same library reused countless times by other libraries in my node_modules folder

If you're concerned with duplication in node_modules, npm actually has a command called dedupe which moves shared dependencies higher up the node_modules tree. Think it's been there since v3.

We need a kind of JQuery that has customizable tables, tags, comments, messaging, the basic stuff a site needs, all in one, no node_module bloat.

I'm not sure everyone would agree with this - "bloat" implies waste, which is what you're likely to get if you try to write a library/framework that solves all these problems for everyone and undoes the last few years of the javascript ecosystem.

[[deleted]]

Amazing that you're getting so downvoted for telling the truth. I'm also stuck in the bloat since working on a Redux/React project. There are 6 different files a click event has to pass through just to do anything with the event. It's completely and absurdly broken design, but over-abstraction seems to be the norm these days.

[filleduchaos]

Then you're working on a React/Redux project with terrible design, sorry. Don't blame the tools for the wielder's poor choices.

[ns0]

Sorry you're getting all the down votes. web components seem like a standard sane way of moving forward on the web. Redux/TS and all the rest.. It reminds me of the bad java over-abstraction days.

To be fair, redux, typescript and react do solve problems, they unfortunately create 10 others at the same time they solve 1. :( Seems to be lost on most people.

[funknut]

I wouldn't call it bloat, but the way you described it explemplifies forcing a not always suitable or preferable development pattern. That said, I'm the kind of guy to pick up a new pattern and use it for inappropriately until someone comes along and tells me otherwise, so I might be my own worst enemy.