As someone who doesn't use JS frequently but still has to build some things ocasionally with it, it's funny how "Simple Modern Javascript" is a completely different beast each year. 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. For example, in this post already I see quite a lot of things that completely break how things were done in other projects or other frameworks. All for what? I don't see any improvements that would make such a break worthy.
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.
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 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 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
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/
> 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.
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.
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”.
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.
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
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.
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.
> 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.
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.
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.
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.
> 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.
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.
`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.
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.
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".
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.
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.
[+] [-] gjulianm|3 years ago|reply
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.
[+] [-] jalapenos|3 years ago|reply
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.
[+] [-] flippinburgers|3 years ago|reply
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.
[+] [-] TheRealDunkirk|3 years ago|reply
[+] [-] remorses|3 years ago|reply
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
[+] [-] mwexler|3 years ago|reply
Ala https://en.m.wikipedia.org/wiki/Coffee_Talk_(Saturday_Night_...
[+] [-] eckza|3 years ago|reply
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/
[+] [-] 323|3 years ago|reply
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, ...)
[+] [-] selfmodruntime|3 years ago|reply
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.
[+] [-] rk06|3 years ago|reply
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.
[+] [-] j45|3 years ago|reply
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.
[+] [-] dawnerd|3 years ago|reply
[+] [-] gemstones|3 years ago|reply
[+] [-] duxup|3 years ago|reply
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”.
[+] [-] adhoc_slime|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] Offler|3 years ago|reply
[+] [-] morbicer|3 years ago|reply
[+] [-] selfmodruntime|3 years ago|reply
[+] [-] rk06|3 years ago|reply
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
[+] [-] chrisweekly|3 years ago|reply
const Edit = { template:/html/`<SlideOver @done="close" title="Edit Contact"> <form @submit.prevent="submit">
[+] [-] mythz|3 years ago|reply
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...
[+] [-] rektide|3 years ago|reply
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.
[+] [-] mouzogu|3 years ago|reply
- 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.
[+] [-] simonw|3 years ago|reply
[+] [-] layoric|3 years ago|reply
[+] [-] graderjs|3 years ago|reply
[+] [-] bern4444|3 years ago|reply
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...
[+] [-] rjha|3 years ago|reply
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.
[+] [-] nailer|3 years ago|reply
Regardless of what you think about the maintainability of tailwind, Tailwind is someone else’s postcss CSS processor classes.
[+] [-] elvin_d|3 years ago|reply
[+] [-] mythz|3 years ago|reply
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.
[+] [-] dalmo3|3 years ago|reply
[+] [-] e12e|3 years ago|reply
[+] [-] justinpombrio|3 years ago|reply
[+] [-] preya2k|3 years ago|reply
[+] [-] ocimbote|3 years ago|reply
Edit: importmaps is also in this entry, I found it straighter to the point: https://news.ycombinator.com/item?id=34829039
[+] [-] mythz|3 years ago|reply
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-...
[+] [-] CharlieDigital|3 years ago|reply
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.
[+] [-] toastal|3 years ago|reply
[+] [-] xigoi|3 years ago|reply
[+] [-] oleg_antonyan|3 years ago|reply
[+] [-] hungryforcodes|3 years ago|reply
The only truthful thing that can be said about the article is that it is "modern".
[+] [-] rjha|3 years ago|reply
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.
[+] [-] raydiatian|3 years ago|reply
[+] [-] dclowd9901|3 years ago|reply
[+] [-] jwmoz|3 years ago|reply
[+] [-] mrweasel|3 years ago|reply
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.