Our great sponsors
-
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/...
-
htm
Hyperscript Tagged Markup: JSX alternative using standard tagged templates, with compiler support.
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.
-
Klotho
AWS Cloud-aware infrastructure-from-code toolbox [NEW]. Build cloud backends with Infrastructure-from-Code (IfC), a revolutionary technique for generating and updating cloud infrastructure. Try IfC with AWS and Klotho now (Now open-source)
-
> 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...
-
importmap-rails
Use ESM with importmap to manage modern JavaScript in Rails without transpiling or bundling.
-
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.
-
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...
-
Appwrite
Appwrite - The Open Source Firebase alternative introduces iOS support . Appwrite is an open source backend server that helps you build native iOS applications much faster with realtime APIs for authentication, databases, files storage, cloud functions and much more!
-
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...
