I've Waited YEARS For This JavaScript Feature...

Omgomgomg we're finally getting pipeline operators in javascript
#t3stack #fullstack #webdevelopment
ALL MY VIDEOS ARE POSTED EARLY ON PATREON / t3dotgg
Everything else (Twitch, Twitter, Discord & my blog): t3.gg/links
S/O Mir for the awesome edit 🙏

[@ruaidhrilumsden]

"Programmers don't love naming things, programmers love programming." Couldn't have said it better. As I was watching this I was thinking 'this is kinda like why Tailwind is great'. I suppose great minds think alike!

[@nathanfranck5822]

Typescript has really helped me not to worry about the names of things, since it's trivial later to do a 'rename' refactor on a name that no longer matches it's data or usage. I often start a type definition or variable declaration with 'let thinger = ...' so that I can fill in the variable first, use it, and then stare at my code and figure out what 'thinger' should be named now that it is filled in and used, it's funny that this works but it's super effective for me.

[@CottidaeSEA]

@@nathanfranck5822 I name stuff result more often than I'd like to admit. Though to be fair, it's a very good name for most scenarios. Since I tend to declare variables early, it also allows readers to know immediately what is going to be returned.

[@jonnylukejs]

but do we "love" programming or do we love hating ourselves?

[@CottidaeSEA]

@@jonnylukejs I love calling people idiot, even if that idiot is me.

[@alexg4927]

Id rather say programmers don't like to think about unnecessary stuff. I tried Tailwind and even though I don't have to think about naming, I have to make my way though long lines of utilitary classes. And that's really annoying. The same issue arises when U have to think how to put into Tailwind some stuff that I might easily do with Css or Scss And another problem is that utilitary classes become so difficult to read especially when there are more than 10-20 of them for one JSX tag. I have to re-read again and again until I find what I'm looking for

[@Darkitz69]

Don't like the hyping up too much, but seeing proposals is really cool. Maybe you could do a video just digging trough a few proposals and explain the use-cases? (negative ones aswell, please) Or a video for each one. Seeing things move in javascript (and libraries) makes the ecosystem feel more alive and is great.

[@CottidaeSEA]

Disadvantages: Another peculiar operator you need to know. Awkward symbols, a pain for international keyboards. If logging needs to be done, the chain needs to be broken which means refactoring the entire function to keep the result the same if you do not wish to add logging in the implementations. Advantages: No need for reassigning values. Linear flow, makes it easier to read without the nesting. Possible performance gains depending on implementation. That's about all I can think of. I'd say better to have it than not, but I'm not too fond of it myself. I prefer the Visitor pattern in OOP, which is the equivalent of this. This is much faster to write out though, less structure necessary.

[@TheChodex]

@@CottidaeSEA "Awkward symbols, a pain for international keyboards." - I don't agree with this, | and > are very common symbols for any programmer - you need | for "or" statement, and you need > when doing comparisons, so "pain for international keyboard" is invalid argument

[@howdyimflowey4341]

@@TheChodex They are very common, but when typed separatedly. In spanish keyboards for example, the keys are located in completely opposite sides of the keyboard, and you need to use two different modifiers (shift for > and altgr for |).

[@thefeymesaleng]

@@howdyimflowey4341 man of culture 👏👏

[@CottidaeSEA]

@@TheChodex |>% all three are necessary and they all need some sort of Alt/Shift combination. While they are all used, you rarely use so many of them in succession. That's why they are awkward.

[@arturmuellerromanov4438]

I don't know if to love or hate this channel. Sometimes it's infuriating, sometimes enlightening. Guess that's properties of fire.

[@dongueW]

😂😂

[@yestermonth]

Same opinion here, still the reason I haven't subscribed yet 💀

[@pranitrock]

I have used the single line approach before guess this is way more readable for later when you come back to that code.

[@eberechiuche799]

Hey Theo, love your videos a lot, always learning a bunch from you, as an entry level dev I could just watch your videos and see your approach to things and your rants and I can instantly know what not to do and what to do. Thanks a lot

[@fredericorinco9133]

Pipes as type guards for typescript will be SO GOOD too. I can't wait for TS to support it after it's released xd

[@davidoriley]

In the meantime i've used the functional programming library "Ramda" which has a piping function to make piping a little less painfu. Its got some other pretty useful stuff too. But having piping adopted to native javascript would be *chefs kiss*

[@geeksy2278]

Great! Used in Elixir which is a great language

[@avi12]

While the pipe operator seems very cool and useful, you should be very careful with it 1. If you have too many pipes and one of them has a bug, good luck debugging, especially if they're one-liners 2. It makes it far less readable I'm a "const" kind of guy, i.e. I'd rather name everything to make the code readable than use "let" and reassign variables, making the code far less predictable

[@OryginTech]

You missed the plot here entirely

[@whatplan4335]

For 2, the thing is most of the time this is unnecessary and requires a lot of thought to name it something appropriate, where pipes allow you to just clearly show the flow of data from function of function. If you want to add a name, it’s very easy to add in an in line comment.

[@ocwebdesigndev54]

1. For implicit bugs, can easily add pipes in between pipes for logging the value tranformations. For explicit ones the stack trace can easily have "error at doSomething pipe#3". Or if not, then you still have at-line or at-function error logging and it shouldn't be too different 2. With one-off anonymous pipes I see your point. However at scale it should force creating smaller functions to make the piping readable which would improve readability and DRY throughout a codebase. Overall, people who write bad code will write bad functional code. There are tradeoffs but piping does make some situations more readable

[@DryBones111]

Bugs aren't so much of an issue if you embrace functional composition, making use of strong static typing, and keeping the code declarative. And the few that sneak through will be caught in your tests, which are now extremely simple to write. Also, pipes are equivalent to using const at each stage. Nobody will be mutating those values before they're passed on to the next function.

[@JonLynchIsAlive]

Ocaml has this as well. Javascript is my first love, so this would be awesome to see. Hope it makes it in!

[@UliTroyo]

This is great! Nushell made me a convert to pipes recently.

[@MarthinusBosman]

I like these weird-newsy-thing-that-hasn't-happened-yet-but-you're-hyped-about-it videos

[@somebody656]

pipe in elixir is so good. I implemented something similar in Scala 3 using extensions

[@Loige]

Elixir fans will be ecstatic! Btw it might be interesting to do a deep dive and show how you could use the pipe with promises... fetch is the first example that comes to mind (step 1: make a request and get the response, step 2: extract the response body, step 3: process the body somehow).

[@milesparker557]

Before I clicked on this video, I didn't know what piping was. Now I'm excited to get it!

[@barjo_]

I really hope for functions that have only 1 param you can purely pipe functions together like in Unix. Eg: return x |> addTwo |> square |> square |> square

[@Jeanpierrec19]

I would be fine with being able to call any function on a type. So let x = 10; x.addTwo().squared(); return x; This would be difficult in JS though but in TS where the type information is available that would be great.

[@zzzyyyxxx]

Check out Dart, it has "extension methods" for exactly this use case.

[@OnFireByte]

Nim have something similar to this too, pretty neat

[@Jeanpierrec19]

@@zzzyyyxxx yeah but it's dart... Many languages has this.

[@snailedlt]

Piping will be insane! It's one of the reasons why bash is so powerful with a very basic "standard library", and I can't wait for Javascript to get it!

[@Baraka0369]

What I find really really cool in dart is the .. operator to chain function

[@headlights-go-up]

100% enjoy these types of videos.

[@igrb]

how did I miss this?? can't wait for this kind of functional stuff omg Now I wanna see prime nerd out about pipes and garbage collection because I don't know what happens since there's no variables defined 🤔

[@KeganVanSickle]

This would be great to see in vanilla JS. Thanks for the update Theo!

[@pauloffborba]

I'm using those pipes in Elixir lang and it's really awesome.

[@MrGarkin]

export const piped = (x: number) => addTwo(x) |> square(%) |> square(%) |> square(%);

[@whynotdean8966]

4:21 Oh yeah, so readable. FilterObject(UnkownObject)|>DoWork(%)|>%?UnkownFunction(%):OtherFunction(%)|>%??{} Makes perfect sense.

[@ShawnShaddock]

This is awesome, have you done anything with fp-ts? The pipe operator will be lit with fp-ts

[@DryBones111]

While I love this proposal, I really dislike the % syntax. Piping should use a function reference instead of an invocation. This does mean that you can only pipe arity-one functions, so this proposal should be paired with a tidy way to do partial application. Preferably something that looks cleaner and doesn't have the same overhead as creating a new lambda/arrow function.

[@fluffydoggo]

At first was disgusted, but the use cases start adding up. Take for example builders. This could now allow functional programming to use builders without using builders by piping stuff down.

[@patricksmith8262]

Loved this when i encountered it in Elixir.

[@chiubaca]

Oo I feel like this could make using faunaDBs js SDK so much easier to work with.

[@taureon_]

i think this may be a bit confusing because the return statement has stuff running after it, so if it gets added i would put it all in a temp variable and return that

[@yapet]

We already have method chaining, which looks exactly the same, yet I don’t think it’s a concern when writing returns. Same goes for jsx, I feel like. There is a lot of code run, before return is evaluated. I don’t feel like this needs to be accounted separately for.

[@taureon_]

@@yapet i forgot about method chaining because i dont use methods a lot, my bad

[@hamdysaadpersonal]

that's actually great

[@Souljacker7]

That's dope!

[@snatvb]

pipeline operator has stage 2 more than 2 years...

[@jordandomovcijski2293]

I love this new concept, the only thing I am worried about is what if you get bug in one parts of the pipes. How hard it will be to debug it?

[@robertholtz]

I’m sure they’ll address that in debug/console somehow. I’m guessing these values will cascade as part of the return value of any associated function calls.

[@ivanrenescorcia]

Love it!

[@jankoprowski]

How about debugging/breakpoints? Whether I will be able to egzamin the intermediate values and put breakpoint anywhere between those pipes?

[@janjac8619]

If this comes, im only scared of refactoring the codebases

[@ErnaSolbergXXX]

Guess I'm too old when I feel this just create a mess without any clear benefit.

[@appuser]

Huge! This is awesome. I wish they'd add this to python too, pipe-thon if you will.

[@Nellak2011]

Would you be able to define a pipe in a loop? For example: for (let i=0; i < 10; i++) |> some expr (%) Which would be the same as piping it 10 times.

[@jon1867]

I don't think so but you could do this right now let something = "hello" for(let i = 0; i < 10; i++){ something = someExpr(something) }

[@pullrequest1481]

Oh... i saw that operator in bash.

[@boryslebeda6908]

Was it JavaScript or TypeScript? And how long will it take to have it in node.js, browsers and stuff like prettier

[@GrimChu69]

Feels like Batch :D

[@SonAyoD]

Great vid

[@crowdozer3592]

It would be the most JS thing ever if they decided to use `this` as the temporary piped value lol

[@santicanabalramos667]

How many stages are left to get the final release? This is a really excited new feature I can not wait to use 😮

[@yousafsabir7]

When are the types coming to Js?

[@madebyjonny7637]

need that |>

[@TomasJansson]

Would it be possible to write x |> addTwo |> square? That’s how I like to do it in F#.

[@CottidaeSEA]

For anyone deep into OOP, this is similar to adopting the Visitor pattern, where you bring functionality to the instance instead of the class by visiting it with specific interfaces. I prefer the Visitor pattern, but that's also because I am far more used to OOP. I mostly dislike this operator because of the keys it'll make me have to press. Might be fine for English keyboards, but for us international people, this will often require much more key presses with Alt and Shift modifiers. In my case I'd have to use Alt twice and Shift once. Not fun.

[@DryBones111]

If only we had programmable hotkeys in our editors.

[@CottidaeSEA]

@@DryBones111 Which work until you need to use that key combination. I need to use Shift and Alt for so many different things it's not even funny. Also, as with anything else, if you need to make customizations to make it work, it's not designed well.

[@rajaryansingh230]

Till then you can use it: const pipe = (...fns) => x => fns.reduce((v, f) => f(v), x)

[@Mohara-Cam]

what's your thoughts on using Ramda for the FP piping things?

[@urssaf343]

God speed.

[@faizanahmed9304]

atlast, peace nerds ;)

[@vaap]

hop on tuples and records proposal

[@andrewpeters8357]

Not a massive fan, to be honest. Although declaring new variables can come at the expense of potentially clogging up the namespace, these variable names often provide an incredible amount of readability. I find the "non-piped" example that the proposal includes to be far more readable - but maybe that's just me? The only one benefit I can think of is that there are occasionally temp variables that you want to completely avoid the referencing later on in the block (often prefixed with a "_"); but, even then, you have to weigh in syntactical limits (which JS + TS are definitely testing the bounds of right now), and API complexity - less is more IMO.

[@Niconelli12]

Hmm... I really like this operator. But I don't like Tailwind xD

[@Orland89]

Pipe have a big issue. Easy to right but hard to read. And easy to read code it's the best pattern, ever.

[@LohenYumnam]

Hey Theo name of the vscode theme ??

[@DjLeonSKennedy]

Hello from Haskell world noobs : D

[@gideonmaxmerling204]

but you could always do f(g(x)), so your add2square example isn't really a good usecase

[@aidantilgner]

Ugh I guess I'm finally gonna have to learn what functional programming is

[@xtinctspecies]

It’s the best thing to have happened to me

[@FlorianWendelborn]

TL;DR: Everything is a function, use them

[@HoosierTransfer]

only ever used functional programming

[@talgy2671]

Functional programming is all about not repeating the same block of code but using this block inside a function and using the function instead of that block of code.

[@Rei-m3g]

It's like this, it doesn't have oops

[@oath_2d]

I love how javascript is slowly more and more adopting fp patterns This proposal will definitely have massive effect on the way we write our javascript code and the DX gains will be amazing

[@rumplstiltztinkerstein]

To be honest, when I first heard of a new feature coming to javascript, my first thought was "Another feature to bloat this old language even further". But now that I see what it does I think it is a good thing. Javascript has been trying to be a lot of things for a long time. It is a language that is a little bit of everything, and it doesn't seem to be the best at anything. Its strength should be on the high level code. Turning into something closer to a functional programming could make more sense in the future. Similar to what Python does, where it has libraries compiled in C running in it's high level runtime with garbage collector. I think that Javascript as a functional programming language would be easier to understand and debug.

[@chiragsingla.]

@Angel developer experience.

[@RaducuGabriel]

@@rumplstiltztinkerstein js used to be functional until es6 classes and the frameworks pulled it to OOP

[@kebien6020]

JavaScript was actually designed to be a functional language and then it was shoehorned into looking a bit like Java (Mostly syntactically, but also with things like adding null where undefined was just fine). But FP things like first-class functions, anonymous function expressions, closures where there from the start. Also, at some point (2009 maybe?) we got the really nice array methods like map and reduce, keeping the momentum for FP in JS.

[@v01d_r34l1ty]

@@RaducuGabriel i'd argue that prototypes and objects arguably made it OOP before classes. Classes just made it more OO. Meanwhile, new additions like this make it more functional. While I don't really use JS anymore, it will remain in my heart as one of my favorite languages because it's the most innovative for developer experience. I mean, it evolved from being a simple browser scripting language as it was when I first used it (a.k.a. a complete joke language that everybody hated) to being used in backend systems for servers.

[@atla5_]

Another FP feature I hope will land into JavaScript is pattern matching

[@mattburgess5697]

I really like the pipeline operators from Elixir. It makes code based on functions (regardless of strictly FP paradigm) much more intuitive and readable.

[@andreicojea]

As someone who started web dev when most people were using Internet Explorer 6, I love how JS language and then ecosystem evolved over the past few years ❤

[@daleryanaldover6545]

I started a year later after Explorer 7 came out. Glad things are getting better and better.

[@vikingthedude]

How do you feel about label statements?

[@yapet]

It’s cool I guess, buuuuut. It seems that I am the only one worried about adding new syntax to js. It’s shiny and fancy, but it has a real impact on perf. The parsers are now required to be more complicated, and as such, parsing perf is impacted by it. Moreover, we are shipping oodles and oodles of JS, which cannot run until it is fully parsed. We have already experienced parsing perf decrease with the introduction of ES6 waaay long ago. It is cool to see JS being pushed forward. Just hope we won’t get another C++, with whole “design by committee” shenanigans attached. Maybe we would require some kind of depreciation strategy going forward. Maybe something akin to "use strict", that axed a part of the language (remember “with” statement anyone?)

[@DryBones111]

This feature is easily transpiled, so if you want backwards compatability to older parsers, you can.

[@yapet]

@@DryBones111 I'm referring to the future parsers perf (even on existing code, without the use of new features), not older ones compatibility. Of course you can transpile most of the new syntactic JS proposals.

[@LukePighetti]

Love a pipe operator. Can be better than extension methods tbh

[@andreisgs5392]

can't this be already done with rxjs? or am I missing something here? Would this pipe work with async functions or promises?

[@wownord]

I really like the equivalent in Clojure (called "threading macros" there). They have things like: thread-first (->) Inserts value of previous function as first parameter of next thread-last (->>) Same but as last param thread-as (as->) Give param a name, like % So it would be something like: (defn piped [x] (-> x add-two square square square))

[@thetrends5670]

Cap *^* is a XOR operator in JavaScript not a Power operator, Power operator is **.

[@uaesbriosheje]

The clickbait title tho...

[@henri5978]

How is it clickbait, if he has waited for it for years?

[@vhaangol4785]

@@henri5978 - "I've waited YEARS for this JavaScript feature" - Thumbnail shows FINALLY Without much context, you'd think this vid is about a new JS feature. The pipeline operator was first discussed around 2015. It has been in stage 2 since 2021. Given that there are 2 more stages before this is released, I doubt we'd see this feature any time soon. So yeah. Kinda clickbaity title

[@uaesbriosheje]

@@henri5978 the title Is clickbait. Content awesome as Always, I love watching his content, but the title this time was a bit meh. Of course, it's irrelevant but hey, it's Just some feedback :D

[@adriancaor]

Since I tested it in Elixir, I miss it in the other languages I have worked with. Good news for JavaScript!

[@AaronPrather]

Isn’t this currently possible by writing a small pipe utility function that converts functions passed as args to an array, then using the reduce prototype method to call each one with the previous returned value?

[@EdJones99]

Anything that takes away the need to come up with names is massive DX improvement imo. Really excited about this.

[@m3hdim3hdi]

what DX mean?

[@tendency5272]

​@@m3hdim3hdi Developer experience

[@jongeduard]

F#, not a language that I really develop in, but that's where I know this operator from. Can we asume that the backward version of the operator is going to be implemented as well? Note. Using a temp variable does not need to imply more memory allocations. Compilers and JIT compilers are very smart these days and do excellent stuff with inlining and optimizing code before actually executing it as machine code. It's much more likely that the functional and imperative versions of the shown code are translated to the exact same thing.

[@jpbz412b]

You can make your own pipe too: function pipe(...fns) { return function apply(arg) { return fns.reduce((prev, curr) => { return curr(prev) }, arg) } } And use it like this: pipe( toUpper, trim, removeNumbers, )(" test123")

[@recepciftci2642]

This is syntax is really ugly. Hope never pass the stage 2

[@akshattamrakar9071]

Exactly. % will make things unnecessary complected.

[@voidmind]

The operator has been a longtime coming. I thing it's been a TC39 proposal in some stage or another for many years.

[@thisweekinreact]

Oh noo 😢 So disappointed, there's a tc39 meeting in progress so for a few seconds I thought it moved to stage 3 😅

[@fueledbycoffee583]

LOVEIT functional array methods we're good but this is just godsend

[@industry_std]

I've always loved this feature without even knowing it existend! Glad to see it get closer to being a real thing. I wish the discourse online would show this kind of advancement in the language over other less useful/unnecessary ones such as the dreadful type annotation thing.

[@jaredsmith5826]

Interested to see how they end up handling Promises and async in pipes. "I learned it in Elixir" I'd be willing to bet you learned it in the shell years before :D

[@yapet]

I’m kinda excited how this may impact library design. We all love method chaining for exactly the same reasons pipe operator is a thing. Right now you are required to put methods on an object / prototype to achieve that. Modern bundlers (generally*) don’t strip out object properties, since they cannot guarantee, that you won’t `Object.keys` them (or something similar). We might see a trend in libraries that expose just functions as opposed to methods on an object and expect you to use pipe to get ergonomics of method chaining. That way bundlers can tree-shake unused functionality more aggressively. *Compilers like Google Closure, can analyze through things like that. Kinda sad that almost nobody seems to use it (unless you are a Clojure JS developer). I feel like making JS compilers more accessible can be a HUGE positive change for the community.

[@plinatry783]

I think the @ sign would be cool. Looks a little like an black hole that sucks everything in. Perfect Fit in my Book :P

[@jon1867]

I agree, but somehow people thought decorators were a good idea

[@Zullfix]

I'm personally more of a fan of extension methods but in the case of javascript lacking explicit types I can see how that could be a problem. 3:46 I somehow doubt that. I think I get what you were trying to say but not the best choice of wording.

[@justfly1984]

You finally sold me a pipe operator. Waiting for somebody to sell me decorators.

[@jon1867]

I think it can be nice in OOP, which I hate OOP so I don't care haha

[@Red7iger]

Apart from that I cannot figure out how to put it in global scope here is a solution right now in typescript. type PFunc = (val: In) => Out; function next(fn: PFunc, input: In) { return { pipe: (nextFn: PFunc) => next(nextFn, fn(input)), out: () => fn(input), }; } function to(val: In) { return { pipe: (fn: PFunc) => next(fn, val), }; } const output = to(1) .pipe((x) => x * 10) .pipe((x) => Array(x).fill(null).join(`${x}`)) .pipe((x) => x.length) .out(); console.log(output); const magic = to({ x: 10, type: 'foo' }) .pipe((obj) => obj.x) .pipe((x) => x.toFixed(10)) .pipe(Object.values) .out(); console.log(magic);

[@thomashermant9321]

What do you think about this : function compose() { var fns = Array.prototype.slice.call(arguments); return fns.reduce(function(f, g) { return function() { return func(f)(func(g).apply(this, arguments)); }; }); }; const composedFunc = compose( func1, func2, func3 );

[@jacmkno5019]

You can think in pipes with async/await. That proposed syntax looks horrible. JavaScript is NOT perl! await (async () => 3)() .then(v => v+2) .then(v => Math.pow(v,2))

[@TheChodex]

At first I was like "hmm I don't know"", but then you won me over with the 3:29 because I got flashbacks from the React when I want to wrap component with few hocs then it's like `withSomething(withSomethingElse(withAnotherSomething(MyComponent, anotherExtraStuff), somethingElseExtraStuff), somethingExtraStuff)` which is annoying to read, this pipe operator is gonna make it much more understandable

[@aislanarislou]

Finally!!!! That feature will be the key for apply Railway programming in Javascript easier and more cleaner than ever !!!! Excited for this coming before 2030 !!!!!

[@ДмитрийКарпич]

Looks great! I love pipes, but don't love chaining - just because it's "kinda" pipes for infants :) So, maybe we are someone can have tuples? Please, it's so suck does not have tuples in JS. Why? func (a,b) -> return [a,b] ? I want return (a, b). It will be so logical and don't break rhythm of code!

[@yoloopen]

There was a language "LiveScript" like 10 yrs ago, it's basically a syntax sugar compiling to JS. It was never popular and become abandoned long ago. But! Just, why the world is so unfair. LiveScript had pipe operators much cooler than what we see in the proposal, and it's simply a syntax sugar, so no tech problems implementing it in JS, but instead we have an uglier version we have to wait for years.

[@dunebuggy1292]

Everything is functional programming when you don't know what functional programming is. Leveraging shortcuts is not functional programming.

[@codeChuck]

Good stuff! Firstly I though of this as a downgrade to readability. But after you said it will not perform assign operation, it sounds like it will be more performant. So the syntax becomes more bearable knowing it is ++ to perf :)

[@TheCuteLittleDoggy]

Ok I just learned how some people are just...... different 😅 he says "this is where things get fun" 🤣 I'm looking around going, Holy crap where's the fun? I don't see any yet!!

[@Spookyhoobster]

They should change that "chalk.dim()" example. (I guess it might make more sense as a "use case" for a proposal rather than a basic "showcase" to get the idea across) My initial reaction was "Oh god, more obscure, hard to read syntax...", but your example with add/square made so much more sense. Lot cleaner than function calls inside function calls.

[@jamshediqbal7936]

It’s called chaining. I remembered when I used lodash a lot in past (not anymore hehe), it looks same as _.chain(x).trim().upper()… 😊