Every time you start at a long established company, there are tons of ‘tried it, didn’t work’ people who’ve been there for 15-20 years. It is frustrating when the thing they’re saying doesn’t work is basically even industry standard. I’ve run into that working as a game developer. Very frustrating.
@amotriuc Жыл бұрын
That's true it can be frustrated but there is no clear yes/no answer here. People with no experience have a tendency to think they know better then someone who has experience, but most often they are wrong and only sometimes they are right. But on the other side no one should just use one argument “We tried that, it didn’t work” it should be much more clear than that: what didn't work and why.
@JorgetePanete Жыл бұрын
industry standard ≠ good look at javascript
@x--. Жыл бұрын
I usually spend more time trying to come up with how I'm going to respond to potential "We've tried that" and "That's impossible" responses than on an original idea. And yeah... sometimes I'm missing a crucial hidden requirement that kills an idea but sometimes, it's just a lot of "Nope, nope, nope... [not my idea]"
@jlr3739 Жыл бұрын
@@amotriuc Experience cuts both ways. I have enough experience now (~6 years working professionally) that I understand the ability to spot potential problems ahead of time-things a new person likely isn't considering, etc. This is not the person I'm talking about. The person I'm talking about is someone who has 'experience,' but has also spent 15-20 years giving up as soon as they encountered resistance on a problem. Aim assist, capsule/camera separation, and more-very standard game features that are ignored because they tried and failed at it once. Experience can inform you and give you a good ability to anticipate problems, but if you're not engaging with it critically or thoughtfully, it can also keep you stuck in your ways and refusing to react to the landscape changing beneath you.
@marcinhou Жыл бұрын
Arthur C. Clarke: "When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong."
@blarghblargh Жыл бұрын
I love DHH half the time, and think he's the biggest exhaust huffing techbro the other half the time. Either way, it's usually an interesting ride.
@woolfel Жыл бұрын
when you keep external dependencies to a minimum, it avoids a lot of problems. I was on a healthcare application in the past and it easily had 10K+ libraries. I was kinda shocked. For my own open source projects I work really hard to keep dependencies less than 10.
@airman122469 Жыл бұрын
“We tried that, it didn’t work” Is always a phrase that when I hear it I immediately think “but did you consider any other perspective?”
@alexandrep4913 Жыл бұрын
Believe 👏 all 👏 attempts 👏
@twenty-fifth420 Жыл бұрын
Yeah in my opinion, that phrase is just apathetic indifference. “We tried.” Okay, but how *hard* did you try? Are we talking like a tad, a lot, did you try different strategies orthodox and unorthodox? It is a cop out to me. My first lizard brain response is to reply back “Well, TRY again!”
@rmidifferent8906 Жыл бұрын
Follow up question to people saying this: but what if you tried it wrong?
@uuu12343 Жыл бұрын
@@twenty-fifth420you are a manager in the making Because alot of the times, when you are not in the team, you can keep screaming that, doesnt mean you understand how THAT implementation happened What the FUCK does "Try harder" mean? Try harder in what? Try harder in that thing that DIDNT FUCKING WORK????
@sorcdk2880 Жыл бұрын
nah, the actually follow up question is: "what went wrong?", because once they answer that, it becomes so much more obvious what needs to be done to get past it.
@fsouza Жыл бұрын
"intellectual failure state" is now my favorite way of calling someone stupid 😂
@Lemmy4555 Жыл бұрын
not a smart move at all since he can't prove his way is objectively the good way, the guy just have a big ego and want to be polarizing.
@samuelodan2376 Жыл бұрын
are trolling? Where did he say his way is the objectively good way. Or are you also in an “intellectual failure state”?
@Lemmy4555 Жыл бұрын
@@samuelodan2376 you have to choose either who use ts does it because has "intelectual failure state" or the article is only about his personal taste and he doesn't want to demonstrate that dropping TS is neither a good or a bad thing.
@samuelodan2376 Жыл бұрын
@@Lemmy4555 you sound you have a grudge from before this article, and that’s understandable. But to respond to this article in a way that suggests you have an issue with the piece itself is misleading, to say the least.
@DontFollowZim Жыл бұрын
When he said Zod doesn't work with jsdoc, what he meant was that when you create object schemas in Zod, you then create the type via z.infer so that the type is always up to date with the Zod schema instead rewriting the type somewhere and having to keep both in sync.
@SRG-Learn-Code Жыл бұрын
Care to explain like im a junior noob? I wish to learn more about jsdocs and zod.
@lucrativelepton Жыл бұрын
@DontFollowZim I wonder if this would work /** @type {z.infer} */
@lucrativelepton Жыл бұрын
@@SRG-Learn-Code jsdocs add annotations to your code. You can write special comments that have a syntax that tell you, your fellow devs, and your IDE stuff like "this function returns a number". It's a way to add type information about your objects and whatnot without writing typescript. Imagine you have an http request handler in express, and you're working with `req.body` or whatever. req.body is the object uploaded by a user and could be anything. You could write a jsdoc comment that annotates the body with type information. It's basically like saying "this request body should be an object with a username and password properties, both of which are strings". It's helpful to describe your expectations for that object, especially since your IDE can autocomplete the properties it knows about while you're working with it. You can even have a build step that actually verifies you aren't doing anything risky. But how do you ACTUALLY know it's what you expect? Remember the user can technically send you anything at runtime. That's where zod can come in. You use zod to define a schema for something and then validate it matches that schema _at runtime_. That way you KNOW that you're working with exactly what you expect. The coolest part of zod is that you can just define the schema, and doing the zod validation automatically adds the type information you'd get with jsdoc or typescript.
@josephchen8738 Жыл бұрын
this man uses zod
@SeknaTS Жыл бұрын
Does z.infer not work in (typescript powered) jsdoc?
@usher-p Жыл бұрын
Tons of love to prime for this! By the way, did you know he works for Netflix?
@rocstar3000 Жыл бұрын
Wow!! And also program in Rust btw (this comment is not sponsored by the Rust foundation™)
@NubeBuster Жыл бұрын
He thinks C++ sucks. I agree
@skinneymoney Жыл бұрын
I wonder if he gets a free Netflix subscription
@WhoaFeelings Жыл бұрын
I still don't know he works for Netflix
@kaffeetscherl Жыл бұрын
12:44 okay, okay. let's be honest. Prime, you and me love those comments for one reason: We were moulded with Java. It's still in our blood. Having an interface with just a handful of methods with beautiful crafted JavaDoc on top is still beautiful to look at.
@origamitraveler74257 ай бұрын
TRUE
@mage3690 Жыл бұрын
"That lowering our collective ambition to whatever was unachievable by others is somehow good." Occasionally, I'll run across phrases that I just _have_ to put in a Google doc file along with all the other little sayings that just made me stare at a brick wall for a solid minute and contemplate life. That was one of them. Thanks, DHH, for verbalizing a sentiment I've had since the 3rd grade, but could never say for myself.
@LeonMarzahn-t6n Жыл бұрын
There is nothing wrong with no build Javascript, just like how there is nothing wrong with no build assembly. But when I want to have a reusable component and maybe a drop down, I might pick building/bundling/compiling over figuring out how to maintain my code in pure JavaScript. In all my years as a developer I have learned to pick my battles. Anything that makes me write code fast and readable is a trade-off I can deal with.
@levifig Жыл бұрын
In my career, I've ran into this kind of mentality plenty of times. As I moved into more strategic roles, I ended up developing a kind of a "motto" for the teams I work with: "Be critical, not cynical". The goal is to fight the cynicism that comes from the "it will never work" mentality. Sure: learn from the past, learn from the criticism, but avoid being cynical about the people or experiences that came in the past and of the people who may give it another try in the future… Humans are not immutable. Times change, people change, experiences change.
@krtirtho Жыл бұрын
It amazes me that there's 10s of thousands of JS frameworks which just a declarative wrapper around DOM So if browsers implement a declarative DOM API, I think a lot of the problems goes way automatically. They already added custom HTMLElement support so I don't think it's impossible to create a Declarative DOM API
@thegrumpydeveloper Жыл бұрын
I see where you’re going with this but my initial thought was html was the declarative dom api 😂 it’s just that diffing changes and injecting new/same elements is slow
@thegrumpydeveloper Жыл бұрын
The irony is dhh is pulling a tried that didn’t work for bundling js. I also tried believing dhh and that didn’t work.
@_unknown_guyАй бұрын
Nah, the irony is RoR had basically one of the first JS bundlers in form of Sprockets and it was in 2011. We wrote CoffeeScript starting from then. ES5 was just 2 years out. DHH was all in on bundling/compiling/minifying JS and it worked. Times have changed and Rails is going the Hotwire way. If you need all the JS bundling stuff, it's one flag away.
@dgdev69 Жыл бұрын
Imo Working with js in bigger teams would be painful without ts. For smaller teams it does not matter js with bit of jsdoc is enough.
@-Jason-L Жыл бұрын
Sounds like the use of bigger teams is the problem to solve...
@mrichards Жыл бұрын
this is funnier when you realise the tweet example DHH linked was posted a couple days ago, so he literally wrote this entire blog post because he thought he was losing a twitter argument
@-Jason-L Жыл бұрын
Meh... every post anyone writes is triggered by something
@JohnWilliams-gy5yc Жыл бұрын
When wasm approaches their maturity, I can see JS could be compiled into wasm and then we can compile js components in parallel and then link those together. So the compilation will never go away but it will be very very much faster.
@Exilum Жыл бұрын
I quite liked this article. DHH isn't even wrong most of the time, but I get the community sentiment. He just suffers from sounding like an insufferable (pun intended) assh*le half of the time. He's just overconfident. When he's wrong, he's confidently wrong, and even when he's right, his confidence just pushes him much farther than it should.
@CottidaeSEA Жыл бұрын
I think the no build JavaScript is reasonable. If you do not have a bunch of various dependencies, particularly stuff like React, you'll naturally have a much more reasonable code base to work with in order to achieve that goal. In one way it is putting the cart before the horse, but I believe that's a matter of mindset. If removing the build step without losing functionality *is* the goal, all would be in order.
@brentlio5578 Жыл бұрын
I must show appreciation of the awesome PrimeAgen bringing us all these great articles and his funny/knowledgable/memetic takes on them. LOL
@noredine Жыл бұрын
3:53 "Been there, done that, messed around I'm having fun, don't put me down I'll never let you sweep me off my feet" - Bulletproof
@richardnpaul_mob Жыл бұрын
Yeah I've had this, come to a new company, ask the question "why are you doing all this crazy stuff, why not do this?", them "oh we tried that and couldn't get it to work", me "Erm, I've worked in a team that got it to work what problems did you hit?", them "oh we had this issue", me "why the hell were you trying to do that? That's crazy, of course that's not going to work, why didn't you so this?", them "oh, we didn't know about that it probably wasn't a thing then", me "we did this 7 years ago, it has been a thing for a decade or so".
@sorcdk2880 Жыл бұрын
While this is the way to break past things that people are stuck with, it is also not particularly diplomatic, and grinding the wheels of those with seniority at a new company might not make you particularly popular, which in turn can make it harder to get changes through. The last part is especially bad, because you got it to the point of "we just didn't know about it", which is a clear signal that you removed most of their resistance to change, and beating them up after that is just pissing on their dignity.
@richardnpaul_mob Жыл бұрын
@@sorcdk2880 I'm not looking to win any popularity contests, but then I'm a DevOps engineer so 🤷, I have had to fix a lot of things here and change people's outlook in my team and then from my team start to change the wider engineering's focus which has finally started to get through and filter up. The last part was just an Internet search away, which they would have had to do anyway. As it happens, we've now built two working systems, one a proof of concept in the legacy platform, which was tried before and failed, the other in a new green field project. My current resistance I'm trying to overcome is getting people on board with blue/green and designing it into our platforms so that we don't have to have maintenance windows and downtime. Again, I'm getting a lot of resistance but I'm going to try to get it into a new greenfield project that we're building as a proof of concept so that we have have a template we can point to and say look, this is how we should do everywhere. My boss gives me quite a lot of latitude, I present ideas, he appreciates them, schedules them in and we get things done and we're probably the one engineering department that's actually achieving a lot. We have a lot to do, but many of my changes are only now going to get deployed a year or so later.
@pxkqd Жыл бұрын
I don't understand the hate against bundling. I mean, I can understand the webpack ptsd, but you can use vite or bun these days. It just works. I've started multiple projects with vite for web, server, cli... Takes at most a couple hours if you need to config something specific. If you just want something established in any modern framework, it's automatic.
@travispulley5288 Жыл бұрын
This really weirds me out too, especially juxtaposed to c# dev environments. I've got a complex js full stack using hmr that shows my changes faster than visual studio can tell I clicked on something. I don't even have to debug a .csproj file to avoid invoking a complicated web of build dependencies just to run a simple unit test.
@timseguine2 Жыл бұрын
I even handrolled my own bundler back in the day with the google closure compiler and it wasn't what I would describe as difficult. I even had caching working with very little effort. Honestly web devs these days have it easy compared to the dark ages, and if your biggest pain point is bundling, then I feel like you don't really have significant pain points.
@_unknown_guyАй бұрын
I'm not sure people understand that Rails had JS bundling in 2011 when there was no JS bundling and DHH embraced it. Webpacker was 2014 which Rails adopted as default later, now even bun is one of the default options. Times have changed. If you don't write frontend in JS, why the hell you want a build step. JS devs view it only from their narrow perspective.
@br3nto Жыл бұрын
12:02 what’s great about importmap is that you can do both. You can have a project that uses both unprocessed JS AND pre-processed JS. 🤯. I know that defeats the argument against no-build but the choice should be about how and where we manage complexity. E.g only put what you need through a build step, and the rest leave untouched. Maybe that just adds more complexity or maybe that makes things simpler… that’s for each team to decide and manage.
@ivonakis Жыл бұрын
In our company we have the the "We tried that, didn't work, but we are doing it anyway" problem - I am talking to processes inside and outside the team .
@AveN7ers Жыл бұрын
@8:20 he likes TypeScript now ?? This guy changes his mind faster than JS libraries are created.
@banned_from_eating_cookies Жыл бұрын
Prime frequently jokes about various languages/frameworks and some don’t get that he’s joking. I’ve noticed that a lot of his live chat think he’s being serious.
@yogabija Жыл бұрын
Yes, please do spend time showing us how you use the stuff you like. Would be very interesting. Especially as finding time to learn new things can be a challenge. Seeing you share things which you like, could make it more easy to spend time on something new.
@FunctionGermany Жыл бұрын
there's no "without typescript but using JSdoc". all the intellisense is still driven by typescript. "generics" aren't a thing in JSdoc - TS interprets them. so what it actually is is TypeScript development but without .ts files and having to compile those.
@greeffer Жыл бұрын
I made two new projects using the cli tool in svelte. One was JSDOC the other was TS. The config files (jsconfig.json and tsconfig.json) were exactly the same, only the name of the file was different.🤔
@unicodefox Жыл бұрын
> We've been running HEY without bundling or compiling JavaScript for 3 years now i open developer tools and it automatically loads a source map for a file ending with .min-7ea3d58b7f4507e3603ec999251ff60d16431a30.js *#NOBUILD** JAVASCRIPT*
@OldKing11100 Жыл бұрын
HTMX + SurrealJS have been a ton of fun to work with. Being able extend HTML then use JS inline with easy helper syntax has made JS frameworks feel unnecessary.
@georgehelyar Жыл бұрын
It's useful to ask other people who have tried before so that you can avoid hitting the same problems, and then see if you can find anything that they missed. There are times when it genuinely doesn't work though. You can't make raster graphics scale as well as vector graphics, you can't set some specific request headers in JS in a browser, etc. Real feature requests I've had to say no to.
@kasper_573 Жыл бұрын
8:19 Prime ”I like to use typescript” Agen
@DecoyBBQCam Жыл бұрын
prime: works at netflix and releases two thirty minute videos a day
@airman122469 Жыл бұрын
Makes you wonder about his work hours doesn’t it?
@ea_naseer Жыл бұрын
@@airman122469probably remote
@mikeha Жыл бұрын
@@airman122469 he does livestreams and breaks them up into separate videos. he has a schedule that he has agreed to with netflix and they're ok with it
@IvanRandomDude Жыл бұрын
Plot twist: Prime is the guy behind anonymous email from few weeks ago stating that he works hours per week.
@davidomar742 Жыл бұрын
this is from his livestream. and he doesn't edit his own videos so he spends his time wisely
@S4ntia60 Жыл бұрын
As a backend dev, I love this front end people dramas and fights about which java script framework derivative is better
@-Jason-L Жыл бұрын
Backend dev = being exposed to a fraction of what is required to deliver solutions to users.
@S4ntia60 Жыл бұрын
@@-Jason-L of the 2 (main) fractions. Argument works both ways. And still does not make the JS dramas less enjoyable
@Wielorybkek Жыл бұрын
The problem is people cannot stop themselves from using general statements. Always! Never! Everyone! etc...
@nethsarasandeepaelvitigala135 Жыл бұрын
Damn, I'm super early today, this is the first time I was this early to anything lol
@DonAlonzo Жыл бұрын
I tried that, didn't work
@WilsonSilva90 Жыл бұрын
@@DonAlonzo skill issue
@05xpeter Жыл бұрын
Any body that takes decisions on to ‘tried it, didn’t work’ without requiring a "what didn't work?". Should not be taking technical decisions
@HeberLopez Жыл бұрын
Can I say I really like the idea behind qwik for achieving similar results while still keeping many of the things we’ve come to love over time? Also, perspective is everything in regards to projects. Not every project is the same and not every project has to either, play around with things and make your own opinions with an open mind, if someone spent the time building a tool, there’s likely an underlying problem that was trying to be fixed, don’t just ignore it based on what it sounds like but rather try to understand it from the perspective of who built it and why, and then make your own opinion of it
@Spongman Жыл бұрын
the irony is, of course, that DHH is saying, about javascript bundling: "tried that, didn't work"
@LiveErrors Жыл бұрын
Btw, how does being dyslexic affect your ability to read code? Does it affect how you like your syntax?
@alexandrep4913 Жыл бұрын
It feels like your brain is copying and pasting snippets of code at random times. Its also a good indicator on whether the language you are using is sorta garbage or not when it comes to syntax. Languages like C and Go have it really good where you can much more easier read it. Languages like Java, Rust and Typescript (not a language, just a documentation tool we decided was one, but whatever) just feels like you're reading chicken scratch.
@ThePrimeTimeagen Жыл бұрын
difficult is the answer, try hard i must
@paddygozie7337 Жыл бұрын
@@ThePrimeTimeagen proceed you can
@unowenwasholo Жыл бұрын
Feels like a strong “Eat the fish, spit the bones” article. You can cut out everything between the second and last paragraphs and lose nothing. It feels like DHH mostly wanted to complain that someone turned their nose up at his project. The self-aggrandizing is a strong turnoff. I have absolutely no clue what is being discussed in the article. There is not enough context or information on why whatever DHH is working on is actually worth looking into. It assumes that just by saying “it can do the thing” that I’m supposed to know what thing it can do, or even what “it” is. One could argue that’s it’s not supposed to be a piece of marketing, but DHH is clearly rushing to the defense of something (HEY?). Any other messaging gets lost in the retaliatory holier-than-thou presentation. Even if he’s trying to be sarcastic, he comes off as bitter to me. But hey, I’m just a smooth-brain TS dev. I only use what gets my product out the door the quickest. Maybe this article is just how the real pros talk and it’s over my head for that reason.
@AustinMarlar Жыл бұрын
I share this sentiment with DHH in general, so many of his takes annoy me. His recent keynote puts most of it into context though and now I see that the vision of DHH is not all that different than what Prime and his audience (us) are interested in. Look for: Rails World 2023 Opening Keynote - David Heinemeier Hansson He start his talk around 10min and the better parts start around the 20min mark. The TLDR is that: - We have too much bloat - Server rendering is cool - Solutions like HTMX/Turbo/Unpolly mixed with interactivity solutions like Alpine/Stimuls/JS are great at giving us what React/Vue/Angular/Svelt give us with a fraction of the JS/TS DHH as a person still annoys me but many of his ideas have a solid foundation.
@SimonBuchanNz Жыл бұрын
The TLDR seems to be "import maps exist now, so with a bunch of effort you don't need a build to get good performance" Yeah, but with the same effort you get even better performance.
@travispulley5288 Жыл бұрын
It's one thing to have terminal doubt, it's another to recognize a system that is prone to failure in ways that are observable and consistent. And then deny those failures, compensating for them by depleting value from something else. And then asserting that the failure is in fact success by misattiributing the compensation efforts. Then distributing punishment in the areas that are depleted for falling behind expectations. Should I throw my dev skills in the trash to become a scrum master instead?
@kellyaquinastomАй бұрын
Prime stack: typescript htmx web components etc. Maybe jsdoc 8:12
@fennecbesixdouze1794 Жыл бұрын
@9:57 This is nonsense. In this paragraph, DHH says removing layers of abstraction leads to "conceptual compression", but in the link he gives in that paragraph it's literally a talk by DHH explaining about how layering an ORM on top of Postgres creates "conceptual compression". Clearly whatever is good about programming, it's not just about removing layers or adding layers of abstraction. You can't make blanket statements that removing layers of abstraction always results in simpler code or less conceptual complexity. It's clearly about using the *right* abstractions for your use case. For some use cases, an ORM will help. For other use cases, an ORM very much gets in the way and you really just want some sort of DAO. If anything, you actually get tons of conceptual compression by pulling in tons of dependencies. You only start to see the problems as your application matures and you want to do more with it than your frameworks easily enable. In the case of Rails, the real problem DHH clearly has is simply that building a Javascript-heavy system ends up putting Rails in the backseat. It's not that one way has more "conceptual compression" than the other, it's just that DHH prefers writing traditional MPA template-engine based SSR Ruby monoliths with just a bit of Javascript sprinkled in.
@laughingvampire7555 Жыл бұрын
if you have 10,000 dependencies you are not using the tool for the job, you are transforming the web into what its not.
@travispulley5288 Жыл бұрын
"transforming the web into what its not" - pinterest is the first thing that comes to mind, but the same anti-design could be made with no-build js too
@Jebusankel Жыл бұрын
If the tooling for jsdoc was really tight to the point that it was nearly the same experience as typescript I could like it.
@ravenecho2410 Жыл бұрын
@2:00 ohhhhh noooo, ive heard that around as well
@simonwillover4175 Жыл бұрын
Who would ever think that fallacy to begin with? I am beyond confused.
@BillLambert Жыл бұрын
Anything - *anything* - that keeps Node and npm away from my boxen is super-duper-welcome in my world. We have gone so far down the cancer-slide to JS hell it's turned everyone into masochists.
@rapzid3536 Жыл бұрын
DHH the kinda guy to address the straw man in the room.
@tensor5113 Жыл бұрын
1:00 A recent project I worked on needed ETL, sql was the obvious option but the previous developers tried to make everything fit in memory, it kinda worked but very slowly and the state management was super complex leading to the data being unreliable. Could this be fixed? sure, but then who wants to put in the man hours to reintroduce and solve a data problem that has already been solved
@SimonBuchanNz Жыл бұрын
Interesting perspective: I've seen the other side: a full ETL setup that takes over an hour for processing only gigabytes of data at most (and often megabytes!). It should have been entirely IO bound, and finished in seconds.
@10Rmorais Жыл бұрын
Nice. I get the feeling that it kinda hurts Prime to agree with DHH, but happy to see he isn't blindly just attacking DHH cause it's his post.
@patricknelson Жыл бұрын
I like JSDoc. It’s a little odd sometimes, but it certain gets the job done for me when I’m in PoJS.
@TheCauthon Жыл бұрын
I love that you are reading C.S. Lewis.
@Thect Жыл бұрын
Hate to admit, he's got a really nice point
@BittermanAndy Жыл бұрын
I was with it until the very end, when he basically said "I learn three different flavour-of-the-month web frameworks every week to avoid having to need to learn too many things just to make something work!". This is why web dev is an absolute clusterfuck and always has been.
@JustBCWi Жыл бұрын
2:00 +1 C.S. Lewis Quote. +100 for a positive take on DHH. I coded in the 2000s and stopped before Rails became a thing. I've been in product manager hades for the past 15 years, but watching what has come out over the past few years is dragging me more into hobby projects that are removing cobwebs created by years of status meetings.
@ThePrimeTimeagen Жыл бұрын
thats pretty fun
@JustBCWi Жыл бұрын
@@ThePrimeTimeagen The letters FUN are not used in spelling status meetings. Love your content, mostly on YT but sometimes on Twitch when the time is right. Even my wife laughs at the jokes. Mostly entertaining, frequently educational. Have you ever thought of applying for an internship at Neflix?
@stanrock8015 Жыл бұрын
I hear this all the time and truth is rarely have same issues. 🤷♂️
@iojourny Жыл бұрын
Great article. In my framework (which powered our startup for 4+ years, until it unfortunately closed this one) I went a very, very long way to allow on-the-fly bundling/minification of JS /CSS files (also SCSS support). It leaves the option open for a build step (just add the already-minified JS artifacts from that step to the resources in your own bundle manifest), but ideally, you just add a few arrays/objects of local JS/CSS resource URLs at the start of each page (can also use certain pre-defined collections from the DB, if that's your thing), and the manager will automatically check resource freshness, update/create new minified files/bundles if needed, and return the URIs. Fully lavarages server-side resource caching headers, allows serving non-minified versions in DevMode, etc. One of the reasons our local / dev / prod environments were so easy to set up and maintain.
@nexovec Жыл бұрын
Is this That one guy with unpopular opinions? Because this is a good article.
@deltafactory Жыл бұрын
Anyone know what diagram tool he uses?
@PaulSebastianM Жыл бұрын
Try Effect-TS/Schema if you don't like Zod.
@lightningx10 Жыл бұрын
I see the clown in the thumbnail, I click. Quite liked his take in this article though :)
@astronemir Жыл бұрын
I face this daily at work.
@maximenadeau9453 Жыл бұрын
I think Sveltekit fixed that issue, it's a compiler, it sends minimal amount of JS to the browser that is all vanilla and devoid of framework glue/bullshit
@pxkqd Жыл бұрын
I don't think you understood. They want to write js and not have any compiler or build. Totally the opposite of Sveltkit which is a DSL and a compiler.
@maximenadeau9453 Жыл бұрын
@@pxkqdYeah I got the first point, it's just, why give yourself so much trouble to write dynamic apps when you have such good DX with no cost.
@DaveWarnock11 ай бұрын
I mock this way of thinking as "we tried that in 1921, it didn't work then and it won't work now"
@aloufin Жыл бұрын
Please move teh Chat in your OBS scene a bit more to the right so it covers less of the article text
@apestogetherstrong341 Жыл бұрын
Please somebody recommend some Rich Hickey talks to Prime. He desperately needs, at least his "Simple made easy" talk, or "Maybe Not" (rust enums are bad, actually).
@FURIArts Жыл бұрын
how much coffee do you consume?
@HenockTesfaye Жыл бұрын
This sounds like trauma. You tried it as a kid, and you haven't tried it since even though a lot has changed.
@omofolarinajibade Жыл бұрын
Yeah his photo 😹
@Wzymedia Жыл бұрын
As far as I am concerned, if you're going to patiently prowling DHH Twitter feed just to be contrarian to whatever he says you should have an OSS project that did as much for developers as Rails did.
@elcugo Жыл бұрын
Did DHH kick Prime's dog or something?
@apollolux Жыл бұрын
I've been using "no-build JS" for literal decades. I genuinely don't understand why people voluntarily chose to intentionally complicate things for themselves by adding extra tooling nonsense instead of simplifying the things they want to build and getting better at programming by practicing useful general purpose stuff that can apply to a bunch of problems.
@travispulley5288 Жыл бұрын
How's that working for you? I'm skeptical but open minded. Every time I find a good premade solution that saves me from having to reinvent it myself, I feel a spurt of joy knowing how much laborious time I don't have to spend making a lesser solution. ex: I know how to debounce input for a no-build js design, but I use react and someone else made a hook that is simple and works very well. The client code I make to use it is elegant and minimal, plus it's very sensible within the react design I'm already using. For your case, I'm wondering what it's like for more complex things like retrying an api endpoint smoothly. (I like how tRPC solves this, and I'm glad to have it in my project)
@apollolux Жыл бұрын
@@travispulley5288 For the majority of my professional work, I haven't needed to do work that was so complex either upfront or became complex over time that warranted explicit build systems like webpack, migration to Typescript, etc. even if it was still attached to CI/CD or something because of corporate policy or whatever, but splitting into multi-tiered environments (minimum dev/prod, preferably dev/staging/prod) is a must regardless. A lot of it has to do with design docs and spec'ing the projects out ahead of time to get resources ready, not just for allocation and budget reasons but also to get in a mindset where if you think XYZ piece of project has a "small" function relative to the project then it should expect a "small" amount of work relative to the rest of the project and likely not _need_ something like an external dependency to work if someone on the team has the knowledge and skill to implement it. Most of the time it was less about having a "robust" solution that a third-party that theoretically had spent more time and effort making and putting through the ringer and more about having a "good enough" solution that worked for what we needed and gracefully handled errors if we missed a blind spot. As for stuff like API testing, I only recall having to be hardcore about that at $_MAJOR_US_BANK, and even then there was explicit test data in the local database to confirm formats and such and I usually used a browser extension version of one of the policy-approved apps for checking results combined with the browser's dev tools. Pretty sure it was a commercial program, so I never had a copy of it for my own personal use.
@BeamMonsterZeus Жыл бұрын
Someone should email DHH and let him know about the outdated "a e s t h e t i c" memes. Maybe he'll stop grayscaling every picture of himself.
@arcuscerebellumus8797 Жыл бұрын
To be fair, "tried that - didn't work" is not a universally bad argument. But I agree that it's extremly overused and verging on falacy. And not just in programing, for that matte... for me a first things that comes to mind is politics, for example. Label everything as "tried that" and you no longer have to change or justify anything. The way things are NOW is as perfect as it will ever get. Francis Fukuyama kinda deal...
@jordixboy Жыл бұрын
You mostly need compression because you use bloated libraries/frameworks. No frameworks = no compression, make a lot of sense to me. The fact that people dont understand this is shocking. Nowadays seems like web equals using a framework yes or yes, lol
@SimonBuchanNz Жыл бұрын
Well, yeah, check your bloat, but that doesn't mean compression and bundling somehow don't make it better. Why use an import map to optimize loading 20 carefully handcrafted JS files, when you could just load one JS file that's half the size? You need to build an import map and/or handle cache-busting anyway, so it's not like you're actually skipping a build step.
@samuelschwager Жыл бұрын
pottery stream when?
@JChen7 Жыл бұрын
I think the struggle is real between "tried that, didn't work" and "doing the same thing repeatedly == definition of insanity." The only cure is probably going back to first principles thinking and asking WHY it failed previously.
@orbatos Жыл бұрын
This is very butthurt, but they are right deepening on the context. Big systems often can't be done this way simply due to complexity.
@AsbestosSoup Жыл бұрын
AGENN
@charlesssgraham Жыл бұрын
Sharing something you think is cool and not obnoxiously preaching your opinion? How dare this man try to take the toxicity out of the internet 😂
@ordep1132 Жыл бұрын
You'll become a DHH fan.
@ordep1132 Жыл бұрын
Few articles missing from the epiphany.
@ordep1132 Жыл бұрын
Then, you'll drop everything else and code with ruby 24/7.
@ghun131 Жыл бұрын
The thing that makes me dislike about jsdoc is that it's comments. Soon enough I forget the type
@-Jason-L Жыл бұрын
IDEs can parse those comments
@lleytonmorris6305 Жыл бұрын
I love types. My company doesn't use typescript so we had to make some exceptions. .d.ts files and a lot of JSDocs later and we are getting to the point where code is a bit more safe... still a lot of any's and I guess no build. Our computers are underpowered and we only have 16GB of memory so we when I run WSL2 + vscode server + a react server + the VM with a couple of services running on it + all the the other crap required to communicate with colleagues, TS runs like garbage. Honestly at the point where I just stop the dev server while I am writing code and just take the minute sitting there waiting for it to compile, just so the language server can be a bit faster because it has an extra 1-2GB of memory. I don't know what my TLDR was meant to be... but at least JSDocs lets me import the .d.ts files and no one seems to have a problem with me writing that code in the codebase
@AdroSlice Жыл бұрын
I tried watching this video, didn't work
@timseguine2 Жыл бұрын
I don't think he is wrong. I just find it strange that he is treating it in terms of his tone like a hill worth dying on. If you write everything like it is a polemic, then you shouldn't be surprised if people react to it like one even if the content is milquetoast at best.
@tehpsalmist Жыл бұрын
Prime is good for the dev world. Moar critical thinking please!!!!
@dave6012 Жыл бұрын
So he writes everything in common js 😬
@fulconandroadcone9488 Жыл бұрын
You should use types even if you don't like them. It is unacceptable that back-end can't just copy response or request type.
@matteac_rs Жыл бұрын
The amount of hours of debugging that strongly typed languages save you is impressive (typescript doesn't count, its types are hallucinations). a backend can't be performant and reliable without types
@faridguzman91 Жыл бұрын
tried react, didnt work
@chudchadanstud Жыл бұрын
Man webbies have lost it. They're fighting over building JavaScript now. When will you draw the line?
@gund_ua8 ай бұрын
Zod is such bullshit, io-ts is THE GOAT
@lungfish Жыл бұрын
he's talking about twitter abandoning rails lol. that's what killed it
@Lemmy4555 Жыл бұрын
I don't understand why you are obsessed against dependencies, what's that only back-end development is allowed to have dependencies while front-end has to be all about reinventing the wheel every time?
@tiko- Жыл бұрын
I've been using inline JS in a script tag at the bottom of SSR'd HTML since the olden days. It destroys Lighthouse scores and it's easy to hack together but I would imagine other people would hate it so I keep it to solo projects. No build step is nice and it encourages you to minimize JS usage.
@tiko- Жыл бұрын
BTW this strategy will lose compared to a well-cached bundle over enough time. Keep in mind Lighthouse always measures a fresh load which gives a bit of an unfair advantage to inlining (assuming you want users to look at more than one page on your site).