When I got into web dev I was confused with all this obscurity that I'm supposed to take for granted. I said to myself that it is the inevitable result of applications that need to be built being complex, but this is a refreshing new perspective. I like simplicity, pretty much why I love Linux, software like ffmpeg, mpv, browse most websites with JS turned off an so on, so when doing something for myself, I try staying away from all this stuff.
@@rumble1925 Good point too. I don't like being overwhelmed with things nobody even tries explaining to me, though it's not the problems of the tools themselves. As long as it doesn't kill performance and clutter output files with megabytes of JS :)
The obsession with having everything done client-side is because of "the cloud" and "cost optimization". Why should they pay more money to their cloud provider for the extra cpu cycles when it can just be unloaded to the clients?
The content is so true, yet we live in a economy that rewards over-engineering web frameworks that are hip and trendy rather than the tried and true methods. Maybe some day hardware will become so expensive because of the miners that devs will revert to a model that considers how precious compute actually is. What LS drop-in are you using in your terminal?
Just exa ( the.exa.website/ ). I would just use plain ls, but I kind of like the appearance it adds. The plain ls colors are kind of terrible and with very little in the way of changing them.
What is the alternative to Electron? I would love to make less bloated apps, but nothing I've seen has the cross platform support with hot reload, popularity, plugins and flexibility without having to pay a massive licensing cost or developing the same codebase 3 times in different languages Electron sucks, but I understand why companies use it. Nothing I've seen compares to how flexible it is.
hi 3:40 they often put random characters in file names to avoid unwanted caching by browsers 6:35 you can still use SSR+SSG with this syntax (see Nuxt/Next or whatever web framework) 7:30 you are in dev mode the built version will be lighter (still bloat tho)
Fair enough. I'll try out the build mode and see how much there is to complain about there. Just out of interest, why would I not want the browser to cache my static image assets? The point I was trying to make was that it seems like something perfectly simple has to be run through loads of unneeded layers of complexity.
tbh , everything is bloated these days , but if i there's a hill i'd on , it would be the use of Nuxtjs and svelt to do anything on the web , they are nice , easy to pick up and amazing to work with great vid btw!
Luke smith influence really shines through this one. You could read about why webpack/component libs are introduced and what they brings to the table and then make this video.
I think Rob Pike influence would be more accurate. I don't deny that they have a purpose, I just say that it is superfluous and there are much better and simpler ways that achieve the same result. It's like Java dependency injection. Has a purpose; really overcomplicated for the result you get.
If I want a website that doesn't have to send a new network request to the server every time the user clicks on a new page, but instead changes the content of the same page (so a single page application), why shouldn't I use JavaScript? Isn't it soyish to use some other language that then transpiles to JavaScript which is then sent to the client when I can just write optimised JavaScript for that myself?
Well, I would argue that the SPA approach to web development is fundamentally flawed. Just creating a consistent experience with SPAs is incredibly hard or requires some kind of really heavy framework, which is all redundant when HTTP gives you the tools to do this already. I have quite a bit of experience with writing these kind of sites as part of my training with React, and not a single one turned out better than if I had just used new network requests. Not to mention performance degradation due to initial download. And JavaScript thread contention. And the complexity of having to use callbacks. This dislike is coming from experience, not blind hate. In general, the main thing I am against is SPAs and not JavaScript in general - although I think it is a horribly designed, flawed language (hence the endorsement of TypeScript). And - no, in my opinion, transpiled languages are not a bad design. C and C++ transpile to native assembler under the hood and are assembled by another program, after all.
I still play it, I really just experience the game by animating it now. Cheating's impact is difficult to understand and explain but it's fair to say it has problems with cheating right now
Seems alright. I would prefer to just not use any kind of extra compiler stage at all (see what I did with Gahoot), but Svelte seems like one of the least harmful options (along with Snowpack, but that is no longer maintained).
Lots of people go for these frameworks because companies also use them and/or just follow whatever hype is in the soydev space Some people don't even believe in static websites I know some guy whos personal/cv website is some weird animation magic scrolling shit made with react. Great channel btw.
@xxh55 Not using frameworks != having plain word document looking websites. You can create a dynamic looking website using vanilla css and a few js libs. No need to send 123mbs of JS thru the wire for a web experience that my makes my laptop overheat.
svelte doesn't suck. i get more done with less code than when i did it with vanilla js. sure i could probably optimize my js code and web components but yeah. i still use webpack even with plain js. lol. i am a lazy dev yes. and i think that webpack plugin is cool lol, i think its funny you hate frameworks and dependencies, yet choose a precompiler for javascript and give yourself more work because you don't bother to understand how type inferences work or want to deal with it
Like I said to the other guy who asked about this - I compiled for release after this. All that seems to do is enables tree pruning (or shaking, is it called?) to remove unused assets and dead code. Perfectly fine change, but still doesn't remove the complexity of the unnecessary webpacking. If webpack just optimised assets, I would have no problem with it. As it stands, I think it kind of sucks.
The way I use TypeScript, it is served directly, unminified and with comments intact. I use TypeScript because I have written large projects in JavaScript before and tore my hair out while working on it. I cannot deal with languages with such poor type systems any more.
@@ej_v2 - Fair enough. I'm not sure how that works, but you obviously know what you're doing. If you prefer writing TypeScript, I don't mind reading it. I'm just tired of the machine generated megascripts, oddball stub files, trendy frameworks etc. You get it. The World Wide Web is a complete mess.
It's meant for big projects, not a hello world program. Also, server-side rendering is pretty ridiculous, the server shouldn't be trying to figure out what the frontend looks like, otherwise under heavy load it will fucking die. It's also more expensive due to higher CPU demands. The only way of doing it is by generating files that are statically loaded into the HTTP server, and JS is just better for anything frontend related anyway. You're just complaining about something simply because you don't understand what is going on and what its purpose is.
I think that a combination of server sided templating and client sided scripting is best. Templating, if designed properly, is really not CPU intensive, especially if implemented in a compile-once way (where you can bind data multiple times to one template AST, similar to Go as mentioned). I should just clear things up. I don't complain about this because I hate Vue or JavaScript (I wouldn't be learning a new framework otherwise :) ) - but I do not like Webpack and I think that stock Vue, which encourages the use of scripting only when needed, rather than for literally every component, is good. This is partly why I also like Alpine, because stock JavaScript is preferred, over loads of abstraction layers. I think that this, out of the box, is much too complicated for something that could be much simpler. Thanks for the comment, btw. I do try to read most of them.
Apart from the runtime weighing a bit too much (a few megabytes last time I checked), I think it's pretty good. Much better than most alternatives, anyway.
@@user-zq8bt6hv9k True. If you look at the people who maintain the language on GitHub, they all have pronouns in their names (not to mention the BLM stuff on the go.dev site). The language itself, however, is alright. It has a purpose as a tool like anything else. When I want a program that's high level and needs to just work, it's much better than C++ for the same purpose.
@@lytix Agree. Like how judgemental do you have to be to judge a person based on a programming language. Sure, there are many over-engineered websites, but why be so rude about it?
Soy devs after installing 2 gigs of dependencies and using vscode to autocomplete pseudo html code
Great deepfakes Luke! Keep it up!
Tried black, tried Australian and they still recognised, so had to try Brittish instead. Foiled again!
When I got into web dev I was confused with all this obscurity that I'm supposed to take for granted. I said to myself that it is the inevitable result of applications that need to be built being complex, but this is a refreshing new perspective. I like simplicity, pretty much why I love Linux, software like ffmpeg, mpv, browse most websites with JS turned off an so on, so when doing something for myself, I try staying away from all this stuff.
@@rumble1925 Good point too. I don't like being overwhelmed with things nobody even tries explaining to me, though it's not the problems of the tools themselves. As long as it doesn't kill performance and clutter output files with megabytes of JS :)
You know its going to be good when he uses ffmpeg to record his screen.
The obsession with having everything done client-side is because of "the cloud" and "cost optimization". Why should they pay more money to their cloud provider for the extra cpu cycles when it can just be unloaded to the clients?
The content is so true, yet we live in a economy that rewards over-engineering web frameworks that are hip and trendy rather than the tried and true methods. Maybe some day hardware will become so expensive because of the miners that devs will revert to a model that considers how precious compute actually is.
What LS drop-in are you using in your terminal?
Just exa ( the.exa.website/ ). I would just use plain ls, but I kind of like the appearance it adds. The plain ls colors are kind of terrible and with very little in the way of changing them.
@@ej_v2 on ubuntu the colors of exa and ls are nearly the same because in the bashrc ls --color=auto is used by default
What is the alternative to Electron? I would love to make less bloated apps, but nothing I've seen has the cross platform support with hot reload, popularity, plugins and flexibility without having to pay a massive licensing cost or developing the same codebase 3 times in different languages
Electron sucks, but I understand why companies use it. Nothing I've seen compares to how flexible it is.
The common way to handle code on the server is Next.js for React and Nuxt.js for Vue.
hi
3:40 they often put random characters in file names to avoid unwanted caching by browsers
6:35 you can still use SSR+SSG with this syntax (see Nuxt/Next or whatever web framework)
7:30 you are in dev mode the built version will be lighter (still bloat tho)
Fair enough. I'll try out the build mode and see how much there is to complain about there. Just out of interest, why would I not want the browser to cache my static image assets? The point I was trying to make was that it seems like something perfectly simple has to be run through loads of unneeded layers of complexity.
tbh , everything is bloated these days , but if i there's a hill i'd on , it would be the use of Nuxtjs and svelt to do anything on the web , they are nice , easy to pick up and amazing to work with
great vid btw!
Luke smith influence really shines through this one. You could read about why webpack/component libs are introduced and what they brings to the table and then make this video.
I think Rob Pike influence would be more accurate. I don't deny that they have a purpose, I just say that it is superfluous and there are much better and simpler ways that achieve the same result. It's like Java dependency injection. Has a purpose; really overcomplicated for the result you get.
@@ej_v2 I mean, you totally aren't Luke Smith, but that video thumbnail resembles some memery only Luke Smith would use.
not sure how complaining about web bloat makes you a "luke smith", maybe your feelings got hurt a little.
@@ChristopherGray00>Dumb Soyjak memes in thunb
>complain about web bloat
>"Soy dev"
Nah, thats literally luke
If I want a website that doesn't have to send a new network request to the server every time the user clicks on a new page, but instead changes the content of the same page (so a single page application), why shouldn't I use JavaScript? Isn't it soyish to use some other language that then transpiles to JavaScript which is then sent to the client when I can just write optimised JavaScript for that myself?
Well, I would argue that the SPA approach to web development is fundamentally flawed. Just creating a consistent experience with SPAs is incredibly hard or requires some kind of really heavy framework, which is all redundant when HTTP gives you the tools to do this already. I have quite a bit of experience with writing these kind of sites as part of my training with React, and not a single one turned out better than if I had just used new network requests. Not to mention performance degradation due to initial download. And JavaScript thread contention. And the complexity of having to use callbacks. This dislike is coming from experience, not blind hate.
In general, the main thing I am against is SPAs and not JavaScript in general - although I think it is a horribly designed, flawed language (hence the endorsement of TypeScript). And - no, in my opinion, transpiled languages are not a bad design. C and C++ transpile to native assembler under the hood and are assembled by another program, after all.
you should change the title to backend gremlin gets confused by the idea of modern devices with web browsers taking the load off of servers
go on bro! somebody had to say all of what you've said!!!
I have no idea what any of this means but I like watching rants. well, i sort of understand it, but definitely not most.
Love your gmod animation. Do you still play TF2, by the way? I've been told it's having some problems with cheating.
I still play it, I really just experience the game by animating it now. Cheating's impact is difficult to understand and explain but it's fair to say it has problems with cheating right now
15:28 Capital B is bytes
I use them on bindings but I'm not a fan of that extra steps of transpiling and compiling. So bloated.
Any thoughts on Svelte?
Seems alright. I would prefer to just not use any kind of extra compiler stage at all (see what I did with Gahoot), but Svelte seems like one of the least harmful options (along with Snowpack, but that is no longer maintained).
now i use astro so that i can ship with no js and at the same time i can integrate some bloats on my blog.
Lots of people go for these frameworks because companies also use them and/or just follow whatever hype is in the soydev space
Some people don't even believe in static websites I know some guy whos personal/cv website is some weird animation magic scrolling shit made with react.
Great channel btw.
god forbid someone have a cv website with some personality and fun stuff instead of a fucking plain html doc
@xxh55 Not using frameworks != having plain word document looking websites.
You can create a dynamic looking website using vanilla css and a few js libs. No need to send 123mbs of JS thru the wire for a web experience that my makes my laptop overheat.
Very nice Ethan!
What do you think of Svelte + Vite?
What would be your chosen full stack?
nginx, mariadb, phpmyadmin(optional), php -> html + css. javascript only to load on scroll and translate dates from utc to local time
svelte doesn't suck. i get more done with less code than when i did it with vanilla js. sure i could probably optimize my js code and web components but yeah. i still use webpack even with plain js. lol. i am a lazy dev yes. and i think that webpack plugin is cool lol, i think its funny you hate frameworks and dependencies, yet choose a precompiler for javascript and give yourself more work because you don't bother to understand how type inferences work or want to deal with it
dude the code isn't optimized you're running the development build instead of the production build
Like I said to the other guy who asked about this - I compiled for release after this. All that seems to do is enables tree pruning (or shaking, is it called?) to remove unused assets and dead code. Perfectly fine change, but still doesn't remove the complexity of the unnecessary webpacking. If webpack just optimised assets, I would have no problem with it. As it stands, I think it kind of sucks.
Typescript sucks as well. It's better to just serve source code directly, comments intact, and use automatic compression on the server.
The way I use TypeScript, it is served directly, unminified and with comments intact. I use TypeScript because I have written large projects in JavaScript before and tore my hair out while working on it. I cannot deal with languages with such poor type systems any more.
@@ej_v2 - Fair enough. I'm not sure how that works, but you obviously know what you're doing. If you prefer writing TypeScript, I don't mind reading it. I'm just tired of the machine generated megascripts, oddball stub files, trendy frameworks etc. You get it. The World Wide Web is a complete mess.
@@ej_v2 - P.S. I really enjoyed the video
@@PIX_BMS I absolutely get the sentiment. It was so cool being able to just open up and read through a site's script file. Glad you enjoyed :)
I'm sorry but server side rendering it's just awful, I worked with both and it's a reason why it's fading away
this is why firefox is slow
"modnern"
It's meant for big projects, not a hello world program. Also, server-side rendering is pretty ridiculous, the server shouldn't be trying to figure out what the frontend looks like, otherwise under heavy load it will fucking die. It's also more expensive due to higher CPU demands. The only way of doing it is by generating files that are statically loaded into the HTTP server, and JS is just better for anything frontend related anyway.
You're just complaining about something simply because you don't understand what is going on and what its purpose is.
I think that a combination of server sided templating and client sided scripting is best. Templating, if designed properly, is really not CPU intensive, especially if implemented in a compile-once way (where you can bind data multiple times to one template AST, similar to Go as mentioned).
I should just clear things up. I don't complain about this because I hate Vue or JavaScript (I wouldn't be learning a new framework otherwise :) ) - but I do not like Webpack and I think that stock Vue, which encourages the use of scripting only when needed, rather than for literally every component, is good. This is partly why I also like Alpine, because stock JavaScript is preferred, over loads of abstraction layers. I think that this, out of the box, is much too complicated for something that could be much simpler.
Thanks for the comment, btw. I do try to read most of them.
Web 2.0 has always been terrible.
hi
golang is also a soy language tbf
Apart from the runtime weighing a bit too much (a few megabytes last time I checked), I think it's pretty good. Much better than most alternatives, anyway.
@@ej_v2 it's massively adopted by the gafam fanboys, which are by definition soy devs. thus it's a soy language
@@user-zq8bt6hv9k True. If you look at the people who maintain the language on GitHub, they all have pronouns in their names (not to mention the BLM stuff on the go.dev site). The language itself, however, is alright. It has a purpose as a tool like anything else. When I want a program that's high level and needs to just work, it's much better than C++ for the same purpose.
@@lytix Agree. Like how judgemental do you have to be to judge a person based on a programming language. Sure, there are many over-engineered websites, but why be so rude about it?
@@rkvkydqf Don't take it too seriously. I have a very dry sense of humor. :)