Simple Modern JavaScript Using JavaScript Modules and Import Maps(vue-mjs.web-templates.io)
vue-mjs.web-templates.io
Simple Modern JavaScript Using JavaScript Modules and Import Maps
https://vue-mjs.web-templates.io/blog/javascript
115 comments
Frontend JS frameworks have been a meme for a while now.
I think it's a combination of the front-end needing more boilerplate than back-end, and developers struggling with accounting. Maybe your cool new framework will save you 10% dev time, but you'll lose that 10% ten times over with the learning and error-bashing you and your teammates and future team members will have to go through.
My policy is that you can use pure JS where a framework is overkill (I'll also accept jQuery), and React otherwise. React has emerged as the winner, and trying other things isn't worth the cost if you're paying (which employee developers are not).
I recently built a small app using pure JS, just to remind myself how it used to be. It's definitely too verbose to avoid frustration. But HotNewFrameworkX vs React is never going to be big enough a benefit to be justified.
I think it's a combination of the front-end needing more boilerplate than back-end, and developers struggling with accounting. Maybe your cool new framework will save you 10% dev time, but you'll lose that 10% ten times over with the learning and error-bashing you and your teammates and future team members will have to go through.
My policy is that you can use pure JS where a framework is overkill (I'll also accept jQuery), and React otherwise. React has emerged as the winner, and trying other things isn't worth the cost if you're paying (which employee developers are not).
I recently built a small app using pure JS, just to remind myself how it used to be. It's definitely too verbose to avoid frustration. But HotNewFrameworkX vs React is never going to be big enough a benefit to be justified.
It's not the frameworks.
React and Vue for example have been super stable for almost 10 years, and they don't really need anything other than one or two packages to work. CDN + alternative syntax is enough to make React as boilerplate-free as jQuery. Add another package (htm) if you want the good syntax back.
The problem has always been the ancillary stuff: JSX, Vue SFCs, wanting to use "import from" in the browser, IE11 compatibility, testing, linting, converting CSS, removing typescript types.
For those things we need tools like Webpack, Babel, ESLint, etc. And those just aren't "as good" as React, Vue, or even Typescript. Some of them break compatibility constantly, need a lot of boilerplate, need pulling several packages to do the most basic things, are the source of frustration for a lot of people and the source of the overkill you mention.
IMHO think part of the issue is that a lot of those ancillary projects are optimizing for cases that aren't significant in practice.
React and Vue for example have been super stable for almost 10 years, and they don't really need anything other than one or two packages to work. CDN + alternative syntax is enough to make React as boilerplate-free as jQuery. Add another package (htm) if you want the good syntax back.
The problem has always been the ancillary stuff: JSX, Vue SFCs, wanting to use "import from" in the browser, IE11 compatibility, testing, linting, converting CSS, removing typescript types.
For those things we need tools like Webpack, Babel, ESLint, etc. And those just aren't "as good" as React, Vue, or even Typescript. Some of them break compatibility constantly, need a lot of boilerplate, need pulling several packages to do the most basic things, are the source of frustration for a lot of people and the source of the overkill you mention.
IMHO think part of the issue is that a lot of those ancillary projects are optimizing for cases that aren't significant in practice.
I'll just leave this here for the ones who have convinced themselves that react is the winner (whatever that means): https://andy-bell.co.uk/the-extremely-loud-minority/
The winner means I can easily hire people who can develop on it from the get go, I can sell it without resistance, it's effective enough, and the business is aligned with productive output rather than technical oneupmanship.
I feel like comparing Wordpress to React/Vue is strange. Do people build web apps using Wordpress these days? I know you can make Wordpress do more via extensions (site builder, e-commerce), but it seems weird creating something original with Wordpress to me, but I genuinely don't know what Wordpress is capable of these days. In the sense of what Wordpress was made for and the extensions available for it, it checks out to me that it would dominate the web landscape.
As far as not blindly following the advice of web advocates, I agree - they live on the bleeding edge. Unfortunately these are the people the new and impressionable devs come across on social media and hold their words like gospel because look how many followers they have and look at who they worked for, they must be right! Web tech moves fast, especially the shiny frontend stuff, and that generates discussion and leads people to believe that everything else is obsolete when in reality it's not.
As far as not blindly following the advice of web advocates, I agree - they live on the bleeding edge. Unfortunately these are the people the new and impressionable devs come across on social media and hold their words like gospel because look how many followers they have and look at who they worked for, they must be right! Web tech moves fast, especially the shiny frontend stuff, and that generates discussion and leads people to believe that everything else is obsolete when in reality it's not.
As someone whose been in this space for a while, there are always new frameworks, new ways of doing things, new libraries and tools, most of it is just noise. Sometimes a new tool comes out (like Vite) that is a seismic shift, but for the most part that new framework or state management library really isn't all that much better than what we currently have.
My best suggestion to those developing JS apps is to not get carried away with the noise, pick a solid framework (React, Vue, Svelte, etc), pick some solid libraries, stay away from the experimental stuff, and just run with the tools you've got. There will always be a new tool around the corner that claims to be better than the existing tool, forget about it and stick with what you got, then revisit that tool if you hear alot of noise around it.
My best suggestion to those developing JS apps is to not get carried away with the noise, pick a solid framework (React, Vue, Svelte, etc), pick some solid libraries, stay away from the experimental stuff, and just run with the tools you've got. There will always be a new tool around the corner that claims to be better than the existing tool, forget about it and stick with what you got, then revisit that tool if you hear alot of noise around it.
What’s special about Vite?
I used Webpack before Vite and always ended up with super complicated scripts for generating configurations.
With Vite everything just basically works out of the box with no or very little configuration. And it's pretty fast.
And it works with Rollup plugins, which are easy to write.
With Vite everything just basically works out of the box with no or very little configuration. And it's pretty fast.
And it works with Rollup plugins, which are easy to write.
I agree with you but it might be due to my own ignorance.
I've done react, vue, and old school jquery and miss the days when javascript was just something you had a script tag for in your website.
"Building" js projects and all of the other weird ... garbage ... that gets thrown in is just totally frustrating. The best I have been able to manage is to use esbuild + react + typescript in a very conservative fashion to keep things manageable for someone like my self: has a life and doesn't want that life to be consumed by yet-another-new-node-js-build-this-perpetually-differently-and-forever-and-with-much-pain system.
I've done react, vue, and old school jquery and miss the days when javascript was just something you had a script tag for in your website.
"Building" js projects and all of the other weird ... garbage ... that gets thrown in is just totally frustrating. The best I have been able to manage is to use esbuild + react + typescript in a very conservative fashion to keep things manageable for someone like my self: has a life and doesn't want that life to be consumed by yet-another-new-node-js-build-this-perpetually-differently-and-forever-and-with-much-pain system.
> miss the days when javascript was just something you had a script tag for in your website.
What's to stop you from doing this now?
In fact, in between all the fluff in the article, mentions of browser support for ES Modules makes this pretty straight forward. I used it recently for a small repro and i was surprised at how well it worked https://idb-perf-repro.netlify.app
What's to stop you from doing this now?
In fact, in between all the fluff in the article, mentions of browser support for ES Modules makes this pretty straight forward. I used it recently for a small repro and i was surprised at how well it worked https://idb-perf-repro.netlify.app
I must point out for the record that this problem isn't novel. Apologies for bringing up his name here, but JWZ labeled this phenomenon "CADT," the "cascade of attention-defecit teenagers" model of development, all the way back in 2003.
Probably because all tooling comes from open source developers that are simply not happy with the status quo and are trying to improve things doing what they can, see Webpack, Babel, Vite, pnpm
What we really need is an end to end echo-system with funding, adoption and vision. Deno and Bun are both getting in this direction
What we really need is an end to end echo-system with funding, adoption and vision. Deno and Bun are both getting in this direction
To paraphrase a trite and old SNL line: "Simple Modern JS from last year is neither simple nor modern. Discuss amongst yourselves"
Ala https://en.m.wikipedia.org/wiki/Coffee_Talk_(Saturday_Night_...
Ala https://en.m.wikipedia.org/wiki/Coffee_Talk_(Saturday_Night_...
Give Elm a shot.
We haven't had a breaking change to the current version since August 2018: https://github.com/elm/compiler/tags In fact, the single most frequent criticism of our community is, "Is Elm dead? It hasn't been updated in years". The truth of the matter is that it's not dead; it's just really stable.
Everything still works. You can use a bundler, like Vite or Parcel, but you don't really have to. You can use whatever Javascript library you like, through ports or web components, but again: you don't really have to, unless you need to do interop with another service (i.e., Google reCAPTCHA or Stripe) - and in that case, you're at their mercy regardless of whether you're building your application in Elm, or in something else.
Compared to the rest of the JS ecosystem, we have virtually zero dependencies on outside tools or infra, other than Github; but if Github "goes away", I'd be willing to bet that the rest of the Javascript ecosystem would be in a lot of trouble, too.
We are a small but passionate developer community. Enough of us - myself included - do this full time for it to feel like it's a safe bet and that it's not going anywhere anytime soon. Join us. https://elmlang.slack.com/
We haven't had a breaking change to the current version since August 2018: https://github.com/elm/compiler/tags In fact, the single most frequent criticism of our community is, "Is Elm dead? It hasn't been updated in years". The truth of the matter is that it's not dead; it's just really stable.
Everything still works. You can use a bundler, like Vite or Parcel, but you don't really have to. You can use whatever Javascript library you like, through ports or web components, but again: you don't really have to, unless you need to do interop with another service (i.e., Google reCAPTCHA or Stripe) - and in that case, you're at their mercy regardless of whether you're building your application in Elm, or in something else.
Compared to the rest of the JS ecosystem, we have virtually zero dependencies on outside tools or infra, other than Github; but if Github "goes away", I'd be willing to bet that the rest of the Javascript ecosystem would be in a lot of trouble, too.
We are a small but passionate developer community. Enough of us - myself included - do this full time for it to feel like it's a safe bet and that it's not going anywhere anytime soon. Join us. https://elmlang.slack.com/
Elm looks quite interesting, I may have to try it out. But I feel that for many JS/TS devs, it may be too much of a jump to move to a functional language.
> it's not dead; it's just really stable.
Am I the only one who thinks this idea is somewhat contradicted by the TODOs that are still in the official docs, and seem to have been for years?
Am I the only one who thinks this idea is somewhat contradicted by the TODOs that are still in the official docs, and seem to have been for years?
> I have not seen this pace in other languages/environments. For example, in Python
It happens in Python too. For example in ML, in 2015 everybody was using torch, then Keras, then TensorFlow, then PyTorch.
Pandas now being replaced by Polars.
If you look at MLOps, every 3 months there is a new hot library.
In other words, it happens in the active parts of the ecosystem (data-science), not in the old stable ones (standard library, reading files, ...)
It happens in Python too. For example in ML, in 2015 everybody was using torch, then Keras, then TensorFlow, then PyTorch.
Pandas now being replaced by Polars.
If you look at MLOps, every 3 months there is a new hot library.
In other words, it happens in the active parts of the ecosystem (data-science), not in the old stable ones (standard library, reading files, ...)
Just want to point out that polars is not a complete replacement for pandas and they will likely live side by side in the data ecosystem.
One of the main and original intentions of pandas is replacing highly dynamic and changing excel models for financial, econometric and physical systems. The rigid structure of polars syntax while great for stability and optimization is not practical for research/development iteration of these kinds of models.
It’s one thing that the “standard library for X” changes every few years. The problem is when upgrades within the same library are backward incompatible, or require changes in unrelated things (such as the build system), or when the library gets dropped completely from support.
> It happens in Python too.
Python ML maybe. That's a different community to Python in general. The only place where there's been churn in general Python is probably package management.
Python ML maybe. That's a different community to Python in general. The only place where there's been churn in general Python is probably package management.
10 years ago there was a new Python web framework every month. Now that space is pretty much stable (dead).
The fact that JavaScript front-end is going through so much churn just shows that it's not obvious yet what the proper design looks like.
Rust is going through the same thing now with GUI frameworks, every couple months a new approach appears. Because it's not obvious yet what's the proper design for a Rust GUI API.
The fact that JavaScript front-end is going through so much churn just shows that it's not obvious yet what the proper design looks like.
Rust is going through the same thing now with GUI frameworks, every couple months a new approach appears. Because it's not obvious yet what's the proper design for a Rust GUI API.
I wouldn't say it's stable or dead. Starlette and FastAPI are great async frameworks that seem to have replaced Tornado. Django is only recently getting some async support.
JS frontend seems to have been going through churn for over a decade now. It's a messy language, and because we've been forced to use it as the sole frontend language for a while people have been trying to figure out how best develop with it. Hopefully, with more language support in Wasm, JS will finally be replaced.
JS frontend seems to have been going through churn for over a decade now. It's a messy language, and because we've been forced to use it as the sole frontend language for a while people have been trying to figure out how best develop with it. Hopefully, with more language support in Wasm, JS will finally be replaced.
> 10 years ago there was a new Python web framework every month.
That doesn't fit my recollection. Only Django and Flask had much mindshare.
> Now that space is pretty much stable (dead).
Do you mean stable or dead?
That doesn't fit my recollection. Only Django and Flask had much mindshare.
> Now that space is pretty much stable (dead).
Do you mean stable or dead?
> Only Django and Flask had much mindshare.
That's the status today.
A few other major ones back then - Zope, Tornado, Bottle.py, Pylons, TurboGears, CherryPy, web.py, Werkzeug.
That's the status today.
A few other major ones back then - Zope, Tornado, Bottle.py, Pylons, TurboGears, CherryPy, web.py, Werkzeug.
Zope was an oddity and had already started to fade into the background 10 years ago. Bottle was eclipsed quickly by Flask. Werkzeug was more of a toolkit than a framework.
Is Tornado even a web framework?
There was some interest in the others you mention but I don't remember them ever being major contenders.
I guess my point was that it never felt like the javascript situation where there was genuine paralysis of choice on many fronts. You generally either went Django or Flask depending on your preference for "batteries included". All the other choices were pretty niche.
Javascript has stabilized a bit in the last few years but the number of choices needed to start a project are still much higher than anything I experienced in Python web dev.
Is Tornado even a web framework?
There was some interest in the others you mention but I don't remember them ever being major contenders.
I guess my point was that it never felt like the javascript situation where there was genuine paralysis of choice on many fronts. You generally either went Django or Flask depending on your preference for "batteries included". All the other choices were pretty niche.
Javascript has stabilized a bit in the last few years but the number of choices needed to start a project are still much higher than anything I experienced in Python web dev.
Django was the big one back then.
But it was not clear at all that Flask would be the other winner. There were a lot of articles discussing Flask vs Bottle vs web.py.
> like the javascript situation where there was genuine paralysis of choice on many fronts.
I think that's the perception from the outside. If you start a project, it's pretty clear what's the recommended stack of the day. Sure, next year might be different, but today it's React/Vite/Tailwind/...
But it was not clear at all that Flask would be the other winner. There were a lot of articles discussing Flask vs Bottle vs web.py.
> like the javascript situation where there was genuine paralysis of choice on many fronts.
I think that's the perception from the outside. If you start a project, it's pretty clear what's the recommended stack of the day. Sure, next year might be different, but today it's React/Vite/Tailwind/...
> Libraries, UI frameworks, build systems, preprocessing tools, the JS community seems to have a knack for rebuilding everything from the ground up with almost zero backward compatibility with a frequency I haven't seen anywhere
The modern web industry isn't that old yet. Give it time. We've been writing C++ since 1985.
React is 10 years old. Vue is 9 years old. Angular is 11 years old. The only "real" new kid on the block is Svelte, which is 7 years old now.
The web constantly strives towards simplicity. React was developed because AngularJS was this huge enterprise framework of global state. React includes immutability to make things simpler. Vue was developed because its developers saw React (then with classes) as too complicated. It's loved to this day even by the HN crowd for its simplicity. Svelte again was developed because their developers saw the possibility to make updating the DOM simpler. Again, the HN crowd and its users love it, because Svelte really is dead simple. It's been my drug of choice for 2 years now and I'm seeing unbelievable productivity among friends and colleagues which choose to use it.
The amount of libraries you see can be explained because of JS huge open source crowd, perhaps the largest among any language. There is no controlling entity, so people are free to write their own open source abstractions. We as an industry should see this as a good thing, because there are mountains of code now available for everyone, free of charge with MIT licensing. Startups can write applications that reach millions and generate billions, without worrying about QT licensing costs or paying for a Delphi compiler toolset. They need one codebase for an application that runs virtually the same on every device, mobile, tablet or desktop alike.
> Another example, I recently had to upgrade a Vue 2 application to Vue 3, because Vue 2 is going EOL this year. Well, apparently that means I also had to change the build system from Webpack to Vite
Again, Vite strives for simplicity. Vite is so simple that it took the industry by storm. Gone are the days of webpack 4 era configuration files that made you want to rip your hair out. Vite was written by Evan You, the man behind Vue, which could give you an indicator of the quality of the tool.
I hate working on our C++ / QT enterprise product, because each change takes ages for me to see and verify. If that product was a web app (which we are currently looking into), I could see changes instantly, with application state persisting through recompilations.
Grizzled seasoned developers have longed for a native application toolset that runs on every device for decades. Some just miss that web browsers do exactly that, with the added benefit of being a near perfect sandbox. Of course it's not perfect (yet?), but perfect is the enemy of good.
The modern web industry isn't that old yet. Give it time. We've been writing C++ since 1985.
React is 10 years old. Vue is 9 years old. Angular is 11 years old. The only "real" new kid on the block is Svelte, which is 7 years old now.
The web constantly strives towards simplicity. React was developed because AngularJS was this huge enterprise framework of global state. React includes immutability to make things simpler. Vue was developed because its developers saw React (then with classes) as too complicated. It's loved to this day even by the HN crowd for its simplicity. Svelte again was developed because their developers saw the possibility to make updating the DOM simpler. Again, the HN crowd and its users love it, because Svelte really is dead simple. It's been my drug of choice for 2 years now and I'm seeing unbelievable productivity among friends and colleagues which choose to use it.
The amount of libraries you see can be explained because of JS huge open source crowd, perhaps the largest among any language. There is no controlling entity, so people are free to write their own open source abstractions. We as an industry should see this as a good thing, because there are mountains of code now available for everyone, free of charge with MIT licensing. Startups can write applications that reach millions and generate billions, without worrying about QT licensing costs or paying for a Delphi compiler toolset. They need one codebase for an application that runs virtually the same on every device, mobile, tablet or desktop alike.
> Another example, I recently had to upgrade a Vue 2 application to Vue 3, because Vue 2 is going EOL this year. Well, apparently that means I also had to change the build system from Webpack to Vite
Again, Vite strives for simplicity. Vite is so simple that it took the industry by storm. Gone are the days of webpack 4 era configuration files that made you want to rip your hair out. Vite was written by Evan You, the man behind Vue, which could give you an indicator of the quality of the tool.
I hate working on our C++ / QT enterprise product, because each change takes ages for me to see and verify. If that product was a web app (which we are currently looking into), I could see changes instantly, with application state persisting through recompilations.
Grizzled seasoned developers have longed for a native application toolset that runs on every device for decades. Some just miss that web browsers do exactly that, with the added benefit of being a near perfect sandbox. Of course it's not perfect (yet?), but perfect is the enemy of good.
I won't try to guess the industry trajectory as a whole. But I can speak from personal experience. I've been on teams jump on the single page application bandwagon. React in particular.
It's been 5 years since initiating that investment. Reflecting on it I'm frankly amazed at the amount of technology that we don't need. The standard type of UI we build really hasn't changed but the time code and overall cost continues upward.
Looking back to 2018 we might have been collectively beguiled by the self-perpetuating marketing machine of single page application technology. We've decided unless there's a very clear and specific justification to write a thick client on a web page we're avoiding it going forward.
Tools such as HTMX are perfectly effective substitutes at far lower cost. At least for what we need
It's been 5 years since initiating that investment. Reflecting on it I'm frankly amazed at the amount of technology that we don't need. The standard type of UI we build really hasn't changed but the time code and overall cost continues upward.
Looking back to 2018 we might have been collectively beguiled by the self-perpetuating marketing machine of single page application technology. We've decided unless there's a very clear and specific justification to write a thick client on a web page we're avoiding it going forward.
Tools such as HTMX are perfectly effective substitutes at far lower cost. At least for what we need
Minor correction, Svelte dispenses with the Virtual DOM an algorithm for making DOM updates, not the Shadow DOM which is a completely separate browser construct for isolating subtrees in the DOM.
Thanks. I'm not an expert on Svelte internals, but I simplified my statement.
It sucks. But part of the reason is ecosystem shift.
commonjs to esm is a massive shift. esbuild in place of babel is a ground breaking achievement.
Vite, which leverages ESM and esbuild, is very different, and better than webpack.
The ecosystems which haven't changed, I. E. react and angular, are either in middle of transition or suffering from not doing it.
commonjs to esm is a massive shift. esbuild in place of babel is a ground breaking achievement.
Vite, which leverages ESM and esbuild, is very different, and better than webpack.
The ecosystems which haven't changed, I. E. react and angular, are either in middle of transition or suffering from not doing it.
So much of the effort of extending JavaScript via many frameworks and the constant updating feels brittle.
It makes having a relationship with a stable piece of code challenging to move on to the next big function.
Over time, maintaining anything too old or too new can drag momentum and progress.
Still it’s one of the most universal technologies. Some of the more recent simple frameworks like alpine.js, or lit as I rediscovered today on HN may have more merit than initially realized.
It makes having a relationship with a stable piece of code challenging to move on to the next big function.
Over time, maintaining anything too old or too new can drag momentum and progress.
Still it’s one of the most universal technologies. Some of the more recent simple frameworks like alpine.js, or lit as I rediscovered today on HN may have more merit than initially realized.
JS backends do the same thing too. Hapijs had a habit for a long time of making breaking changes often. Most recently for me was Strapi which took everything and threw it out the window with really no way to upgrade that didn't also involve re-writing a ton of code. It's exhausting. This is what makes me want to just stick with the old tried and true tools (like WordPress).
I love JS, but I agree with all of this. I will say that vite/parcel/etc. are genuinely simpler and worth the migration headaches. (They are also built in Go/Rust, which should probably cause some self-reflection in the Javascript community.)
I love the variety. But I understand how it can be head spinning.
IMO the important thing is to find what works for you. I’d be wary of every other article out there that offers their ideas of the best way of doing anything web.
Personally I wouldn’t consider the article’s solution “simple”.
IMO the important thing is to find what works for you. I’d be wary of every other article out there that offers their ideas of the best way of doing anything web.
Personally I wouldn’t consider the article’s solution “simple”.
It’s less about it being head spinning vs the need for it to be.
Creating beginners is important.
Having more attention to spend on the user than maintaining the brittleness that can be present is a real tax.
Creating beginners is important.
Having more attention to spend on the user than maintaining the brittleness that can be present is a real tax.
I did the vue2 - vue3 upgrade, while I see what you're saying and actually agree, I have no idea why you had change your build tool from webpack to Vite. I'm still on webpack, for better or worse.
Webpack wasn’t on the list of supported build systems when I made the upgrade, don’t know if it still isn’t there. I preferred to waste time making a supported build system work than wasting it making an unsupported one work.
[deleted]
[deleted]
A React project wouldn't have the same issues.
<text-input :status="store.error" id="text" label="" placeholder="What needs to be done?" v-model="store.newTodo" v-on:keyup.enter.stop="store.addTodo()">
I have never been able to grasp why the HN crowd prefers arcane template magicks to "just" javascript. How is that simpler than
<input
id="text"
placeholder="..."
=> setText(event.target.value)
=> keyEvent.key === "Enter" && addTodo(text)}}
/>
<script>
let text = '';
function onEnter(key){
if(e.keyCode === 13) addTodo(text)
}
</script>
<input
id="text"
placeholder="..."
bind:value={text}
on:keydown={onEnter}
>Except neither of these examples are "just" JavaScript and require a preprocessor to convert it to valid JavaScript that the browser can actually run.
Unlike Vue templated components which is just JavaScript that's executable as-is and only requires the Vue runtime library to run.
Unlike Vue templated components which is just JavaScript that's executable as-is and only requires the Vue runtime library to run.
Vue's version puts JavaScript-like expressions in the template though. This is what people like about JSX is that aside from from the JSX expression extension to JavaScript, everything else in it - binding and control flow - is actual JavaScript.
You can do better than both though by just using JS template literals, like Lit / lit-html does. Here you have only valid JS syntax, JS for the expressions, and no compiler:
You can do better than both though by just using JS template literals, like Lit / lit-html does. Here you have only valid JS syntax, JS for the expressions, and no compiler:
html`<input
id="text"
placeholder="..."
@change=${event => setText(event.target.value) }
@keyup=${keyEvent => keyEvent.key === "Enter" && addTodo(text)}}
>`
> Except neither of these examples are "just" JavaScript and require a preprocessor to convert it to valid JavaScript that the browser can actually run.
That is true. But the syntax is much closer to native JavaScript.
That is true. But the syntax is much closer to native JavaScript.
IMO it's a weird claim to make that invalid JavaScript is much closer to native JavaScript than actual valid JavaScript.
They're just stylistic preferences, both have valid JavaScript expressions inside their component event handlers, the difference is syntactical, React went with JSX whilst Vue/Angular/Alpine.js/Aurelia adopted a HTML (valid) centric syntax.
They're just stylistic preferences, both have valid JavaScript expressions inside their component event handlers, the difference is syntactical, React went with JSX whilst Vue/Angular/Alpine.js/Aurelia adopted a HTML (valid) centric syntax.
I don't think so. Vue places almost it's entire rendering logic into HTML strings. To me this is worse than something that appears to be JavaScript, acts like JavaScript and has the same syntax as JavaScript.
> I don't think so. Vue places almost it's entire rendering logic into HTML strings.
I don't know what this is supposed to mean. The logic in Vue 3 components is maintained in its JavaScript setup function. The template syntax is just HTML based template syntax that can be parsed natively by browser's HTML parsers for binding component functionality to the DOM. Behind the scenes it compiles down to JavaScript functions like React does, where in addition to its template syntax Vue also supports Render Functions [1] and JSX/TSX [2].
The template can be maintained in a string, in the HTML DOM or in a SFC. Templates in a string or DOM don't need a preprocessor whereas Vue SFC's does as compiles down into more optimal JavaScript functions than React's and its template syntax is non-existent at runtime as it never makes it to its compiled .js builds.
Both Vue and React use their view functions to construct a Virtual DOM that they use to calculate which DOM modifications need to be made, i.e. they both serve the same function and their differences is largely cosmetic, effectively just a stylistic preference.
[1] https://vuejs.org/guide/extras/render-function.html
[2] https://vuejs.org/guide/extras/render-function.html#jsx-tsx
I don't know what this is supposed to mean. The logic in Vue 3 components is maintained in its JavaScript setup function. The template syntax is just HTML based template syntax that can be parsed natively by browser's HTML parsers for binding component functionality to the DOM. Behind the scenes it compiles down to JavaScript functions like React does, where in addition to its template syntax Vue also supports Render Functions [1] and JSX/TSX [2].
The template can be maintained in a string, in the HTML DOM or in a SFC. Templates in a string or DOM don't need a preprocessor whereas Vue SFC's does as compiles down into more optimal JavaScript functions than React's and its template syntax is non-existent at runtime as it never makes it to its compiled .js builds.
Both Vue and React use their view functions to construct a Virtual DOM that they use to calculate which DOM modifications need to be made, i.e. they both serve the same function and their differences is largely cosmetic, effectively just a stylistic preference.
[1] https://vuejs.org/guide/extras/render-function.html
[2] https://vuejs.org/guide/extras/render-function.html#jsx-tsx
Eh, sure, if you only have one page and that's all you do on that page. Real world web applications are much more complicated with all sorts of states and nested components, and you would want encapsulation and a very good separation of the functionalities. But the blog article can only show you a simple example to illustrate the idea.
IMO the problem is examples have to be simple to understand, but if you’re using React right the context of the application is much larger / not the only consideration.
Perhaps, you should look into alternative approaches. Because they are also ugly.atleast this one is shorter and is more convinient.
You can always chose Not to use them. "v-on:keyup" also works but you need to move logic for checking enter and stopping event propagation to event handler
You can always chose Not to use them. "v-on:keyup" also works but you need to move logic for checking enter and stopping event propagation to event handler
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">
const Edit = { template:/html/`<SlideOver @done="close" title="Edit Contact"> <form @submit.prevent="submit">
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...
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.
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,
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/...
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
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.
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.
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
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.
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.
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...
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...
i had to update an anchor tag yesterday in html from a#foo to a#bar:
- the <a> was a react element (a dependency in 1 million diff places)
- href value was a prop coming from an API
- footnote (to which the anchor goes) was a handlebar template in different repo
- the ID of footnote required modifying a seperate JS util which handles numerical increments (also updating test, and PR comments)
- the <a>, href, and footnote are all joined and bundled together using variety of complex scripts
this is normally a 10 second task. but thanks to simple modern javascript it took me best part of a week and a lot of complexity fatigue & depressive thoughts.
- the <a> was a react element (a dependency in 1 million diff places)
- href value was a prop coming from an API
- footnote (to which the anchor goes) was a handlebar template in different repo
- the ID of footnote required modifying a seperate JS util which handles numerical increments (also updating test, and PR comments)
- the <a>, href, and footnote are all joined and bundled together using variety of complex scripts
this is normally a 10 second task. but thanks to simple modern javascript it took me best part of a week and a lot of complexity fatigue & depressive thoughts.
To be fair that sounds like an architecture issue and sounds like in reality the task was a lot more complex than a#foo -> a#bar.
If the href needed to come from the api and the ID needed to be incremented and unknowable ahead of time then there were always going to be complexities. But it’s not like React stops you from hardcoding href URIs (said as someone who generally avoids using React whenever I can).
If the href needed to come from the api and the ID needed to be incremented and unknowable ahead of time then there were always going to be complexities. But it’s not like React stops you from hardcoding href URIs (said as someone who generally avoids using React whenever I can).
> in reality the task was a lot more complex than a#foo -> a#bar.
it really wasn't. been doing this for 15 years. seen all the trends.
cargo-culting mentality. a lot of new-ish folks really really don't know any better. first instinct is to hit npm i.
the idea of static html is alien to many.
it really wasn't. been doing this for 15 years. seen all the trends.
cargo-culting mentality. a lot of new-ish folks really really don't know any better. first instinct is to hit npm i.
the idea of static html is alien to many.
Import Maps are finally here for macOS/iOS Safari in the Safari 16.4 beta: https://developer.apple.com/documentation/safari-release-not...
Well spotted, the shim works now, so something that could be removed in the near future.
This is sort of like "Let's make my pantaloons more puffy than yours." At some point it's like dandy pretensions, right? It's not really usefully changing anything, it's aesthetics only. The stage where aesthetics spins off on its own and becomes its own goal divorced of other uses, is the "sexual selection leading to peacock feathers" level of JS ridiculousness.
No other language or framework seems to get the same scrutiny as JavaScript.
The Enterprise Java solutions never seem to get as much discussion but we all recognize it also as being equally if not more so absurd[1]. This is true of every language and framework that gains mass adoption and use. Scala projects are crazy complex, the python 2 to python 3 migration was a mess, none of these are problems. They reflect the improvements in every metric to the underlying platforms and systems - end user experience, developer experience, reliability, testability etc.
JavaScript is in a phenomenal place today - we have come "full circle" in the same way that streaming has come "full circle" with cable - better tooling, new capabilities, improved experiences etc.
There's a lot of keeping up with the jones' - that's partly nice as its job security and partly nice as a reflection of engineers improving our own ecosystem.
[1] https://github.com/Hello-World-EE/Java-Hello-World-Enterpris...
The Enterprise Java solutions never seem to get as much discussion but we all recognize it also as being equally if not more so absurd[1]. This is true of every language and framework that gains mass adoption and use. Scala projects are crazy complex, the python 2 to python 3 migration was a mess, none of these are problems. They reflect the improvements in every metric to the underlying platforms and systems - end user experience, developer experience, reliability, testability etc.
JavaScript is in a phenomenal place today - we have come "full circle" in the same way that streaming has come "full circle" with cable - better tooling, new capabilities, improved experiences etc.
There's a lot of keeping up with the jones' - that's partly nice as its job security and partly nice as a reflection of engineers improving our own ecosystem.
[1] https://github.com/Hello-World-EE/Java-Hello-World-Enterpris...
This is an echo of Stroustrup argument that other nice languages have no user. Sure Java enterprise beans was whacky but saying it got no scrutiny is inaccurate. It got lot of scrutiny and criticism and that is why it moved into the direction of POJO from EJB madness. Things have become better in that land.
Javascript is not getting hate because it is now famous so people are jealous and are hurling non-sensical abuses. The problem many of us see is that Javascript is famous, a critical piece of tooling and Javascript evangelists are still working in the teenager I-will-just-type-it-again mode.
By now, things should have progressed to a stage where doing simple things was simple.
Javascript is not getting hate because it is now famous so people are jealous and are hurling non-sensical abuses. The problem many of us see is that Javascript is famous, a critical piece of tooling and Javascript evangelists are still working in the teenager I-will-just-type-it-again mode.
By now, things should have progressed to a stage where doing simple things was simple.
> Tailwind enables a responsive, utility-first CSS framework for creating maintainable CSS at scale without the need for any CSS preprocessors like Sass
Regardless of what you think about the maintainability of tailwind, Tailwind is someone else’s postcss CSS processor classes.
Regardless of what you think about the maintainability of tailwind, Tailwind is someone else’s postcss CSS processor classes.
They are introducing a new framework but making statements like it changing the game. Probably for one that dislike JSX.
What new game changing framework?
The post talks about how it’s using JavaScript Modules and Import Maps to avoid needing an npm build system, how it’s gone back to traditional MPA server rendered pages to avoid SPA client routing and heavy state, how that approach lets you use any JS library in each page without affecting deps or build sizes of other pages, which libraries are good for use without a build system, the productivity features of its client and Vue component library and techniques it uses to load components fast with embedded JSON and pages fast with htmx’s boost feature which is a popular pjax implementation that’s a common performance technique that websites like GitHub uses.
None of this is framework dependent and is achievable with any server html framework.
The post talks about how it’s using JavaScript Modules and Import Maps to avoid needing an npm build system, how it’s gone back to traditional MPA server rendered pages to avoid SPA client routing and heavy state, how that approach lets you use any JS library in each page without affecting deps or build sizes of other pages, which libraries are good for use without a build system, the productivity features of its client and Vue component library and techniques it uses to load components fast with embedded JSON and pages fast with htmx’s boost feature which is a popular pjax implementation that’s a common performance technique that websites like GitHub uses.
None of this is framework dependent and is achievable with any server html framework.
Vue 3 adopting modern features without npm build. You are correct that it's not framework dependent and this is the reason for my comment.
The post starting about the build process following by how awesome new Vue is. IMO it two different points and build process is not making Vue unique but the post indeed.
The post is nothing more than a clickbaity ad for ServiceStack.
> ServiceStack is a simple, fast, versatile and highly-productive full-featured Web and Web Services Framework
https://docs.servicestack.net/why-servicestack
> ServiceStack is a simple, fast, versatile and highly-productive full-featured Web and Web Services Framework
https://docs.servicestack.net/why-servicestack
I don't trust someone that uses let where you should be using const.
I see many uses of const, and a few let's - which ones would you change to const?
A better question would be: which ones would you not change to `const`?
`const` prevents surface-level mutation (though you can still modify the parts of the thing). `let` has sane scoping rules. Sadly neither has both: `let` is fully mutable and `const` has crazy scoping rules. So using `const` over `let` isn't a strict improvement.
Let and const have the same scope, var is the one with weird rules
That's new to me. What's crazy about the scope of const?
Wow, I just completely misremembered that. Sorry!
Source? Their scoping rules should be exactly identical....
Please fix the website and disable the horrible horizontal scrolling on mobile devices due to the overflowing code sections.
Skimming through the article, I don't get the value proposition. Is there a way to summarize it, please?
Edit: importmaps is also in this entry, I found it straighter to the point: https://news.ycombinator.com/item?id=34829039
Edit: importmaps is also in this entry, I found it straighter to the point: https://news.ycombinator.com/item?id=34829039
"An approach for building simpler JavaScript Multi Page Apps without an npm build system"
Effectively we can use modern browsers native support of JavaScript Modules and Import Maps to create modular JavaScript Apps without a bundler.
DHH has a good post of the benefits of this approach in "Modern web apps without JavaScript bundling or transpiling" [1]
Which HEY has been running off for more than a year [2].
[1] https://world.hey.com/dhh/modern-web-apps-without-javascript...
[2] https://world.hey.com/dhh/hey-is-running-its-javascript-off-...
Effectively we can use modern browsers native support of JavaScript Modules and Import Maps to create modular JavaScript Apps without a bundler.
DHH has a good post of the benefits of this approach in "Modern web apps without JavaScript bundling or transpiling" [1]
Which HEY has been running off for more than a year [2].
[1] https://world.hey.com/dhh/modern-web-apps-without-javascript...
[2] https://world.hey.com/dhh/hey-is-running-its-javascript-off-...
Do import maps combine all scripts into a single download?
I thought that was the main benefit of "bundling" multiple modules together.
I thought that was the main benefit of "bundling" multiple modules together.
No it's purpose is basically to define an alias for a JavaScript module so your source code can import by package name whilst the physical location of where it should import modules from is defined in an external importmap where it can be changed/maintained without needing to update source code that uses it. Docs for importmap is at [1].
Using JavaScript Modules means the browser can traverse the matrix of dependencies needed to efficiently download & execute just the modules it needs.
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/sc...
Using JavaScript Modules means the browser can traverse the matrix of dependencies needed to efficiently download & execute just the modules it needs.
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/sc...
Therefore import maps do not solve all problems, bundling "compiler" solve.
Even with HTTP/2 there is "some" overhead when loading lots of small files.
There is also no tree-shaking e.g only loading functions which are really used.
They have different trade-offs sure, where bundling typically creates large opaque blobs of JS used by the entire SPA resulting in large initial download & parsing/execution time which is why it's preferable to only download & execute code needed which is easy to achieve with cohesive modules.
The opposite of large JS bundles is a framework like Qwik [1] which achieves perfect PageSpeed scores by downloading the least JS possible, both initially and then at runtime by only downloading the JS needed per interaction, resulting in very small downloads over a lot more requests.
[1] https://qwik.builder.io
The opposite of large JS bundles is a framework like Qwik [1] which achieves perfect PageSpeed scores by downloading the least JS possible, both initially and then at runtime by only downloading the JS needed per interaction, resulting in very small downloads over a lot more requests.
[1] https://qwik.builder.io
If the browser is smart enough to discover all the files it needs to request over the http/2 connection upfront there’s no real difference between downloading one big file and 100 little ones.
Where you get into trouble is resources pulling in others with a dynamic import mechanism, which can start a slow cascade. There are various solutions, like preload tags, import maps, http/3 (which reduces stalling), and prebundled libraries or groups of libraries.
As for lack of tree-shaking, that’s not an issue for smaller web applications. The libraries will be prebuilt and so are slim already, and you have perfect control over what is added which means there’s less that needs discarding. Also, most web applications struggle with image footprint, not js or css footprint.
I think a medium to large SPA web app shouldn’t try this approach, but smaller web apps or ones that have a light client footprint may benefit from the simplicity of a no build frontend.
Where you get into trouble is resources pulling in others with a dynamic import mechanism, which can start a slow cascade. There are various solutions, like preload tags, import maps, http/3 (which reduces stalling), and prebundled libraries or groups of libraries.
As for lack of tree-shaking, that’s not an issue for smaller web applications. The libraries will be prebuilt and so are slim already, and you have perfect control over what is added which means there’s less that needs discarding. Also, most web applications struggle with image footprint, not js or css footprint.
I think a medium to large SPA web app shouldn’t try this approach, but smaller web apps or ones that have a light client footprint may benefit from the simplicity of a no build frontend.
> there’s no real difference between downloading one big file and 100 little ones.
Are you sure? Each separate download needs its own negotiation with the server. Each download needs its own request and response. So you would have 100 requests and 100 responses versus 1 request and 1 response.
It's the same difference as driving 100 cars vs. driving a train with 100 connected train-cars over a narrow bridge etc.
Are you sure? Each separate download needs its own negotiation with the server. Each download needs its own request and response. So you would have 100 requests and 100 responses versus 1 request and 1 response.
It's the same difference as driving 100 cars vs. driving a train with 100 connected train-cars over a narrow bridge etc.
HTTP 1.0 when every request/response pair was a separate TCP connection certainly was a huge deal for one big file versus 100 little ones.
HTTP 1.1 shifted the dynamic a bit, when properly configured.
HTTP 2+ shift the dynamic a lot. When everything is a single reusable shared connection it's a lot more "100 connected train-cars". At that point it's more a matter of request/response header overhead. (And even there HTTP 2+ have interesting mitigations such as Brotli compression and common header dictionaries.)
There's still some difference between one big file and 100 little ones in HTTP 2+, but things are much more complex and a lot of it does start to look like a "wash" (do whatever makes you happy to start, then performance test your specific scenarios once you've got a complete application).
HTTP 1.1 shifted the dynamic a bit, when properly configured.
HTTP 2+ shift the dynamic a lot. When everything is a single reusable shared connection it's a lot more "100 connected train-cars". At that point it's more a matter of request/response header overhead. (And even there HTTP 2+ have interesting mitigations such as Brotli compression and common header dictionaries.)
There's still some difference between one big file and 100 little ones in HTTP 2+, but things are much more complex and a lot of it does start to look like a "wash" (do whatever makes you happy to start, then performance test your specific scenarios once you've got a complete application).
> There is also no tree-shaking e.g only loading functions which are really used.
In most browser implementations ESM modules produce "proxy" objects that weak reference un-JITed code until used and will (eventually) garbage-collect portions of the module that aren't ever imported/used by other modules. This can be seen as a sort of "natural" tree-shaking at runtime.
In most browser implementations ESM modules produce "proxy" objects that weak reference un-JITed code until used and will (eventually) garbage-collect portions of the module that aren't ever imported/used by other modules. This can be seen as a sort of "natural" tree-shaking at runtime.
I dig it.
We need more thinking and efforts like this to bring frontend back to progressive principles.
Much of the innovation in the frontend space is now happening outside of the React ecosystem. (Astro, Qwik, Marko as other examples.)
This is all important work if we want to continue to regain our sanity with frontend.
We need more thinking and efforts like this to bring frontend back to progressive principles.
Much of the innovation in the frontend space is now happening outside of the React ecosystem. (Astro, Qwik, Marko as other examples.)
This is all important work if we want to continue to regain our sanity with frontend.
I'm not a fan of the use of CDNs here. Why should I be trusting a third-party for your JavaScript? What is that CDN doing with this data? Why are there no subresource integrity checks to verify the scripts aren't tampered with? At least with compiled output hosted first party I can have a little more trust in the code, but it'd also be reasonable to expect that the code is tree shaken is therefore consuming less bandwidth.
You can always download the code from the CDN and self-host it.
Yep, also what the template does on install [1]
[1] https://github.com/NetCoreTemplates/vue-mjs/blob/main/MyApp/...
[1] https://github.com/NetCoreTemplates/vue-mjs/blob/main/MyApp/...
Well that's a relief
importmaps supported in Rails 7 https://github.com/rails/importmap-rails
The title is quite deceptive. It's all dependent on Vue3 (not VanillaJS, which i was expecting), has many modules in fact which it is dependent on (so it's really NOT simple) and alot of it is actually in TypeScript.
The only truthful thing that can be said about the article is that it is "modern".
The only truthful thing that can be said about the article is that it is "modern".
if this is simple, then what exactly is complicated? To a guy new to programming, ref(1), ref(false), mount(x), import { $1} , from {@x} are all hard concepts to grasp. I can give pass to async and await for being baked in the language.
Today, Java considers the canonical Hello world example to be too complicated because of static main() and System.out.println() and introducing changes to make it easy to write first programs.
I do not know what kool-aid cool kids in Javascript front end world are drinking.
Today, Java considers the canonical Hello world example to be too complicated because of static main() and System.out.println() and introducing changes to make it easy to write first programs.
I do not know what kool-aid cool kids in Javascript front end world are drinking.
Do it at scale
I’d like to see what the adoption rate is on all the features mentioned in this article.
It should depend on learning curve. People find it hard to move out from comfort zone. You can also track Fresh from Deno, their counters and stuff..
Still can't get over how they put html inside js.
I feel the same way. When I first moved from just doing things purely in HTML one for prevailing mantras online was: css, javascript and html are three separate things, they do not mix. Your site should work if the css didn't load, it should work if javascript failed.
The basic premise was progressive enhancements, javascript augmented your html, but again, never mix.
Another argument was that your web designers couldn't be expected to know or understand javascript, they weren't necessarily programmers, so they should be able to just stay in html and css.
The basic premise was progressive enhancements, javascript augmented your html, but again, never mix.
Another argument was that your web designers couldn't be expected to know or understand javascript, they weren't necessarily programmers, so they should be able to just stay in html and css.
For me it's more the bastardisation of the MVC pattern.
Another example, I recently had to upgrade a Vue 2 application to Vue 3, because Vue 2 is going EOL this year. Well, apparently that means I also had to change the build system from Webpack to Vite, the test library also was a "recommended change", the state store library was different and wasn't backwards compatible, and half the vue plugins required an update or a replacement for a Vue 3 compatible alternative.
I have not seen this pace in other languages/environments. For example, in Python, there are different "build" systems (old setuptools, pip, poetry...) and yet they are all compatible. In C/C++ I still haven't heard of a framework that forces you to upgrade your build system when they push a new version.