5 ms·

> be careful what you install and read the source code to understand what it is doing. That’s the reason why I started to love pika.dev ‘s package search. Webp

> be careful what you install and read the source code to understand what it is doing. That’s the reason why I started to love pika.dev ‘s package search. Webpack still sucks and will ruin your day with hours of unnecessary configurations and fixes. On the other hand, when setting yourself a rule to use plain ESM only without any build system, coding has been a joy. The only thing that still sucks is UI frameworks, because all major frameworks still require a shitty babel workflow in one form or the other. Vue.js has an ESM module which is useless without babel (due to the .vue file format), and Angular/React are still in the lets-invent-our-own-language fatigue.

korla 6y ago
React has no invented language. You’re thinking about jsx which isn’t needed. It is recommended, however.
- cookiengineer 6y ago
  > It is used everywhere, however. Fixed that for you. React without jsx components is just as useless as Vue without .vue files. If you cannot use the ecosystem of a framework in practice, your framework isn’t a framework anymore.
  - dragonwriter 6y ago
    > React without jsx components is just as useless as Vue without .vue files. It's not useless at all. JSX in React is just an alternate syntax for React.createElement calls.
    - deleted 6y ago
      [deleted]
  - aaronjxz 6y ago
    Wrong, you can still use VueJS without the vue extension... https://dev.to/arswaw/create-a-lightweight-componentized-spa-without-node-569j https://dev.to/arswaw/create-a-lightweight-componentized-spa...
pugio 6y ago
Lately I've been developing with a JS workflow that's finally made me think "hey this is fun!" again: Chrome target, native ESM modules, VS Code with JSDoc annotations for types. All libraries (chosen preferentially from microjs.com) are copied into vendor/, and the front end is written in preact.js using htm [0] for native JS tagged html strings, leading to code like: import ImageView from "./image-view.js"; render({ trail_item, selector }, state) { /** @type {LinkItem} */ let link_item = trail_item; let title = this.render_title(trail_item); let favicon = this.render_favicon(trail_item); let img = html`<ImageView src=${favicon} />`; return html`${img}${title}`; } There's a VS Code extension which formats html`` strings as actual HTML, and the Typescript checker built in to VS Code gives me advanced types and autocomplete, all with a workflow that's as simple as "refresh page". Granted, not every project can afford to target just evergreen browsers, but for my use case it works perfectly and I finally feel like I have the perfect blend of old-style web dev (in terms of refresh cycle) with modern language features and typing. The overhead, both in page-weight and cognitive load, is as small as I can make it. EDIT: Modified my code sample to show how you can use Preact components in a JSX-like way. [0] https://preactjs.com/guide/v10/getting-started/#alternatives-to-jsx https://preactjs.com/guide/v10/getting-started/#alternatives...
- cousin_it 6y ago
  Yeah, the microjs approach is much nicer than the Node approach. I think the mistake of modern JS (and many other languages) is conflating source files with libraries. A better model is combining many source files into one library file, which provides one toplevel name when imported. A good example is how Three.js, which has a complex internal structure, gets distributed as one file and provides one toplevel name THREE. And of course there are many examples in C-land, where a large library can live behind a single header file. A project should only depend on a handful of those, and there should be few dependencies between them, so package management becomes easy enough to do by hand - just drop a file in your project's vendor/ directory. As a bonus, this fixes the problem of having many fine-grained imports. If done right, your project's source files might not need any import statements at all. Anything inside the project could be available without ceremony, as if it was all one big file, and external libraries live in a handful of big namespaces which are also available without ceremony.
rk06 6y ago
> The only thing that still sucks is UI frameworks, because all major frameworks still require a shitty babel workflow in one form or the other. Vue.js has an ESM module which is useless without babel (due to the .vue file format), and Angular/React are still in the lets-invent-our-own-language fatigue. The pain is real. Create-react-app will dump 250 MB+ of files in node_modules however, newer approaches are emerging and (hopefully) will be stable soon. few noteworthy ones are: 1. SnowPack[0] (in early access) 2. Vite[1] (from author of Vue.js) . It is in experimental phase. but is quie good. 3. Unnamed project by Author of Preact. [0] https://www.snowpack.dev/ https://www.snowpack.dev/ [1] https://github.com/vitejs/vite https://github.com/vitejs/vite [2] https://twitter.com/_developit/status/1264062182326710273 https://twitter.com/_developit/status/1264062182326710273
aaronjxz 6y ago
A lot of UI Frameworks need webpack, I had been looking at web components... You can build Vue applications without bundler... file is JS extension, you use const template =` <you html stuff here> `

korla 6y ago

React has no invented language. You’re thinking about jsx which isn’t needed. It is recommended, however.

cookiengineer 6y ago
> It is used everywhere, however. Fixed that for you. React without jsx components is just as useless as Vue without .vue files. If you cannot use the ecosystem of a framework in practice, your framework isn’t a framework anymore.
- dragonwriter 6y ago
  > React without jsx components is just as useless as Vue without .vue files. It's not useless at all. JSX in React is just an alternate syntax for React.createElement calls.
  - deleted 6y ago
    [deleted]
- aaronjxz 6y ago
  Wrong, you can still use VueJS without the vue extension... https://dev.to/arswaw/create-a-lightweight-componentized-spa-without-node-569j https://dev.to/arswaw/create-a-lightweight-componentized-spa...

pugio 6y ago

Lately I've been developing with a JS workflow that's finally made me think "hey this is fun!" again: Chrome target, native ESM modules, VS Code with JSDoc annotations for types. All libraries (chosen preferentially from microjs.com) are copied into vendor/, and the front end is written in preact.js using htm [0] for native JS tagged html strings, leading to code like: import ImageView from "./image-view.js"; render({ trail_item, selector }, state) { /** @type {LinkItem} */ let link_item = trail_item; let title = this.render_title(trail_item); let favicon = this.render_favicon(trail_item); let img = html`<ImageView src=${favicon} />`; return html`${img}${title}`; } There's a VS Code extension which formats html`` strings as actual HTML, and the Typescript checker built in to VS Code gives me advanced types and autocomplete, all with a workflow that's as simple as "refresh page". Granted, not every project can afford to target just evergreen browsers, but for my use case it works perfectly and I finally feel like I have the perfect blend of old-style web dev (in terms of refresh cycle) with modern language features and typing. The overhead, both in page-weight and cognitive load, is as small as I can make it. EDIT: Modified my code sample to show how you can use Preact components in a JSX-like way. [0] https://preactjs.com/guide/v10/getting-started/#alternatives-to-jsx https://preactjs.com/guide/v10/getting-started/#alternatives...

cousin_it 6y ago
Yeah, the microjs approach is much nicer than the Node approach. I think the mistake of modern JS (and many other languages) is conflating source files with libraries. A better model is combining many source files into one library file, which provides one toplevel name when imported. A good example is how Three.js, which has a complex internal structure, gets distributed as one file and provides one toplevel name THREE. And of course there are many examples in C-land, where a large library can live behind a single header file. A project should only depend on a handful of those, and there should be few dependencies between them, so package management becomes easy enough to do by hand - just drop a file in your project's vendor/ directory. As a bonus, this fixes the problem of having many fine-grained imports. If done right, your project's source files might not need any import statements at all. Anything inside the project could be available without ceremony, as if it was all one big file, and external libraries live in a handful of big namespaces which are also available without ceremony.

rk06 6y ago

> The only thing that still sucks is UI frameworks, because all major frameworks still require a shitty babel workflow in one form or the other. Vue.js has an ESM module which is useless without babel (due to the .vue file format), and Angular/React are still in the lets-invent-our-own-language fatigue. The pain is real. Create-react-app will dump 250 MB+ of files in node_modules however, newer approaches are emerging and (hopefully) will be stable soon. few noteworthy ones are: 1. SnowPack[0] (in early access) 2. Vite[1] (from author of Vue.js) . It is in experimental phase. but is quie good. 3. Unnamed project by Author of Preact. [0] https://www.snowpack.dev/ https://www.snowpack.dev/ [1] https://github.com/vitejs/vite https://github.com/vitejs/vite [2] https://twitter.com/_developit/status/1264062182326710273 https://twitter.com/_developit/status/1264062182326710273

aaronjxz 6y ago

A lot of UI Frameworks need webpack, I had been looking at web components... You can build Vue applications without bundler... file is JS extension, you use const template =` <you html stuff here> `