TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Why Htmx Does Not Have a Build Step

178 点作者 crbelaus超过 1 年前

18 条评论

simonw超过 1 年前
I liked Julia Evans&#x27; take on this: <a href="https:&#x2F;&#x2F;jvns.ca&#x2F;blog&#x2F;2023&#x2F;02&#x2F;16&#x2F;writing-javascript-without-a-build-system&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;jvns.ca&#x2F;blog&#x2F;2023&#x2F;02&#x2F;16&#x2F;writing-javascript-without-a...</a><p>&quot;&quot;&quot; My goal is that if I have a site that I made 3 or 5 years ago, I’d like to be able to, in 20 minutes:<p>- get the source from github on a new computer<p>- make some changes<p>- put it on the internet &quot;&quot;&quot;<p>Front-end build scripts make sense for projects that are constantly developed by a team that is actively ready to incrementally fix any problems that come up.<p>For sites that only get maintained every year or so (and I have plenty of those myself) my experience is that they often cause more problems than they solve.<p>I also found that I started really enjoying JavaScript development again once I gave myself permission to ignore the npm&#x2F;webpack&#x2F;etc script world entirely and just write regular code that runs in browsers!
评论 #37265895 未加载
评论 #37265547 未加载
评论 #37271529 未加载
评论 #37267580 未加载
评论 #37265604 未加载
评论 #37273975 未加载
max_超过 1 年前
I was recommending htmx to some of my friends and they asked me &quot;What does it add?&quot;<p>I told them that it&#x27;s value proposition was not that it &quot;added&quot; anything but that it &quot;eliminated&quot; things, like build systems, configs, and the need to use js frameworks in incidences where it&#x27;s an overkill (which in my experience is majority of the cases)<p>HTMX is a good example&#x2F;manifestation of Nassim Taleb&#x27;s &quot;Via Negative&quot; heuristic i.e some systems can improved simply by the removal of components that are dangerous, ineffective or cause friction. As opposed to trying to improve systems by trying to add components that we think will make a system better. [0]<p>A lot of technology is focused on improvement by adding, but I think we should start thinking more in this paradigm of improvement by subtracting — subtraction complexity that makes systems more difficult to maintain &amp; build upon.<p>[0]: <a href="https:&#x2F;&#x2F;coffeeandjunk.com&#x2F;via-negativa&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;coffeeandjunk.com&#x2F;via-negativa&#x2F;</a>
评论 #37265837 未加载
评论 #37265628 未加载
评论 #37265658 未加载
semiquaver超过 1 年前
Crossing my fingers that the proposal for allowing (browser-ignored) type annotations in javascript progresses: <a href="https:&#x2F;&#x2F;tc39.es&#x2F;proposal-type-annotations&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;tc39.es&#x2F;proposal-type-annotations&#x2F;</a><p>Between that, HTTP2&#x2F;3 and ES modules many of the downsides for building apps with no compile step are almost completely mitigated.
评论 #37265521 未加载
评论 #37265509 未加载
NelsonMinar超过 1 年前
I love this, particularly its clear-eyed summary of some of the tradeoffs. Gonna be honest: build systems have completely robbed the joy from writing simple frontend hacks for me. I no longer use them, which means I just can&#x27;t use a whole lot of Javascript frameworks and libaries. Oh well.
meowtimemania超过 1 年前
I just threw away an admin site written with trpc+react and rewrote it with htmx. Deleting so much code felt glorious. Everything feels more simple and as a result adding features is so much easier.
spankalee超过 1 年前
Compilers should be optional, in a two senses of the word:<p>1. Even if you use a language like TypeScript in your library, your users shouldn&#x27;t have to. Provide types to them, even provide features like decorators, but have first-class and ergonomic ways for plain JS users to accomplish the same task.<p>2. Frameworks don&#x27;t need compilers. All the reasons those that do claim to have them: especially performance, ergonomics, are disproven as requirement by libraries that meet or exceed them on those axes. You especially don&#x27;t need to fork JS and HTML, and doing so fragments the web dev ecosystem, and causes tool friction, for very little gain. You can offer a compiler, but it should be an optional optimizer.<p>However, even as compilers should be optional, I also think they should be possible. If users want TypeScript to check their work, and especially if they&#x27;re in large teams and organizations where extra checks help collaboration, your approach shouldn&#x27;t prevent it.<p>And if you&#x27;re doing things in a language without traditionally good static analysis tools, like HTML, you should try to provide them, otherwise your approach really doesn&#x27;t scale due to ever-increasing fragility as your code base and team size grows.
can3p超过 1 年前
I think build systems are a very big reason for the mess javascript is in nowadays.<p>- Typescript is very light from the code transformation point of view. If anyone remembers the output of babel especially for async&#x2F;await + the way module imports are implemented generates a really hard to read code and the &quot;best practices&quot; about hiding the state make things a lot harder. Just think about the fact that back in the days (tm) it was common to inspect the state of the app and change it full lisp style and now the js console can mostly be used for quick code tests and looking around when execution is stopped at breakpoint and you can&#x27;t see that much anyway because of how the code is generated. - The whole babel thing still feels like a madness to me. Yeah, you&#x27;re getting some new language features but for the price of non obvious code transformation that makes you need source maps (and you need to make them work and maintain that) and all the rest - Build step + npm results in on controlled bloat of the js bundle. `npm install &lt;random-component&gt;` may inflate you bundle by 500kb easily - And with all that there is still a quite big trouble with requiring necessary modules for the use on frontend. Just think that there is still no simple way to require all css provided by a library from npm<p>Another big problem on my opinion is the propagation of &quot;write once&#x2F;use everywhere&quot; approach. It works sometimes yeah, but you need to sell your soul for that: you&#x27;ll have to use something like next.js and that implies that you&#x27;re bound to use node.js and then you either do all your development in node or have another service doing stuff in the language of your choice and then have a node service as a templating layer and then you need containers and orchestration and so on which makes it a technically challenging project for something that almost for sure can be done in some trivial set of technologies if this requirement had been dropped.<p>One could argue that we need a different approach with libraries that acknowledges that frontend is distinct world and aims to provide ready made components specifically for the web with an easy setup and no&#x2F;minimal dependencies. Maybe even with a vendor folder like approach, since the won&#x27;t be too much code anyway. That should be enough for 99.999% of projects and the rest can use the full scale approach and embrace complexity if they really need it.
mamcx超过 1 年前
Dependency hell IS hell.<p>I broke my dev machine because a bad application of reps + brew, and triying to reinstall all was a messy mess.<p>Now I doing things with nix, and is almost good, yet I can&#x27;t escape dependency hell completely...
bingemaker超过 1 年前
&gt; It’s certainly not true for Python, or Java, or C<p>As far as the C code that I&#x27;ve seen from the past (early 2000s), they do compile pretty fine even today. I doubt if &quot;C&quot; belongs there.
评论 #37265648 未加载
评论 #37266741 未加载
评论 #37265575 未加载
ikekkdcjkfke超过 1 年前
I remember going from just having to hit F5 to waiting for a &quot;hot&quot; reload, angular js -&gt; angular 2. Sad times
评论 #37265493 未加载
sebazzz超过 1 年前
&gt; Would code written in those TypeScript versions compile unmodified in today’s TypeScript compiler (version 5.1 at the time of writing)? Maybe, maybe not.<p>Definitely not. Typescript upgrades are nearly always breaking in some way. But the fun really starts when upgrading typings (type definitions), or when a library that used to have no typings starts including typings which are more often than not not compatible with the 3rd party typings causing a whole headache by itself.<p>I love the concept of Typescript but I’m glad I left it behind in favor of Blazor (laugh if you want). It allows me to focus on the customer problems in the limited time I have rather than fixing my build for the Nth time.<p>Also, lately the Typescript type system has become more complex and the typings itself have also grown more complex, with things like:<p><pre><code> export type SomeType = IPickOne&lt;SomeOtherType,SomeProperty&gt; | IPickExcept&lt;SomeOtherType2,SomeProperty2&gt;; </code></pre> Utterly insane and you need to pre-compile the types in your mind or rely on auto-complete to understand them.<p>I get idea that some parts of the front-end ecosystem are designed to be busy work, or at least usually turn out to be. But not all of us work in a SaaS development team that can affort 30% or 40% to just play with front-end build systems. Some of us work for clients instead, and need to make the best of the time we have. And more often than not, that means excluding risk factors like large parts of the NPM ecosystem. Limiting things to some simple gulp, dart-sass and some terser to “build” the front-end.
emadda超过 1 年前
I often use vanilla esbuild installed via NPM.<p>I feel like this build step would still work in 5 to 10 years:<p>- esbuild is compiled into a single binary for each target system so has minimal dependencies.<p>- NPM makes the version immutable, and will download the same binary version on ‘npm install’.<p>- I will use .tsx as my extension but use only pure JS, this gets me IDE suggestions without writing TS types, which works well for small projects.<p>Compared to webpack, esbuild seems unbreakable.
yellow_lead超过 1 年前
I tried to use htmx but the client side templates extension (allowing you to transform json into html client side using a template) doesn&#x27;t support json arrays.<p>Maybe I don&#x27;t understand the right way of doing things with htmx, but returning large amounts of html seemed like it&#x27;s a waste of bandwidth to me. That said, I appreciate htmx not having a build step. Even tailwind gets annoying to me.
评论 #37265481 未加载
评论 #37265469 未加载
评论 #37265785 未加载
评论 #37267348 未加载
评论 #37265581 未加载
pictur超过 1 年前
The answer is simple: it offers simple things as a simple library. I really liked the effort to explain this so long. You shouldn&#x27;t even be satisfied with that, my friend. I&#x27;m looking forward to the htmx nutshell book. you can write it.
jsmm超过 1 年前
Maybe, slightly off-topic. I recently started developing with htmx and go and it&#x27;s been really very productive for me as I am not a front end developer. But there are still some usecases, where I need to use JS, like a simple &#x27;hide and show password field&#x27;. I had to use htmx:on JavaScript to make it work. I am for no build as it keeps development and debugging simpler.
TheCapeGreek超过 1 年前
I like that the trend cycle is now moving towards simpler systems with good DX instead of yet another React competitor.
PaulHoule超过 1 年前
I&#x27;ve seen Typescript programs break between versions of Typescript more than I&#x27;ve seen happen in any other programming language.
评论 #37265408 未加载
评论 #37265233 未加载
评论 #37265355 未加载
评论 #37268124 未加载
评论 #37265302 未加载
评论 #37265317 未加载
ComputerGuru超过 1 年前
I agree with the main points in the post and certainly understand how they could push one in the direction that htmx has taken, but for me (and I posted a long comment along these lines as a reply in this thread elsewhere) the benefit of TypeScript isn&#x27;t just the type safety but also that it forces you to explicitly provide more strongly-structured, parseable context info (regarding your intent in the codebase) that can be used to further empower static analysis tools (whether it&#x27;s the TypeScript compiler or various linters à la eslint and co) to pick up on discrepancies between what the code is supposed to do and what the code does.<p>I view JS as a particularly unreliable language to build solid (as in dependable, consistent, coherent, and sound) projects in, and the various build tools are just ways to at least partially overcome those inherent shortcomings of the language. Transpiling from ESNext to ES5, merging disparate source components, etc are all just icing on the cake and not the real reason to use TypeScript (though I am surprised that the article talked about its ECMAScript version restrictions caused by IE11 support but <i>didn&#x27;t</i> talk about how w&#x2F; TypeScript you can use language-level (not library-level) features such as the spread operator, for ... of, async&#x2F;await, etc. and have them automatically converted&#x2F;transpiled to functional equivalents that work on ES5 browsers).<p>Just look at how the various @typescript-eslint&#x2F;* packages can supplant basic eslint rules, replacing them with more precise variants¹ by using the extra information provided by the TypeScript AST instead of just the info surfaced by the JavaScript AST.<p>¹ Let alone the existence of the hundreds of additional lints that are only possible for TypeScript codebases.
评论 #37269233 未加载
评论 #37267956 未加载