8 ms·

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

• flippinburgers 4y ago
  Man I cannot wait for bundlers and all of that garbage to go the way of the dodo bird.
  • selfmodruntime 4y ago
    Man I cannot wait for compilers and linkers and all that garbage to go the way of the dodo bird.
    • chasd00 4y ago
      You don’t, and never did, need compilers and linkers for JavaScript. There’s even “script” right in the name.
      • selfmodruntime 4y ago
        Sure, you can run optimized JavaScript in your browser. At least you can smugly tell your users about your elitist belief when they mention that your scripts don't run on safari, because you've mistakenly used an API that was only available in Chrome and you didn't ship a polyfill, or if your code is larger than it has to be because it's not minified.
      • incrudible 4y ago
        Sure, you strictly do not need many things that make your site smaller and load faster.
• christophilus 4y ago
  I’ve been doing it professionally for 20 years, and I agree. Modern front end development with TypeScript, Vite, Preact, and even the much maligned npm are so much better than anything that preceded them for building complex front end applications. I like having a build step for code that I write. I build C, I build Go, I build C#. I don’t ship debug builds of those things. I don’t know why I’d want to forego all of the niceties that a modern TS build brings and also ship what is essentially a debug build of JS to the browser. Sure, for a really simple web page, I’ll just slap a script together. But for anything real, hell yes, give me a good build mechanism.
  • flippinburgers 4y ago
    Comparing building a golang project with "building" a frontend project is pretty laughable. Frontend "builds" are atrocious.
    • orra 4y ago
      Perhaps, but JS tooling is waaaay better than it used to be. Vite and Turbopack are way easier to use than Webpack, and faster than the next best thing, Parcel. npm supports lockfiles. Yarn goes further in that you no longer need a million files in node_modules; or pnpm uses hard links to prevent duplication. That said, typechecking Typescript is unfortunately slow. esbuild (as used by Vite) can strip out type signatures quickly, but can't check them. Rescript is very fast, but is a very different language than TypeScript or JavaScript, namely ML with braces.
    • whostolemyhat 4y ago
      What a silly thing to say.
  • ihatepython 4y ago
    I have never ever in my lifetime seen a front end application that was enjoyable to use.
    • whostolemyhat 4y ago
• inbx0 4y ago
  The author is pretty clear that their intention is to use this as a simple first step to creating an app without the hassles of bundlers, they don't seem to be advocating that one would create "medium-large" projects like this. The word "incremental" is mentioned in the first sentence. Nor does their message come across as "why don't people do this" to me. > Until recently though, I wasn’t sure how to make this step feel incremental. Seems like they genuinely just found a neat way to do a thing and wanted to share it.
  • programmarchy 4y ago
    It’s cool to see what modern browsers can do natively now. Using babel/webpack probably obscures that for most developers.
• ducharmdev 4y ago
  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 starting to finally get there).
  • rimliu 4y ago
    Cargo-culting is responsible for the most popular things in development. Not the actual benefits.
  • hartator 4y ago
    > but it's like everyone's forgotten the historical context that made the build step so popular to begin with. Maybe the reasons are not as strong as it seems?
  • irrational 4y ago
    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 knew how things were before transpilers were created and now think that this is how it has to be and that this is the best way.
    • noahtallen 4y ago
      > We compile apps for the desktop, we should compile apps for the web too. I don't think this is true at all. The key reason you see build steps are to solve problems that you don't even have to worry about in desktop apps. If you have an app on the web, its bundle size needs to be small so that it downloads over the internet in a few hundred ms or so. So you get a minification step. You want a good type system, you end up with a build step. You want broad compatibility with older browsers? You end up with polyfills. Need to do some asset processing? You end up with some scripts that have to run at build time. Build steps aren't some arbitrary complexity people make them out to be. They solve performance and compatibility issues, which impact real users in the real world. Running full-blown desktop apps over HTTP comes with a different set of problems compared to any local native app. Of course most of this isn't important for small side projects. But for many, side projects are a way to learn about different technologies they might end up using for larger projects or in a professional context.
• selfmodruntime 4y ago
  But can't you see? Overengineered blog / todo list clearly shows that JavaScript frameworks are totally useless and we should all be using jQuery instead. My own custom framework is totally up to the task and we shouldn't be trusting <big corp> as the maintainer of common frameworks. The browser is a bad tool anyway and we should all go back to using text only web pages.
• danwee 4y ago
  > People think they are smart and come up with ideas nobody thought of before. "This seems so simple, why don't people use this?" So, in your opinion how do things improve then? People see how painful some tools are and so they try to improve things. Some times it works, some times it doesn't.
• jmull 4y ago
  > People think they are smart and come up with ideas nobody thought of before. I think you're projecting your thoughts about some other thing on to this article... this one is a "this is how I like to do things and I found a new thing that helps do it that way" post. The tone of the article is really not like what you're suggesting.
• fleddr 4y ago
  "Sure, it works well enough for the example shown in the article, but won't work well beyond this." Sigh...the entire bloody point of the author is to use this for light projects, to scale the sophistication of the setup gracefully. With very obvious benefits: easy to understand, not linked to any setup so it works forever, interoperable and transferable. Typescript isn't universally important for development. It has its advantages for large projects with many developers but it's in no way essential. Most web projects don't use Typescript and the very idea that it's a must-have only a few years old and quite opinionated. Likewise, Babel isn't important either. You don't need to use some futuristic JS feature on your simple project, you can just stick to well supported ones, thus not needing Babel. "I have been doing web development as a hobby and professionally for well over a decade and have seen too much of this." I've been doing web development since 1996, so that makes for 27 years, should such obnoxious statement make anyone's opinion more important. If you need to piss on the idea of somebody scaling a web architecture proportionally to actual needs, you should reconsider who is the "smart" one.
  • klysm 4y ago
    Why scale “gracefully” though? The boilerplate of bundlers and package managers isn’t difficult or time consuming in practice. Sure it’s a lot of code and bloat but it isn’t actually hard.
  • kitsunesoba 4y ago
    > Likewise, Babel isn't important either. You don't need to use some futuristic JS feature on your simple project, you can just stick to well supported ones, thus not needing Babel. I would say even many moderately complex sites/apps have no need for [shiny new feature X]. These days new JS features tend more towards nice-to-have than they do essential. Back in the days when jQuery was ubiquitous it was a different story but things have improved quite a bit.
    • fleddr 4y ago
      Agree, Babel is bullshit in most cases these days. It's for people wanting to use some syntactic sugar that they just learned about 3 days ago.
• cnity 4y ago
  "I like cars, they serve my use case exactly". "Sigh, another car user. What are you going to do when you need to transport 50 humans at the same time?"
• irrational 4y ago
  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?
  • forgotpwd16 4y ago
    >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.
    • abraxas 4y ago
      > Then the most complex front-end was having two forms You have no clue what you're talking about. In the late nineties we had just about every bell and whistle working that I see in websites today, hardware limitations permitting. Some of it did not work well because client browsers were slow but it was all there: full interactivity through Java applets, VRML, media control API etc. Websites in the nineties were not two forms and a table tag. My masters project was embedding a voice recognition engine for interactive web search. Yeah we didn't do SPAs and instead implemented interactivity locally. That was a good thing that you threw in the garbage for a fad.
      • MrJohz 4y ago
        It seems odd to bring in Java applets and similar technologies to the discussion when the original point was that web development shouldn't need a build step. And isn't the whole point of SPAs to implement local interactivity? I.e. treat the client as a separate application (just like you would with an applet) and move session logic out of the server? If anything, I think it's remarkable how far we've graduated from that point: many features components and features that we used to have to build by hand are now directly implemented in the browser; Javascript is significantly easier and nicer to use, even without having to apply a build step (even just splitting scripts into separate modules is now supported natively!); and features that previously required potentially insecure plugins to be enabled are now controlled by the browser, giving users much more ability to control what their browser is doing or not doing. Even if you do want more complex development with build steps, with tools like Parcel and Vite, that's usually pretty simple at this point (certainly simpler than the last few Java builds that I've seen). It seems like you're complaining that everything is worse now because it's possible to have stupid amounts of complexity these days, but it's also a lot easier to have no complexity at all.
• stronglikedan 4y ago
  Not everything must scale to stay relevant.
• nilslindemann 4y ago
  > People think they are smart