Our great sponsors
-
-
htm
Hyperscript Tagged Markup: JSX alternative using standard tagged templates, with compiler support.
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
importmap-rails
Use ESM with importmap to manage modern JavaScript in Rails without transpiling or bundling.
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
What you can do in a Vue SFC you can also do in a templated string, 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 more functionality is available available in [2] which uses the new AutoQueryGrid component to reduce the functionality down to 1 line.
The point of going with a traditional Multi Page App 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
> which seemed like a lot of generic jquery like magic binding glue
They're just simple few line helpers [1] that removes verbose boilerplate of needing to use `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/mas...
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
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/
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" but with 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...
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" but with 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...