80 ms·

Simple Modern JavaScript Using JavaScript Modules and Import Maps

175 points by mythz 4y ago

hungryforcodes 4y ago
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".
rjha 4y ago
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.
simonw 4y ago
Import Maps are finally here for macOS/iOS Safari in the Safari 16.4 beta: https://developer.apple.com/documentation/safari-release-notes/safari-16_4-release-notes https://developer.apple.com/documentation/safari-release-not...
- layoric 4y ago
  Well spotted, the shim works now, so something that could be removed in the near future.
dclowd9901 4y ago
I’d like to see what the adoption rate is on all the features mentioned in this article.
- simultsop 4y ago
  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..
preya2k 4y ago
Please fix the website and disable the horrible horizontal scrolling on mobile devices due to the overflowing code sections.
elvin_d 4y ago
They are introducing a new framework but making statements like it changing the game. Probably for one that dislike JSX.
- mythz 4y ago
  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.
  - elvin_d 4y ago
    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.
  - dalmo3 4y ago
    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 https://docs.servicestack.net/why-servicestack
    - mythz 4y ago
      The website is actually a Live Demo of its new npm build-free project template and the post is documentation for the approach and features used by the Project Template. The page itself also serves as a working demonstration for the features it talks about.
dalmo3 4y ago
I don't trust someone that uses let where you should be using const.
- justinpombrio 4y ago
  `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.
  - MisterKent 4y ago
    Source? Their scoping rules should be exactly identical....
  - dalmo3 4y ago
    That's new to me. What's crazy about the scope of const?
    - justinpombrio 4y ago
      Wow, I just completely misremembered that. Sorry!
  - seniorsassycat 4y ago
    Let and const have the same scope, var is the one with weird rules
- e12e 4y ago
  I see many uses of const, and a few let's - which ones would you change to const?
  - hLineVsLineH 4y ago
    A better question would be: which ones would you not change to `const`?
chrisweekly 4y ago
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">
- rektide 4y ago
  > 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.
ocimbote 4y ago
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 https://news.ycombinator.com/item?id=34829039
- mythz 4y ago
  "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-bundling-or-transpiling-a20f2755 https://world.hey.com/dhh/modern-web-apps-without-javascript... [2] https://world.hey.com/dhh/hey-is-running-its-javascript-off-import-maps-2abcf203 https://world.hey.com/dhh/hey-is-running-its-javascript-off-...
  - galaxyLogic 4y ago
    Do import maps combine all scripts into a single download? I thought that was the main benefit of "bundling" multiple modules together.
    - mythz 4y ago
      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/script/type/importmap https://developer.mozilla.org/en-US/docs/Web/HTML/Element/sc...
      - 4y ago
raydiatian 4y ago
Do it at scale
nailer 4y ago
> 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.
oleg_antonyan 4y ago
importmaps supported in Rails 7 https://github.com/rails/importmap-rails https://github.com/rails/importmap-rails
gjulianm 4y ago
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.
- Offler 4y ago
  A React project wouldn't have the same issues.
- flippinburgers 4y ago
  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.
  - madeofpalk 4y ago
    > 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 https://idb-perf-repro.netlify.app
morbicer 4y ago
<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()"> v-on:keyup.enter.stop incantation followed by some string referring to code? Thanks but I will stick to my "complex" typed React
- selfmodruntime 4y ago
  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="..." onChange={event => setText(event.target.value) onKeyUp={keyEvent => keyEvent.key === "Enter" && addTodo(text)}} /> Or even better, svelte's version <script> let text = ''; function onEnter(key){ if(e.keyCode === 13) addTodo(text) } </script> <input id="text" placeholder="..." bind:value={text} on:keydown={onEnter} >
  - duxup 4y ago
    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.
  - mythz 4y ago
    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.
    - selfmodruntime 4y ago
      > 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.
      - 4y ago
5350-uiop-1130 4y ago
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.
- zztop44 4y ago
  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).
  - 5350-uiop-1130 4y ago
    > 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.
jwmoz 4y ago
Still can't get over how they put html inside js.
- mrweasel 4y ago
  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.
  - jwmoz 4y ago
    For me it's more the bastardisation of the MVC pattern.
graderjs 4y ago
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.
CharlieDigital 4y ago
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.
toastal 4y ago
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.
- xigoi 4y ago
  You can always download the code from the CDN and self-host it.
  - mythz 4y ago
    Yep, also what the template does on install [1] [1] https://github.com/NetCoreTemplates/vue-mjs/blob/main/MyApp/postinstall.js https://github.com/NetCoreTemplates/vue-mjs/blob/main/MyApp/...
    - toastal 4y ago
      Well that's a relief
bern4444 4y ago
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-Enterprise-Edition/tree/master/src/com/example https://github.com/Hello-World-EE/Java-Hello-World-Enterpris...
- rjha 4y ago
  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.

175 points by mythz 4y ago

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".

rjha 4y ago

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.

simonw 4y ago

Import Maps are finally here for macOS/iOS Safari in the Safari 16.4 beta: https://developer.apple.com/documentation/safari-release-notes/safari-16_4-release-notes https://developer.apple.com/documentation/safari-release-not...

layoric 4y ago
Well spotted, the shim works now, so something that could be removed in the near future.

dclowd9901 4y ago

I’d like to see what the adoption rate is on all the features mentioned in this article.

simultsop 4y ago
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..

preya2k 4y ago

Please fix the website and disable the horrible horizontal scrolling on mobile devices due to the overflowing code sections.

elvin_d 4y ago

They are introducing a new framework but making statements like it changing the game. Probably for one that dislike JSX.

mythz 4y ago
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.
- elvin_d 4y ago
  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.
- dalmo3 4y ago
  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 https://docs.servicestack.net/why-servicestack
  - mythz 4y ago
    The website is actually a Live Demo of its new npm build-free project template and the post is documentation for the approach and features used by the Project Template. The page itself also serves as a working demonstration for the features it talks about.

dalmo3 4y ago

I don't trust someone that uses let where you should be using const.

justinpombrio 4y ago
`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.
- MisterKent 4y ago
  Source? Their scoping rules should be exactly identical....
- dalmo3 4y ago
  That's new to me. What's crazy about the scope of const?
  - justinpombrio 4y ago
    Wow, I just completely misremembered that. Sorry!
- seniorsassycat 4y ago
  Let and const have the same scope, var is the one with weird rules
e12e 4y ago
I see many uses of const, and a few let's - which ones would you change to const?
- hLineVsLineH 4y ago
  A better question would be: which ones would you not change to `const`?

chrisweekly 4y ago

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">

rektide 4y ago
> 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.

ocimbote 4y ago

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 https://news.ycombinator.com/item?id=34829039

mythz 4y ago
"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-bundling-or-transpiling-a20f2755 https://world.hey.com/dhh/modern-web-apps-without-javascript... [2] https://world.hey.com/dhh/hey-is-running-its-javascript-off-import-maps-2abcf203 https://world.hey.com/dhh/hey-is-running-its-javascript-off-...
- galaxyLogic 4y ago
  Do import maps combine all scripts into a single download? I thought that was the main benefit of "bundling" multiple modules together.
  - mythz 4y ago
    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/script/type/importmap https://developer.mozilla.org/en-US/docs/Web/HTML/Element/sc...
    - 4y ago

raydiatian 4y ago

Do it at scale

nailer 4y ago

> 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.

oleg_antonyan 4y ago

importmaps supported in Rails 7 https://github.com/rails/importmap-rails https://github.com/rails/importmap-rails

gjulianm 4y ago

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.

Offler 4y ago
A React project wouldn't have the same issues.
flippinburgers 4y ago
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.
- madeofpalk 4y ago
  > 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 https://idb-perf-repro.netlify.app

morbicer 4y ago

<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()"> v-on:keyup.enter.stop incantation followed by some string referring to code? Thanks but I will stick to my "complex" typed React

selfmodruntime 4y ago
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="..." onChange={event => setText(event.target.value) onKeyUp={keyEvent => keyEvent.key === "Enter" && addTodo(text)}} /> Or even better, svelte's version <script> let text = ''; function onEnter(key){ if(e.keyCode === 13) addTodo(text) } </script> <input id="text" placeholder="..." bind:value={text} on:keydown={onEnter} >
- duxup 4y ago
  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.
- mythz 4y ago
  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.
  - selfmodruntime 4y ago
    > 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.
    - 4y ago

5350-uiop-1130 4y ago

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.

zztop44 4y ago
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).
- 5350-uiop-1130 4y ago
  > 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.

jwmoz 4y ago

Still can't get over how they put html inside js.

mrweasel 4y ago
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.
- jwmoz 4y ago
  For me it's more the bastardisation of the MVC pattern.

graderjs 4y ago

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.

CharlieDigital 4y ago

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.

toastal 4y ago

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.

xigoi 4y ago
You can always download the code from the CDN and self-host it.
- mythz 4y ago
  Yep, also what the template does on install [1] [1] https://github.com/NetCoreTemplates/vue-mjs/blob/main/MyApp/postinstall.js https://github.com/NetCoreTemplates/vue-mjs/blob/main/MyApp/...
  - toastal 4y ago
    Well that's a relief

bern4444 4y ago

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-Enterprise-Edition/tree/master/src/com/example https://github.com/Hello-World-EE/Java-Hello-World-Enterpris...

rjha 4y ago
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.