141–150 of 170 posts
We have also tried this approach and I still think that it might be the future. But apart from using it on tiny projects and experiments, the DX is just subpar compared to any modern vite based “build-full” stack.
Wouldn't this require node_modules to be publicly accessible?
Sigh... Another post like this. Sure, it works well enough for the example shown in the article, but won't work well beyond this. Bundlers, package managers and other tools were created to address problems people saw in medium-large projects for websites with a lot of traffic. And as soon as the project has dozens of files and even just two or three external libraries, this becomes unmaintainable. Not to mention mini…
To go quite a bit off topic. The author says that he starts with a single html file and splits it or incrementally adds stuff when needed. That course of action has proven to be a really bad idea on every non trivial web project I worked on. Mostly for teamwork and maintainability reasons. E.g there is no clear project structure, the next dev will not understand stuff and do things differently. And welcome to the cha…
Thinking outside the node-vue-kitchen sink sort of development box is a good idea. Maybe you don't have a grand idea, maybe you just have a kinda neat idea. Punch that thing out fast and light. You can always grow it bigger, but maybe you don't need to.
Earlier quoted context omitted.
I think the criticism is exactly of that ability to scale though. This setup is ineffective but manageable at the individual scale, but it's going to get more complicated as soon as anyone else is involved, or if the project lives longer than six months and needs to be updated, or if you wanted to add any dependency more complicated than a single file. The other side of it is it's not really clear what the author is…
My objection is that the author is quite clearly describing this as a bottom-up, small scale approach. Criticizing it as an inadequate approach for something much larger is unwarranted, as nowhere was the claim made that this scales up infinitely. What is gained? No build step, as the article also clearly mentions. Your alternative approach goes against the goal of the author. Which is to not have a tool chain. "You…
In my opinion that boat sailed the moment he implemented `download-package`.
Sigh... Another post like this. Sure, it works well enough for the example shown in the article, but won't work well beyond this. Bundlers, package managers and other tools were created to address problems people saw in medium-large projects for websites with a lot of traffic. And as soon as the project has dozens of files and even just two or three external libraries, this becomes unmaintainable. Not to mention mini…
Earlier quoted context omitted.
You are optimizing for entirely different use cases. There are a whole bunch of devs who work alone or in (very) small teams. For this type of work it’s really more of a hindrance to have an imposed structure and tooling. We want to get to your goals as efficiently as possible. Minimal abstractions, guidelines, tooling, indirection, magic, surprises and general overhead are in order. We don’t want to struggle with qu…
Imo being "smart" like this is reinventing the wheel and doesn't give you any productivity gains.
Earlier quoted context omitted.
Imo being "smart" like this is reinventing the wheel and doesn't give you any productivity gains.
It's not reinventing anything. It's just avoiding complexity until necessary.
Second, anyone reading the repo is now expected to understand not 1 but 2 languages.
Finally, the shell script performs basic tasks that npm does out of the box.
Because of above reasons I think this solution is needlessly complex.
Earlier quoted context omitted.
The last couple days there's been a lot of negativity towards the build step, but it's like everyone's forgotten the historical context that made the build step so popular to begin with. I'll give credit to the post about the fragility of certain build tools long-term in the npm ecosystem, but I don't think that's a reason to shrug off build tools period. We just need better, more stable ones (and I think we're start…
The historical context is web development became popular and developers from other disciplines moved over and brought their practices from those other areas of programming with them. We compile apps for the desktop, we should compile apps for the web too. They brought their complexity with them and forced it onto web development instead of stopping to consider if that was a good idea. Now we have developers who never…
Sure, I would agree that the current JS ecosystem has its issues, but work can happen at either compile/design time, or at run time. Shifting work from one step to another has trade-offs that may or may not matter for a given team or product.
For small hobby projects? The scale makes these problems pretty insignificant, so handling more at runtime ain't so bad. But the number of possible problems multiplies as your codebase increases in size, and by solving these problems sooner, you spend less time overall dealing with them.
Sigh... Another post like this. Sure, it works well enough for the example shown in the article, but won't work well beyond this. Bundlers, package managers and other tools were created to address problems people saw in medium-large projects for websites with a lot of traffic. And as soon as the project has dozens of files and even just two or three external libraries, this becomes unmaintainable. Not to mention mini…
I’ve been doing web development for more nearly 25 years. It isn’t unmaintainable. How do you think we built large websites in the days before compiling/transpiling was a thing?
You don't really compare web development 25 years ago and now, do you? Then the most complex front-end was having two forms. Also people wrote operating systems in ed but don't think one will even consider giving up their IDE/editor for ed because people could build complex software in past with that.