For anyone wondering about the SQL injection at 9:23: It uses a tagged template string. Notice the "sql" before the back quote. This is a "tag". It's a function that receives all the elements composing the template string (literal and variables) and has the opportunity to transform any of these before returning whatever it wants. Obviously, this function is responsible to sanitize the variables.
11:00 yes it's exaggerated. People think that if you don't deploy to Vercel, that Next.js features just stop working. If you deploy Nextjs as a simple Node app, all its features still work. I've deployed multiple Nextjs apps in various configurations to VMs with or without Docker and things still work. Of course it requires more work compared to just clicking few buttons on Vercel, but it does work. And I just want to say, you don't need to deploy your Next.js based blog to a super complicated AWS serverless/edge setup, but that's what people think they have to do these days.
Reinventing all of the frameworks was a collective attempt to prevent AI from writing new code (until new models are trained, then they get reinvented again).
sql`` is actually a function, if you call a function with backticks instead of parenthese, from what I understand, every time you use ${} it appends that value to the list of arguments, the first argument being the whole string as an array.
I think the point with the WebSockets in node is not that they implemented them like the browser did, but that they implemented the Web Standard API for WebSocket that all the browsers and runtimes support
in my humble opinion as a senior dev - websocket server is the best test of a language/runtime. it's stateful, so you test all features of a language. UI in general is not a bad test either. basically anything but a restful api server :)
The Object.groupBy is not the same as the SQL group-by. It's really a partitionBy to partition the list into sublists by some condition, where the SQL group-by is aggregation in nature.
Yeah, and it arguably has a place in JS. Filtering a list but also getting the non-matches at the same time is something you could conceivably need to do in front end, not the db
3:13 classic prime. Not everything has to live in the database, as an SRE doing simple scripts, I'd use a feature like groupBy when doing something ad-hoc
tagged function is basically just another way of writing a function, where the tokens (or words) inside the template string are grouped into an array, while the captured variables are turned into arguments
We tried Vercel for a few days and we decided to stay with our own Docker Swarm deployment on our dedicated server. There was literally no measurable advantage of using Vercel on that project.
if you already have CI setup, and are happy configuring AWS, and you don't want specific nextjs + vercel stuff, then you probably wont benefit much from using vercel or netlify
@@darshandev1754 noone should do grouping in FE if possible to do in BE. But sometimes you need same data in different grouping. Creating 2 endpoints is extra maintenance and dependancy. Also, frontend might no longer need different grouping, meaning you will also need to update BE codebase.
@@dinesee1984 makes sense sending ungrouped data does give you flexibility to manipulate it more freely on the frontend however I will still prefer 2 separate endpoints its still pretty ok to group on the frontend if the dataset is small enough, if for some reason it cant be moved to the backend
@@darshandev1754 ofc with big data set you would do it in backend, it is insane to do that kind of operation on FE. Only with small/medium data this is valid, applies same principal as to any other data manipulation in FE
3:18 api returns data that needs to be displayed in 2 different places but in completely different grouping. Instead of creating 2 endpoints you have 1 endpoint. I see this as great feature, less code to write.
@@harleyspeedthrust4013 you can also add num1 + num2 with reduce, so this does not makes sence it terms of NOT making new api for some action that could be done with reduce
I really like vue. It's very unfortunate that things didn't work out with reactivity transform, which would've made it a lot more like svelte 3.0, but you can still use vue-macros to bring it back. What vue does well is co-locating functionality. If you use setup(), or even better, , you can group together definitions that pertain to a specific feature instead of grouping things by type alone. Having your template as-actual-html, your script (setup) and your component-specific styling as-actual-css (which should however always be kept minimal) does wonders for productivity and maintainability. Vue is the one framework I've stuck to since deciding to advocate for it in a company project. We also considered angular and react, at the time Svelte 3 wasn't a thing yet, but vue just had so much less dogma and overhead behind it, it was the only reasonable choice.
Yeah, why does React NOT support vanilla CSS out of the box that allows things like actual media queries and pseudoelements / selectors is beyond me... Why does the setState hook exist? Or at least, why do you HAVE to use it (or the dev time consuming reducer) for arrays? Why can't you just push an object to the state array without having to copy the whole thing over back and forth?
The problem with existing sort and reverse is that it will break if you change that the behavior. 1 thing that EcmaScript is very strict in, is that it never has breaking changes. That is also why sites from that are very old (20+ years) still works, even the very old JS. Frameworks break, even Typescript breakes, but Ecmascript will never has a breaking change, even it is weird like sort and toSorted. That is also why Ecmascript changes take a long time to be stable. Sometimes Typescript implement an unstable Ecmascript proposal, and in Typescript flagged as stable, that also changed in time. (yes this happened)
Can't you just leave the old stuff IN and ADD a "better way" as an option instead of changing the behaviour entirely? Just have LSP barking at you something like "you're mutating that thing" kinda like it already does when you try to use `var`... It's all arbitrary anyway... :|
I feel like the bigger problem is that the designers of WHATWG and whatnot are either not payed enough (if at all) or are not talented enough, or both. But what I am very sure about is that they're never in any kind of hurry to either finish a spec, or adopt a new non-breaking spec, or just make a good mostly flawless spec. I kind of got really disappointed to see that they adopted the abort signal API only to find out that the spec they came up with was kinda bad and lacking, and now it's taking them a decade to come up with amendments to it. There are tons of specs waiting in stage 3 as well, that might as well wait forever. At this point it'd be faster to replace the whole WEB standard with a new one than just to implement 5 specs if there was lots of funding and talent behind it.
@@arcuscerebellumus8797 That is why they have add new methods, so your site from 20 years ago still works. Your linter can tell you that you better can use toSorted. But it is not ECMA that tells you, e.g. Eslint can have a rule that you can use to tell you to stop using the old mutating sort.
3:30 also, if you have to write a js side sorter, I guarantee you that a for loop will be more faster (as in faster than the word faster) and more flexible.
07:00 "you create a website in which you can not replicate that state" what does that mean? --- only hard thing making modals for me using other tags is preventing tabbing behind modal (assuming inert attribute not supported)
Yes... I was trying to play this video clicking the play button on the original Firebase video paused in the background while you were commenting. Send help.
that groupby thing is also useful if you have to do data processing that you had to get PowerShell but because there' no tasks that it's worse at than data processing, you're passing it to node
I run UMAMI on a droplet. No docker, just a PM2 config to run next start in the directory. Everything works in self hosted nextjs except the edge infrastructure which it’s in the name, it’s infrastructure not something related to nextjs prod server
Error: Hydration failed because the initial UI does not match what was rendered on the server. Meanwhile it's because the server has a different timezone setting than the client side browser, because you're displaying time somewhere in a server component... That's just one quirk. Good luck figuring out all the quirky hydration errors that are naaaasty to debug 😂
@@In7elligence I got nothing to figure out it's something I noticed in NextJS apps I've used (I don't use NextJS since version 12 + work brings other stacks into mix). Example Supabase crashes on me if I run simple query. When I look it's all NextJS. Noticed this with few other sites I've bombed that were using Next
@@theseangle This thing is painful because I actually totally wrote a tiny library for java people who made O(n^2) algo where I could make linear (and they could have used database just they cached data in memory). Sped things up like 50x - not current job, but previous 🙂
@@theseangle Funny thing is that there was an other case: not in-memory but also replication /memoization and before just storing a cache locally they wanted some nosql bullshit just because the data source were so slow (everyone was accessing it - it was a database of adresses of the whole country and for some reason everyone accessed the same thing instead of locally caching) and honestly there was this nosql hypster guy who wanted to remake the whole centralized thing with some shiny technology as a "huge side-quest of our little project of putting up a single address box" - so I just told him to fsck-off and implemented a simple cache that got updated once daily from the live slow shit... Guess what - it was extreme well working. I also have no idea how they made the original so slow, because for this other thing (this is unrelated to the previously mentioned one!) was not even in-memory.... it was just an OTHER SQL server that rarely replicated the live one which was slow... and that's it. Doing this kind of imperfect replication with maybe 1day old data do not need any nosql, but so many people were thinking of that solution too.... It would be cool if more people indeed know memoization - both in memory and even just in a smaller DB more focused to local needs. In extreme cases even monthly replication is enough haha
Doing Rust for AOC this year after doing Haskell last year. It's incredible how much Rust has in common with Ocaml and Haskell. The c style syntax is a little annoying, but everything being an expression is so nice. Going back to Typescript for my day job is depressing as always XD
You can say just use SQL for data manipulation etc, but tell that to all the backend teams creating the APIs for front-end who insist it's not idiomatic to give us the data in a useful format 😂
i mean... did so much actually happened? Sure there a new Frameworks all the time but nobody uses them. Dont think there was any relevant newcomers this year. Also the common frameworks didnt changed that crazy.
@@moritzschuessler I think the only major one new comer was bun But next.js changed so much that it's practically a new framework and it was buggy until a couple months ago Dunno about angulars changes but does sound significant
genuinely confused about why groupBy exists. The example he showed would be much more readable with a map or filter, but most importantly, why add it if an extremely similar method already exists?
im wondering the same thing. some people said that they think it offers a performance benefit. i don't know and personally don't care because the idea of "performance" in javascript land is kind of a joke
How do you write an expression that gives you two lists that partitions a list using map or filter? Yeah, you can use multiple filters, but now you need to be careful that your filter condition is exactly inverted and the list didn't change or you miss or double count. But the real issue is if you're grouping by eg parentId you don't know what the values to filter by are!
I prefer htmx and svelte to Vue, but of the mainstream frameworks, sorry, libraries, my experience has been that Vue is a much less leaky abstraction than React, and much easier to incrementally adopt than Angular. However it has been some years since i have used any of them.
"InJeCtIoN AtTaCk!1!1" vs "isn't that an injection attack via string interpolation?" Turns out it is not string interpolation, though it looks a lot like it. That first case makes you look like a fool, in the 2nd you've expressed a concern while leaving the door open to being wrong, learning and growing. Of course if you're proven right, you can still pull out deez nuts.
Javascript is so bad that even its inventor doesn't have anything nice to say about it. Nevertheless, we are all forced to use it and it will likely be around for a while.
nah... First of all, this piling on JS is mostly about frameworks and mostly a meme, but even if it died like "yesterday", with the amount of existing code and infrastructure, the transitory period and maintenance going with it would stretch into a lifetime... we (as in humans) still use Fortran and Cobol and IF you choose to spend time in it (although I have no idea why you'd do that to yourself), they actually may end up paying a lot more then your avarage JS position.
I've never really understood the whole "oh no, this function mutates the original array" dilemma with sorting. Shouldn't that be the assumption? .map and .reduce are inherently not functions that should mutate the original array just based off of what they do, so that's a non-argument. If you want a copy of your array when it's sorted, maybe just clone it before sorting? I honestly just don't get it.
@@adambickford8720 Yes, but why? It makes no sense to me. I do not see the point in reallocating memory just to adjust 1 to 2. I do not see the point in reallocating all of the memory just to append a single element to an array. To me it just seems like idiocy. There is some merit to immutability, but I honestly do not believe it should be the default behavior for turning A into B.
@@CottidaeSEA you are essentially trading performance for correctness and predictability. This is a trend among almost all the major languages. It allows frameworks to use identity checks for equality which is quite a bit more performant in large graphs. In practice, you are very unlikely to see a meaningful performance gap.
@@adambickford8720 Sure, but you can have that with mutable data as well. If you're passing data to who knows where then immutable makes sense. If you're working with data locally or you get an input that needs to be adjusted somehow inside of the current logic but not outside, clone it. It just feels like people just don't know what they are doing and immutable data feels like a protection against that. I also want to point out that pretty much half of the performance issues I encounter are memory-related, so I am not so sure about that unlikely performance gap.
@@CottidaeSEA its a different paradigm with its own pros and cons. its not that people don't understand, they just don't agree on the value of the trade-offs. immutable code is easier to understand as you don't have to worry about state over time. you don't have to 'manage' state, so it reduces bugs. it's a big part of why functional programming is on the rise and these apis support that nicely. if performance is critical you might want to consider something like persistent structs, object pooling, mutable structs, etc. but if you don't have measurements and SLAs, the 'performance' claim isn't very convincing.
I really like how much shit fireship and prime talk about popular technologies while also using a lot of them daily. Much prefer that over these weird "my language/framework is the best language/framework" fights
Next now also had 2 flavour, Angular just got another api to write templete and Svelte about to release another way to write reactive stuff Everyone does it now
@@khangle6872 Which is a bad thing. Every year they have to change their opinion what a decent webapp has to look like. It sucks. I've rarely seen any improvements being worth the changes and the mess they create. Vue with options api was perfectly fine. Like react was in 2014 or Angular 2 in 2017. I also hate the argument of "programming language X is a lot different these days because it now has Y" which means they offer more ways to do the same thing or they created a mess with breaking changes. Of course everyone can make changes or invent new libs and frameworks otherwise there would be no improvements at all. However you just can't invent a new more efficent way to do X or Y so frequently. I think as a developer you waste your time and you benefit more if u have a very basic but extremely flexible techstack like vanilla sql + php/go + some vanilla js/css and spend your time learning these properly & establish a nice workflow instead of switching between fe-frameworks/or-mapper/baas/css-frameworks/... to always get the right abstraction for the current job.
@@moritzschuessler It always depends on the focus of a problem. Both vue api's provide a solution for a quite focused problem which is just annoying. A programming language does not have a narrow focus like that. So reducing the amount of necessary concepts you have to understand in order to solve a variety of problems should be the priority. It''s difficult to compare. A similar thing would be if a programming language has 20 different ways to init an object or to create a timer. And on top of that all of these methods seem to do the same but behave slightly different. (I have a C# .NET background)
@@deado7282 new apis are necessary to be backwards compatible. If not it will break when migrating to new versions. If that isn’t the case new versions wouldn’t be possible and there would be way more new frameworks (and languages)
As a joke, I started learning Haskell so I could make fun of it too. Since then, I don't want to program in anything else. Just saying 🤷♂
ok virgin
the language is cool but everything around it just sucks. You can tell it is written by mathematicians and not software engineers.
@@Kriszzzfulyou need a maths degree to understand the errors otherwise it's a good language
@@weeb3277 Luckily, I used to do frontend back in the days 🤣
I started learning and I no longer want to program at all.
For anyone wondering about the SQL injection at 9:23: It uses a tagged template string. Notice the "sql" before the back quote. This is a "tag".
It's a function that receives all the elements composing the template string (literal and variables) and has the opportunity to transform any of these before returning whatever it wants.
Obviously, this function is responsible to sanitize the variables.
"Modes are almost always a mistake." - Prime
"Vim is the best editor." - Also Prime
11:00 yes it's exaggerated. People think that if you don't deploy to Vercel, that Next.js features just stop working. If you deploy Nextjs as a simple Node app, all its features still work. I've deployed multiple Nextjs apps in various configurations to VMs with or without Docker and things still work. Of course it requires more work compared to just clicking few buttons on Vercel, but it does work.
And I just want to say, you don't need to deploy your Next.js based blog to a super complicated AWS serverless/edge setup, but that's what people think they have to do these days.
Reinventing all of the frameworks was a collective attempt to prevent AI from writing new code (until new models are trained, then they get reinvented again).
My blog is officially in a Primeagen video
sql`` is actually a function, if you call a function with backticks instead of parenthese, from what I understand, every time you use ${} it appends that value to the list of arguments, the first argument being the whole string as an array.
I think the point with the WebSockets in node is not that they implemented them like the browser did, but that they implemented the Web Standard API for WebSocket that all the browsers and runtimes support
in my humble opinion as a senior dev - websocket server is the best test of a language/runtime. it's stateful, so you test all features of a language. UI in general is not a bad test either. basically anything but a restful api server :)
"NoSql is largely a mistake" this is a great statement ! Also a good tweet kkk
The Object.groupBy is not the same as the SQL group-by. It's really a partitionBy to partition the list into sublists by some condition, where the SQL group-by is aggregation in nature.
Yeah, and it arguably has a place in JS. Filtering a list but also getting the non-matches at the same time is something you could conceivably need to do in front end, not the db
ES++. New features will continue until morale improves.
3:13 classic prime. Not everything has to live in the database, as an SRE doing simple scripts, I'd use a feature like groupBy when doing something ad-hoc
And not everything is a crud web app
@@igorordecha example?
That's why I don't understand his non sense random rants xd
tagged function is basically just another way of writing a function, where the tokens (or words) inside the template string are grouped into an array, while the captured variables are turned into arguments
We tried Vercel for a few days and we decided to stay with our own Docker Swarm deployment on our dedicated server. There was literally no measurable advantage of using Vercel on that project.
if you already have CI setup, and are happy configuring AWS, and you don't want specific nextjs + vercel stuff, then you probably wont benefit much from using vercel or netlify
Arch users that develop in Haskell are getting constantly attacked by Prime :(
"as soon as I start talking about JavaScript frameworks, I turn into a stereotypical monster" -prime
so real
GroupBy is for frontend guys to run it on client side while rendering i think
I think he sometimes forgets JS in the frontend is a thing
@@XDarkGreyX a grouped response can be sent from the backend
his point still stands
a faster backend language/db does it better
@@darshandev1754 noone should do grouping in FE if possible to do in BE. But sometimes you need same data in different grouping. Creating 2 endpoints is extra maintenance and dependancy. Also, frontend might no longer need different grouping, meaning you will also need to update BE codebase.
@@dinesee1984 makes sense
sending ungrouped data does give you flexibility to manipulate it more freely on the frontend
however I will still prefer 2 separate endpoints
its still pretty ok to group on the frontend if the dataset is small enough, if for some reason it cant be moved to the backend
@@darshandev1754 ofc with big data set you would do it in backend, it is insane to do that kind of operation on FE. Only with small/medium data this is valid, applies same principal as to any other data manipulation in FE
3:18 api returns data that needs to be displayed in 2 different places but in completely different grouping. Instead of creating 2 endpoints you have 1 endpoint. I see this as great feature, less code to write.
Also groubBy would not be slow because it will be natively implemented in the interpreter.
sure but it's also just doing what you could already do easily with reduce
@@harleyspeedthrust4013 you can also add num1 + num2 with reduce, so this does not makes sence it terms of NOT making new api for some action that could be done with reduce
@@harleyspeedthrust4013 perhaps but not as performant
@@ArcRCG speculation. and if you care about performance then don't use js
The Haskell rant: dead. I frigging love you man lmao.
I really like vue. It's very unfortunate that things didn't work out with reactivity transform, which would've made it a lot more like svelte 3.0, but you can still use vue-macros to bring it back. What vue does well is co-locating functionality. If you use setup(), or even better, , you can group together definitions that pertain to a specific feature instead of grouping things by type alone. Having your template as-actual-html, your script (setup) and your component-specific styling as-actual-css (which should however always be kept minimal) does wonders for productivity and maintainability.
Vue is the one framework I've stuck to since deciding to advocate for it in a company project. We also considered angular and react, at the time Svelte 3 wasn't a thing yet, but vue just had so much less dogma and overhead behind it, it was the only reasonable choice.
Yeah, why does React NOT support vanilla CSS out of the box that allows things like actual media queries and pseudoelements / selectors is beyond me...
Why does the setState hook exist? Or at least, why do you HAVE to use it (or the dev time consuming reducer) for arrays? Why can't you just push an object to the state array without having to copy the whole thing over back and forth?
The problem with existing sort and reverse is that it will break if you change that the behavior.
1 thing that EcmaScript is very strict in, is that it never has breaking changes.
That is also why sites from that are very old (20+ years) still works, even the very old JS.
Frameworks break, even Typescript breakes, but Ecmascript will never has a breaking change, even it is weird like sort and toSorted.
That is also why Ecmascript changes take a long time to be stable.
Sometimes Typescript implement an unstable Ecmascript proposal, and in Typescript flagged as stable, that also changed in time. (yes this happened)
Can't you just leave the old stuff IN and ADD a "better way" as an option instead of changing the behaviour entirely? Just have LSP barking at you something like "you're mutating that thing" kinda like it already does when you try to use `var`... It's all arbitrary anyway... :|
I feel like the bigger problem is that the designers of WHATWG and whatnot are either not payed enough (if at all) or are not talented enough, or both. But what I am very sure about is that they're never in any kind of hurry to either finish a spec, or adopt a new non-breaking spec, or just make a good mostly flawless spec. I kind of got really disappointed to see that they adopted the abort signal API only to find out that the spec they came up with was kinda bad and lacking, and now it's taking them a decade to come up with amendments to it.
There are tons of specs waiting in stage 3 as well, that might as well wait forever. At this point it'd be faster to replace the whole WEB standard with a new one than just to implement 5 specs if there was lots of funding and talent behind it.
@@arcuscerebellumus8797 That is why they have add new methods, so your site from 20 years ago still works.
Your linter can tell you that you better can use toSorted.
But it is not ECMA that tells you, e.g. Eslint can have a rule that you can use to tell you to stop using the old mutating sort.
3:30 also, if you have to write a js side sorter, I guarantee you that a for loop will be more faster (as in faster than the word faster) and more flexible.
07:00 "you create a website in which you can not replicate that state"
what does that mean?
---
only hard thing making modals for me using other tags is preventing tabbing behind modal (assuming inert attribute not supported)
so needed my daily dose of PrimeTime today - have a great weekend
Yes... I was trying to play this video clicking the play button on the original Firebase video paused in the background while you were commenting.
Send help.
that groupby thing is also useful if you have to do data processing that you had to get PowerShell but because there' no tasks that it's worse at than data processing, you're passing it to node
3:30 you are not running javascript when you call native functions, it is basically a c++ code that is processing it.
Primeagen calling SQL as "Squeal" got me dead 💀
10:57 I think easy means:
1. download (to server) executable (maybe together with other files)
2. run the executable
I run UMAMI on a droplet. No docker, just a PM2 config to run next start in the directory. Everything works in self hosted nextjs except the edge infrastructure which it’s in the name, it’s infrastructure not something related to nextjs prod server
NextJS = Application error: a client-side exception has occurred (see the browser console for more information)
Error: Hydration failed because the initial UI does not match what was rendered on the server.
Meanwhile it's because the server has a different timezone setting than the client side browser, because you're displaying time somewhere in a server component... That's just one quirk. Good luck figuring out all the quirky hydration errors that are naaaasty to debug 😂
@@In7elligence I got nothing to figure out it's something I noticed in NextJS apps I've used (I don't use NextJS since version 12 + work brings other stacks into mix). Example Supabase crashes on me if I run simple query. When I look it's all NextJS. Noticed this with few other sites I've bombed that were using Next
4:34 yes, that would be a golden addition to javascript
1 for Vue
So they added group-by so JS people write even slower codes because doing database things with not database :D
Knowing typical Javascript "devs", it's probably to prevent people from writing O(n^2) algorithms with a separate filter() call for each group 😂
@@theseangle This thing is painful because I actually totally wrote a tiny library for java people who made O(n^2) algo where I could make linear (and they could have used database just they cached data in memory).
Sped things up like 50x - not current job, but previous 🙂
@@u9vata yep, memoization is handy to know about
@@theseangle Funny thing is that there was an other case: not in-memory but also replication /memoization and before just storing a cache locally they wanted some nosql bullshit just because the data source were so slow (everyone was accessing it - it was a database of adresses of the whole country and for some reason everyone accessed the same thing instead of locally caching) and honestly there was this nosql hypster guy who wanted to remake the whole centralized thing with some shiny technology as a "huge side-quest of our little project of putting up a single address box" - so I just told him to fsck-off and implemented a simple cache that got updated once daily from the live slow shit... Guess what - it was extreme well working. I also have no idea how they made the original so slow, because for this other thing (this is unrelated to the previously mentioned one!) was not even in-memory.... it was just an OTHER SQL server that rarely replicated the live one which was slow... and that's it.
Doing this kind of imperfect replication with maybe 1day old data do not need any nosql, but so many people were thinking of that solution too....
It would be cool if more people indeed know memoization - both in memory and even just in a smaller DB more focused to local needs. In extreme cases even monthly replication is enough haha
"NoSql was largely a mistake" is the most factual thing I have ever heard.
Doing Rust for AOC this year after doing Haskell last year. It's incredible how much Rust has in common with Ocaml and Haskell. The c style syntax is a little annoying, but everything being an expression is so nice.
Going back to Typescript for my day job is depressing as always XD
They already have groupBy in C# LINQ. JavaScript catching up
My two favorite TH-camrs 🙌
12:20 Vue is awesome! But not sure how it can mix with HTMX yet.
You can say just use SQL for data manipulation etc, but tell that to all the backend teams creating the APIs for front-end who insist it's not idiomatic to give us the data in a useful format 😂
The bit about Haskell actually killed me 🤣
Yep 12:13, love Vue 💖
15:00 wtf is that? Did you people forgot how to write a loop so now you need a *for template?!*
I hope the JavaScript ecosystem stops this "every week, new framework shenanigans".
Vue is stable, i use it since 2018. Stable as f*ck.
@@voidwalker7774 Have been thinking of giving Vue a try. I will add it to my "Technologies I'm learning in 2024" lost.
@@voidwalker7774 any chances it will change in 2024, because I am fed up with client and server components of next 13 and14
i mean... did so much actually happened? Sure there a new Frameworks all the time but nobody uses them. Dont think there was any relevant newcomers this year. Also the common frameworks didnt changed that crazy.
@@moritzschuessler I think the only major one new comer was bun
But next.js changed so much that it's practically a new framework and it was buggy until a couple months ago
Dunno about angulars changes but does sound significant
Sam Bankman Jailed? Yeah, that guy.
12:40 shit looks like a neural network, oh no, my app is evolving, help!
Why is exporting and importing SUCH A PAIN IN THE ASS with Js and Node and Ts
"NO-SQL was largely a mistake" - The Primeagen
who else starts instinctively slapping the spacebar when Prime starts pausing the video too much? xD
The cutoff for adult is 18, not 21.
For those who didn't know, NOSQL stands for Not Only SQL, LOL.
.toMap that mutates a const array into a const Obj? I imagine ecma people will love it, rush to release
I am a stereotypical italian monster and I approve your message
Anything but your normal voice sounds like Micheal Scott from the office show! I said it once, i said it again!
the year was 2023... JS community finally implemented 2:37 groupBy invented by 3:17 RDBMS's 56 years ago...
genuinely confused about why groupBy exists. The example he showed would be much more readable with a map or filter, but most importantly, why add it if an extremely similar method already exists?
im wondering the same thing. some people said that they think it offers a performance benefit. i don't know and personally don't care because the idea of "performance" in javascript land is kind of a joke
How do you write an expression that gives you two lists that partitions a list using map or filter?
Yeah, you can use multiple filters, but now you need to be careful that your filter condition is exactly inverted and the list didn't change or you miss or double count. But the real issue is if you're grouping by eg parentId you don't know what the values to filter by are!
I love javascript 😍
thank you
I prefer htmx and svelte to Vue, but of the mainstream frameworks, sorry, libraries, my experience has been that Vue is a much less leaky abstraction than React, and much easier to incrementally adopt than Angular. However it has been some years since i have used any of them.
squeel, like the sound of squirrels
haskell community all 21 of them! 😆
He is back yeah(fireship)!
What does he mean by "always ask a question before you just claim an outcome"¿
"InJeCtIoN AtTaCk!1!1"
vs
"isn't that an injection attack via string interpolation?"
Turns out it is not string interpolation, though it looks a lot like it. That first case makes you look like a fool, in the 2nd you've expressed a concern while leaving the door open to being wrong, learning and growing. Of course if you're proven right, you can still pull out deez nuts.
all jokes aside… is JS really done? i‘m new to programming and started with JS. Would love to hear some opinions 🙂
Javascript is so bad that even its inventor doesn't have anything nice to say about it.
Nevertheless, we are all forced to use it and it will likely be around for a while.
We will all die before Javascript does unfortunately.
nah...
First of all, this piling on JS is mostly about frameworks and mostly a meme, but even if it died like "yesterday", with the amount of existing code and infrastructure, the transitory period and maintenance going with it would stretch into a lifetime... we (as in humans) still use Fortran and Cobol and IF you choose to spend time in it (although I have no idea why you'd do that to yourself), they actually may end up paying a lot more then your avarage JS position.
As if. Just git gud. Live in sadness, die in sadness
Learn JS first! You won't know why it's so bad until you learn another lang. And by then you'll be good at JS so who cares?
groupBy is ideal for me because our "DB people" do not allow grouping in the DB...
Perhaps deprecate sort, map etc and use toSort / applySort, toMap / applyMap etc for mutables / immutables? lol
Javascript Backend development is turning into PHP, only worse.
Crazy when you think about it, lol.
04:52 just call it map2
there's 22 now
I love Vue
4:20 skill issues, use a for loop.
All 21 Haskell users... FTW...
App directory "Stable" LUL
JS is a form of inconsistent virginity
I've never really understood the whole "oh no, this function mutates the original array" dilemma with sorting. Shouldn't that be the assumption? .map and .reduce are inherently not functions that should mutate the original array just based off of what they do, so that's a non-argument.
If you want a copy of your array when it's sorted, maybe just clone it before sorting? I honestly just don't get it.
People are moving away from mutability in general to the point where frameworks expect/demand it.
@@adambickford8720 Yes, but why? It makes no sense to me. I do not see the point in reallocating memory just to adjust 1 to 2. I do not see the point in reallocating all of the memory just to append a single element to an array.
To me it just seems like idiocy. There is some merit to immutability, but I honestly do not believe it should be the default behavior for turning A into B.
@@CottidaeSEA you are essentially trading performance for correctness and predictability. This is a trend among almost all the major languages.
It allows frameworks to use identity checks for equality which is quite a bit more performant in large graphs.
In practice, you are very unlikely to see a meaningful performance gap.
@@adambickford8720 Sure, but you can have that with mutable data as well. If you're passing data to who knows where then immutable makes sense. If you're working with data locally or you get an input that needs to be adjusted somehow inside of the current logic but not outside, clone it.
It just feels like people just don't know what they are doing and immutable data feels like a protection against that.
I also want to point out that pretty much half of the performance issues I encounter are memory-related, so I am not so sure about that unlikely performance gap.
@@CottidaeSEA its a different paradigm with its own pros and cons. its not that people don't understand, they just don't agree on the value of the trade-offs.
immutable code is easier to understand as you don't have to worry about state over time. you don't have to 'manage' state, so it reduces bugs. it's a big part of why functional programming is on the rise and these apis support that nicely.
if performance is critical you might want to consider something like persistent structs, object pooling, mutable structs, etc. but if you don't have measurements and SLAs, the 'performance' claim isn't very convincing.
Haha, js should make toMap mutate, so js can remain consistently inconsistent 🤣🤣
Why the hostility towards Haskell?
Because it has no actual use.
Lol
I really like how much shit fireship and prime talk about popular technologies while also using a lot of them daily. Much prefer that over these weird "my language/framework is the best language/framework" fights
Folks who can do that about any of the things they use or like are generally better people to work and live with anyway
They both also stand their favourite things regularly, they just mix it up
HTMX
เรือดับเพลิง
Bro don't give them ideas about toMap, oh no...
Next copied remix before everyone else copied next.
New JS devs are Haskell-wannabes without virginity.
6:31 btw which website is that??
Nice video
are the haskel community pissed....?
.... Maybe
Guys I have important announcement to make, please take it seriously:
I hate web development.
(also javascript is dangerous to your well-being)
JavaScript => JavaShit
Extra virgin Haskell
W
Hey man, arent you taking away views and revenue from fireship by streaming his entire video on your channel?
Dockerizing Next is really not that hard. Skill issue...
First.
Vue is cool. Don't use it.
I don't seem to love vue.
Vue is really not that great, since we have 2 api's to do the sam thing.
Next now also had 2 flavour, Angular just got another api to write templete and Svelte about to release another way to write reactive stuff
Everyone does it now
@@khangle6872 Which is a bad thing.
Every year they have to change their opinion what a decent webapp has to look like. It sucks. I've rarely seen any improvements being worth the changes and the mess they create.
Vue with options api was perfectly fine. Like react was in 2014 or Angular 2 in 2017.
I also hate the argument of "programming language X is a lot different these days because it now has Y" which means they offer more ways to do the same thing or they created a mess with breaking changes.
Of course everyone can make changes or invent new libs and frameworks otherwise there would be no improvements at all. However you just can't invent a new more efficent way to do X or Y so frequently.
I think as a developer you waste your time and you benefit more if u have a very basic but extremely flexible techstack like vanilla sql + php/go + some vanilla js/css and spend your time learning these properly & establish a nice workflow instead of switching between fe-frameworks/or-mapper/baas/css-frameworks/... to always get the right abstraction for the current job.
like any other framework and even language
@@moritzschuessler It always depends on the focus of a problem. Both vue api's provide a solution for a quite focused problem which is just annoying.
A programming language does not have a narrow focus like that. So reducing the amount of necessary concepts you have to understand in order to solve a variety of problems should be the priority. It''s difficult to compare.
A similar thing would be if a programming language has 20 different ways to init an object or to create a timer. And on top of that all of these methods seem to do the same but behave slightly different. (I have a C# .NET background)
@@deado7282 new apis are necessary to be backwards compatible. If not it will break when migrating to new versions. If that isn’t the case new versions wouldn’t be possible and there would be way more new frameworks (and languages)
HTMX just frees up so many of the front-end developer's brain cells that were previously occupied keeping up with changes to frameworks
I hate vue
Nice video