Hacker News Reader

Comment by chrisweekly | Hacker News Reader

There's some good stuff in here, and I appreciate the principles, but in practical terms for real-world projects, this is a subjective and opinionated set of choices amounting to a niche approach. Tailwind isn't a panacea, and that Vue3 Form template string (excerpt below) is kind of gross -- reinforcing my perception that the attempted philosophical purity here is neglecting DX / ergonomics. When it comes to modern webdev embracing standards and leveraging web platform fundamentals, Remix.run (with TSX) makes a lot more sense to me.

const Edit = { template:/html/`<SlideOver @done="close" title="Edit Contact"> <form @submit.prevent="submit">

View on HN

The `/html/` annotation is just a type hint for VS Code plugin to enable intelli-sense in literal strings to improve the authoring UX although this isn't required for JetBrains IDEs like Rider which can infer without it, so I personally wouldn't need to add it.

Otherwise its contents is pure Vue 3 that's runnable without a preprocessor. You could also maintain the Vue component inside a HTML `<template>` [1] but that would force additional considerations due to DOM constraints like forcing usage of explicit end tags, kebab-case attributes & components, using expanded `v-on:` instead of '@' which is special char in Razor, etc.

Given it's just using Vue 3 syntax, I'm assuming the critique is more a stylistic preference for React & TSX over Vue.

[1] https://github.com/NetCoreTemplates/razor-tailwind/blob/main...

> this is a subjective and opinionated set of choices amounting to a niche approach.

at this point, anything not react and bundled is a niche approach. so it doesn't detract- to me- that this post comes off as trying to expand a view of options.

> Tailwind isn't a panacea, and that Vue3 Form template string (excerpt below) is kind of gross

what is a panacea? is your standard to only adopt systems which are a panacea? what qualifies for this bar? personally the template-string seems unoffensive & direct enough to me. it's a go at trying to meld html and programming together, and it seems basically fine. template strings are, in general, pretty great, and we should learn to use them, train ourselves to find them natural.

being able to type-hint with a comment seems like a great zero-cost way to get most of the benefit of much more heavy-weight compiled systems, without having to do any actual work to set-up & maintain build-tools and build-pipelines. it might not instantly have appeal, but to me, 6 little letters in the code are kind of not really a big deal, for how much ridiculous maintenance & pain it could alleviate.

> reinforcing my perception that the attempted philosophical purity here is neglecting DX / ergonomics.

this feels like browbeating. you don't really have any arguments anyone can contest before this; you've leveraged your opinion that this isn't to your liking, without saying why. now you're insulting & degrading the attempt on the grounds that it's too philosophical & pure, again without substantiating how or why. this doesn't feel like a fair conversation.

> When it comes to modern webdev embracing standards and leveraging web platform fundamentals, Remix.run (with TSX) makes a lot more sense to me

right uh huh. can we not make quite such a zero-sum game out of what right now you perceive as working for you, having never tried this other thing? can we make some permission for "i don't know"?

part of what i like about this article is that all the standards present in it are usable on the web platform itself. using tagged template strings, using es modules. using type hints removes the need for compilation. nothing here feels bad to me. it feels like a free alternative that does the same jobs as well, but which most people just aren't accustomed to.

personally, this article was doing pretty good for me in general. i stumbled pretty bad at the @servicestack/client section, which seemed like a lot of generic jquery like magic binding glue, that probably works fine & helps, but felt like a bit more wild-cat a direction of data-handling than i personally wanted to go in for.

> personally the template-string seems unoffensive & direct enough to me. it's a go at trying to meld html and programming together, and it seems basically fine

Then you've never built a large serious production JS frontend using something like Vue.

Saying that JS template strings are a sufficient replacement for SFC Vue files or JSX (or any popular templating system) sounds crazy to me. This would depend very heavily on IDE integrations [1] but even then it would be extremely messy and only add more complexity than removing transpliers gain.

Sure it's fine for small niche usecases but if it was a serious option it would have been pushed long ago. JS templates have been around for 7yrs now.

[1] getting the whole team to just use VSCode is a big ask or getting HTML+Vue formatting/syntax highlighting working across Vim/Webstorm/etc. Then there's losing Prettier + Elint for linting and autoformatting. There's so much tooling lost with template strings,

What you can do in a Vue SFC you can also do in a templated string component, if the component gets too big you can always break it down into smaller components as normal. Sure you can benefit from a smart IDE which understands templated strings, just as they improve the authoring UX for Vue SFC's.

The Vue component used for its working CRUD Example is at [1] which is the verbose version, a more capable example [2] with a lot more functionality is available at [2] which uses the new AutoQueryGrid component to reduce the functionality down to 1 line.

The point of adopting a traditional Multi Page App approach is that you don't need to build a large serious JS SPA frontend as the separate pages provides natural isolation where you only need to build isolated components for the functionality each page needs which is typically glue code that makes use of external libraries & components.

[1] https://github.com/NetCoreTemplates/vue-mjs/blob/main/MyApp/...

[2] https://vue-mjs.web-templates.io/bookings-auto

[3] https://github.com/NetCoreTemplates/vue-mjs/blob/main/MyApp/...

This seems like a case of caring way too much about something that's hardly very different. JSX versus tagged template strings can be incredibly similar to one another.

The examples in this article are using vanilla template strings to author raw html, but that only misses a couple of nicities JSX has. There are tagged template string libraries like htm[1] that do include some of the few nicities JSX has, but which are actually compatible with the official language.

[1] https://github.com/developit/htm

Define "compatible with the language".

Anything you shove into a string and then parse yourself is "compatible with the language". Doesn't make it better or significantly different from systems that do this step earlier.

Compatible with the language seems like a dead obvious concept to me: something you can do with the current TC39 EcmaScript language.

Anything you do with JSX isnt compatible with the language. So that makes it worse & significantly different.

Diving way into technics, tagged template strings, if called from a function, will have reference equality for the literals array. The optimizations might not be ahead of time, but the net is, even if the tagged template string is inline and single-phase (as opposed to moving your tagged template strings to the top level & having them "compile" & return a function to accept variables/children), there's still a lot of room for reusing the same "compiled"/parsed work.

> Compatible with the language seems like a dead obvious concept to me: something you can do with the current TC39 EcmaScript language.

Most JS frameworks are written in JS. You can run React, Svelte, Vue etc. directly from the browser without a build step.

> Anything you do with JSX isnt compatible with the language. So that makes it worse & significantly different.

So, this is an artificial and absolutely arbitrary line that only looks good because you chose it to be so.

Also, JS world is probably unique among all programming languages with such aversion towards anything even remotely resembling compilation. Which is ironic, given that transpilation (aka converting from non-existent and future syntaxes to existing one) is Javascript's bread and butter.

> The optimizations might not be ahead of time, but the net is

> there's still a lot of room for reusing the same "compiled"/parsed work.

As opposed to what? To compilers/transpilers that can, and do, the same thing? And can do significantly more things like run whole-program optimisations. Or, like Solid, can just remove the need for components in the resulting code.

The world already agreed about 40-50 years ago that programming with strings is a bad idea. And now JS purists are willing to die on this hill (while inventing bizarre justifications and increasingly bizarre DSLs for anything remotely complex, see lit-html).

And of course there's nothing wrong, or "worse" with DSL, or compilation. As evidenced by compiled frameworks being blazingly fast: https://krausest.github.io/js-framework-benchmark/2023/table... and

> JS frameworks are written in JS. You can run React, Svelte, Vue etc. directly from the browser without a build step.

incredibly fantastically hugely incorrect. JSX is not supported in EcmaScript! Vue3 is not supported. the way we in fact do use these tools is not supported. i've said that so many times already & you keep making these absurd claims otherwise. it's just not so (not unless you take extreme & vast detours off the mainstream & hand author lower non-JSX react, which no one and few libraries do).

it's not in any way unclear that you've been wrong the whole time but you keep generating longer & longer posts & making more and more noise each time. but you've been in the wrong this whole time & it's just obvious & clear.

JSX is not supported in EcmaScript. again and again and again I keep having to say it. it requires tooling to reduce a superset of the language down; the browser's js engine is not capable of parsing code with jsx in it. this is intensely self-evident yet you protest & make a large hard to deal with confusing scene here.

again: jsx is not valid ecmascript!

> So, this is an artificial and absolutely arbitrary line that only looks good because you chose it to be so.

so now you seemingly maybe actually sideways-admit the truth, but you want to defend the other side... after having repeatedly made confusing claims there is no such line... please man, it hurts to get dragged through this. your whole first arguments seem dishonest & misrepresentative. and this second half admits the truth, but tries to smokescreen & cloak the basic obvious truth in painful new contorted ways.

i meam, really, omg, what? are you frakking kidding? this isnt "arbitrary". this is a quite clear line: things the language can do, and things that require outside tooling to do. jsx and vue3 (im unsure about vue2) require tooling, because as I have said multiple times already the language does not support them. as much as you protest, that's for sure how it is.

> As opposed to what? To compilers/transpilers that can, and do, the same thing?

fuggin exactly; holy heck, yes! a thing in the language as opposed to something that has to rewrite your code because the language cant do that thing (jsx, vue).

frelling heck dmitiriid, nearly everytime you show up in my replies it's full of huge long dissembling. you are telling lie after lie after lie, sowing absurd confusion & doubt over basic assertions, flooding the zone with shit. like this hummdinger of an overstated opinion-as-fact:

> The world already agreed about 40-50 years ago that programming with strings is a bad idea.

get off it man. this vastly overrepresents a particular chosen preferred view, & is nothing more than a malice-ful way to browbeat & condescend. if there's a tagged template string that works just as well as jsx, but actually works inside the language, you're ready to browbeat & bully it... because there's quotes around the content? i've already cited htm, which seems basically to prove this potential, but you're just gonma use nastiness & snark to degrade that potential, to disregard it out of hand? dimitiriid, this is how your replies to me keep going. i really really hate it. your words show intense favoritism towards what you want to believe time & time again & are just incredibly callous & short & browbeating against anything you dont want to think about. this dogmatism is intensely unpleasant to deal with; i'd really like to see a reformed & much more honest & engaged form of discussion when you reply to folks/myself, where other people are allowed to also have opinions, or I'd really appreciate you opting out of replies to me, to reduce these ultra long winded back & forths that feel so vastly unpleasant & infinitely useless. you never ever acknowledge that maybe perhaps other views are possible.

> And of course there's nothing wrong, or "worse" with DSL, or compilation.

they can have be worth it for some people, at some time. but.

i think there's room for people to express a desire not to deal with this shit. just authoring code & having the browser run it has attraction, has some merits. needing more work- external build processes- is in many ways clearly & obviously worse; we just shouldnt have to be taxed like that every single time we want to do anything. these are worse, in many (but not all) dimensions.

> frelling heck dmitiriid, nearly everytime you show up in my replies it's full of huge long dissembling.

Says the person who goes on a rambling rant with cussing, personal attacks, and little to no substance.

Every time you show in anyone's replies this really is all anyone can expect.

I believe you've already had multiple warnings on that from HN moderators.

So, at this point, adieu.

> which seemed like a lot of generic jquery like magic binding glue

They're just a few lines helper [1] to avoid needing to verbose boilerplate of `document.querySelector()` and `Element.addEventListener()` everywhere when wanting to use old-school jQuery dev model without a jQuery dependency.

I'd personally lean on a Reactive JS FX for anything remotely complex, but these helpers work well to demonstrate simple functionality without a JS FX.

[1] https://github.com/ServiceStack/servicestack-client/blob/d47...

Reply on news.ycombinator.com