8 ms·

Can anyone point me to a workflow where the cognitive load is similar to how it was in the good old days? i.e. some thing that does everything for me apart fro

Can anyone point me to a workflow where the cognitive load is similar to how it was in the good old days? i.e. some thing that does everything for me apart from the bit where I write application and presentation code? That mostly just works and doesn't require me to understand the whole stack. Because when I switch to other languages/environments I can most remain blissfully unaware of the plumbing that keeps the thing running. I learned all I needed to learn about pip and virtualenv in under an hour. My C# editor just lets me edit code and hit play. Is there any chance of getting to this state of nirvana for web development?

Filligree 7y ago
Vanilla JS? For most purposes I find that all these frameworks are simply unnecessary. As a bonus, all the debugging tools in Chrome work much better when there's no obfuscation or packing, and "recompiling" is just Ctrl-R. Code size and load speed is also massively better than it would otherwise be. Pages load instantly. It's nirvana, I tell you.
- krapp 7y ago
  The funny thing is, all of these frameworks are designed for teams building professional sites at scale. They shouldn't be the standard for all javascript development. Not every javascript application needs NPM, a frontend framework and recompilation.
- gherkinnn 7y ago
  In my experience that results in the team building an inferior, untested, undocumented, and buggy version of React|Vue|jQuery|lodash. Now you need to train new peeps to handle that mess. And you haven’t even started solving actual problems. Provided you really need so much bulk at your disposal. But that’s a different story.
  - tl 7y ago
    My experiences with React / Vue / Angular: server side rendering plus a reasonable refresh interface (LiveView, PJAX, Turbolinks, etc...) wins until you reach the point where native code is a better solution anyway. JQuery / lodash: we’re slowly getting better about modern browser availability and needing these less, but it’s a long road.
    - gherkinnn 7y ago
      Despite working mainly with TS and React, I almost agree with the first part. There are all to many cases where a minimal setup works just fine. My hope is that such a restrained setup inherently suppresses stupid features nobody asked for. And yet here we are.
  - z3t4 7y ago
    Frameworks are managers pipe dream. Vanilla never gets old.
  - Filligree 7y ago
    Perhaps that's the case. I'm assuming small-scale/personal sites, where there's no team and one person does all the work.
wayneftw 7y ago
Create-react-app is what you’re looking for.
- archie2 7y ago
  But then you're forced to use React...and as soon as you need to do anything outside of what it provides it all falls apart which happens pretty quickly in my experience with it.
  - christophilus 7y ago
    I’ve been doing React for years and haven’t experienced this. What kinds of apps are you building?
    - omegabravo 7y ago
      - web components - runtime plugins React is great if you stay in the design constraints, which is to be expected. This covers the vast majority of web apps. edit: [removed svg snippets] I think I was confused with WebComponents not supporting svg elements that don't include the root tag
      - christophilus 7y ago
        The app I currently work on is 100% runtime plugin based. React has not been an issue there at all. I haven’t tried using web components, though, so can’t speak to that.
        omegabravo 7y ago
        it's not impossible, I have something working with react-registry. With Vue it would work out of the box since it comes with a registry out of the box.
    - gherkinnn 7y ago
      React Router used to be a mess. And should I use Redux? I thought it’s not cool anymore. If I do, do I store everything in a global state? Maybe I’ll use Context and Hooks. Or was it HoCs? And what about mobX? I heard it’s like Vue. I like Vue. And I absolutely need something to handle requests. Saga? Maybe some GraphQL? Now that I have my views, my state, and my data, how do I test this? Jest or something else? But why write tests if I have Types! How to configure TS? A few any never hurt anyone, did they? Too many questions. I’ll let Create React App answer this for me. Or is it Gatsby? Or even Nextjs? Oh, and is Lodash the new Underscore? And what is different about those and Ramda? We need more FP! But how do I structure my Code? Dan “Daddy” Abramov tells us to organise it any old way. But how? [0] Angular and to a lesser extent Vue give you more direction. This is of course not inevitable in a React project, but it does take good technical leadership not to be hindered by analysis paralysis before you even set off. 0 - An exaggerated summary of what I gather on various forum and discussions.
duhi88 7y ago
Deploying JS (or anything) over the web usually requires a lot of extra considerations. Devs want flexibility in their deployment options, which is why Webpack is so complex. Parcel is probably the closest to zero-config that I've seen. Only drawbacks are when you want to do something "off the rails". I'm guessing this project will be the same. Of course, if you're not worried about supporting IE11, you could waive any built step and be absolutely fine. Gzip is more important than minifying.
ccday 7y ago
Ember.js is very much batteries-included although learning the framework definitely requires a time investment.
- kerkeslager 7y ago
  Ember.js is the highest-cognitive-load framework I've ever used. Not only do you have to understand all the bundling of JS, but you have to understand Ember's naming conventions and project structure, which has a lot of corners and edge cases. The basic problem is that they give you a bunch of configuration points and if you don't know what configuration point to insert your code at, you're either going to be writing a terrible hack, or you're just plain unable to do what you need to do. There are similar issues with React, Angular, Django, etc., but Ember is the worst one I've ever used. It's been a while so maybe the situation has improved, but I'm simply not willing to go back to something that has burned me that badly.
  - cogman10 7y ago
    They burned me with the "rails" problem. Ember and RoR are two projects that have really turned me against overarching frameworks. Both have gone through periods of crazy backwards breaking and paradigm shifts that have left me burnt out.
    - kerkeslager 7y ago
      Agreed. I work in Django, and have a love-hate relationship with it. The main selling point is the Django ORM, which keeps me coming back, but even that is just the best of a lot of bad options. And a lot of Django patterns (class-based views, template tags, middleware, signals) are just obfuscating features that are handled much more simply with raw Python features. They let you write 80% of your behavior with 20% of the effort, but drastically impede your progress on the other 20%, and create debugging nightmares. Beware projects with impressive quickstart guides.
      - cogman10 7y ago
mumphster 7y ago
Parcel (https://parceljs.org/ https://parceljs.org/) fits this bill nicely and I use it for all my personal frontend development needs (node and browser targeted). You just add a script tag that points to a js/typescript/rust/(whatever else the author eventually adds) file and run parcel on said html file and you get hot reloading, decent error reporting, bundling, and asset loading via `import` without having to configure a single thing (other than npm installing sass and react and whatever other libraries you want to use))
- bauerd 7y ago
  Yep, tried this recently after being out of JS land for a while, and Parcel just worked. So +1
- tghw 7y ago
  It's also significantly faster the webpack, at least in my experience.
- jjeaff 7y ago
  This is what I was going to suggest. I am working on moving towards react and some other better practices for our current jQuery/spaghetti code front end and I needed to be able to handle multiple entrypoints and types. I messed around with webpack and create react app and gulp and several other things for days before coming across parcel. It just works. Want to build your react app? Just tell parcel where your index.js is and it will see your react and react dom imports and just build it. No config needed. Want to do react in typescript? Just change your entrypoints to index.ts. Done. Even handled the yarn add commands for you. This allowed me to easily have a few different react entrypoints as well as just a few random .ts files for use on pages that aren't built in react yet and then I just watch or build using a wildcard and it takes care of it all. So far, I'm a big fan.
turtlebits 7y ago
I really like svelte, there is a build/compile step, but it’s pretty much batteries included. I have not needed to touch any of the config files and it “just works”. I got turned off by React and Vue where you need to learn a build tool and write your own config.
- lastmjs 7y ago
  Zwitterion could add support for .svelte files rather easily
kabes 7y ago
Meteor comes pretty close being a zero-config build tool and free choice of frontend framework. But you do need to understand the framework
solarkraft 7y ago
> My C# editor Which do you use?
tyingq 7y ago
Svelte was mentioned here yesterday. It's not like the old jQuery days, but it did look simplified to me as compared to other popular toolsets. https://svelte.dev/ https://svelte.dev/ Some examples: https://svelte.dev/examples https://svelte.dev/examples
kerkeslager 7y ago
If you don't need to support older browsers, just write raw JS and use module imports. This means that you're pulling down a lot of different files instead of one big blob, but a lot of those files will already be cached in the user's browser from CDNs anyway. Yes, you don't get JSX this way, but I've always seen people's obsession with syntactic sugar as bikeshedding. Typing out code isn't the bottleneck for development, it's just one of the easiest things to optimize, so people obsess over optimizing syntax while much more significant problems like debugging and traceability are largely ignored because people don't understand them as well. Worrying about losing the benefits of JSX when you're writing a language that still fails silently when you reference a mis-spelled property on an object is like worrying about your haircut while you bleed out from an arterial wound.
- cogman10 7y ago
  Browser support is fairly new, I was actually surprised when you mentioned you could do this now :). But yeah, probably not a terrible way to go. If you are working with an http2 server today then this will work really well.
  - fzzzy 7y ago
    Chrome, Safari and Edge have supported it since late 2017; Firefox since May 2018. So it should be quite safe to use by now.
- kaoD 7y ago
  > a lot of those files will already be cached in the user's browser from CDNs anyway Not anymore. https://www.jefftk.com/p/shared-cache-is-going-away https://www.jefftk.com/p/shared-cache-is-going-away
  - kerkeslager 7y ago
    Interesting. That means that the module approach isn't faster than bundling, but with HTTP2, the module approach shouldn't be slower than bundling.
lastmjs 7y ago
I encourage you to try Zwitterion, that's exactly its goal

Filligree 7y ago

Vanilla JS? For most purposes I find that all these frameworks are simply unnecessary. As a bonus, all the debugging tools in Chrome work much better when there's no obfuscation or packing, and "recompiling" is just Ctrl-R. Code size and load speed is also massively better than it would otherwise be. Pages load instantly. It's nirvana, I tell you.

krapp 7y ago
The funny thing is, all of these frameworks are designed for teams building professional sites at scale. They shouldn't be the standard for all javascript development. Not every javascript application needs NPM, a frontend framework and recompilation.
gherkinnn 7y ago
In my experience that results in the team building an inferior, untested, undocumented, and buggy version of React|Vue|jQuery|lodash. Now you need to train new peeps to handle that mess. And you haven’t even started solving actual problems. Provided you really need so much bulk at your disposal. But that’s a different story.
- tl 7y ago
  My experiences with React / Vue / Angular: server side rendering plus a reasonable refresh interface (LiveView, PJAX, Turbolinks, etc...) wins until you reach the point where native code is a better solution anyway. JQuery / lodash: we’re slowly getting better about modern browser availability and needing these less, but it’s a long road.
  - gherkinnn 7y ago
    Despite working mainly with TS and React, I almost agree with the first part. There are all to many cases where a minimal setup works just fine. My hope is that such a restrained setup inherently suppresses stupid features nobody asked for. And yet here we are.
- z3t4 7y ago
  Frameworks are managers pipe dream. Vanilla never gets old.
- Filligree 7y ago
  Perhaps that's the case. I'm assuming small-scale/personal sites, where there's no team and one person does all the work.

wayneftw 7y ago

Create-react-app is what you’re looking for.

archie2 7y ago
But then you're forced to use React...and as soon as you need to do anything outside of what it provides it all falls apart which happens pretty quickly in my experience with it.
- christophilus 7y ago
  I’ve been doing React for years and haven’t experienced this. What kinds of apps are you building?
  - omegabravo 7y ago
    - web components - runtime plugins React is great if you stay in the design constraints, which is to be expected. This covers the vast majority of web apps. edit: [removed svg snippets] I think I was confused with WebComponents not supporting svg elements that don't include the root tag
    - christophilus 7y ago
      The app I currently work on is 100% runtime plugin based. React has not been an issue there at all. I haven’t tried using web components, though, so can’t speak to that.
      - omegabravo 7y ago
        it's not impossible, I have something working with react-registry. With Vue it would work out of the box since it comes with a registry out of the box.
  - gherkinnn 7y ago
    React Router used to be a mess. And should I use Redux? I thought it’s not cool anymore. If I do, do I store everything in a global state? Maybe I’ll use Context and Hooks. Or was it HoCs? And what about mobX? I heard it’s like Vue. I like Vue. And I absolutely need something to handle requests. Saga? Maybe some GraphQL? Now that I have my views, my state, and my data, how do I test this? Jest or something else? But why write tests if I have Types! How to configure TS? A few any never hurt anyone, did they? Too many questions. I’ll let Create React App answer this for me. Or is it Gatsby? Or even Nextjs? Oh, and is Lodash the new Underscore? And what is different about those and Ramda? We need more FP! But how do I structure my Code? Dan “Daddy” Abramov tells us to organise it any old way. But how? [0] Angular and to a lesser extent Vue give you more direction. This is of course not inevitable in a React project, but it does take good technical leadership not to be hindered by analysis paralysis before you even set off. 0 - An exaggerated summary of what I gather on various forum and discussions.

duhi88 7y ago

Deploying JS (or anything) over the web usually requires a lot of extra considerations. Devs want flexibility in their deployment options, which is why Webpack is so complex. Parcel is probably the closest to zero-config that I've seen. Only drawbacks are when you want to do something "off the rails". I'm guessing this project will be the same. Of course, if you're not worried about supporting IE11, you could waive any built step and be absolutely fine. Gzip is more important than minifying.

ccday 7y ago

Ember.js is very much batteries-included although learning the framework definitely requires a time investment.

kerkeslager 7y ago
Ember.js is the highest-cognitive-load framework I've ever used. Not only do you have to understand all the bundling of JS, but you have to understand Ember's naming conventions and project structure, which has a lot of corners and edge cases. The basic problem is that they give you a bunch of configuration points and if you don't know what configuration point to insert your code at, you're either going to be writing a terrible hack, or you're just plain unable to do what you need to do. There are similar issues with React, Angular, Django, etc., but Ember is the worst one I've ever used. It's been a while so maybe the situation has improved, but I'm simply not willing to go back to something that has burned me that badly.
- cogman10 7y ago
  They burned me with the "rails" problem. Ember and RoR are two projects that have really turned me against overarching frameworks. Both have gone through periods of crazy backwards breaking and paradigm shifts that have left me burnt out.
  - kerkeslager 7y ago
    Agreed. I work in Django, and have a love-hate relationship with it. The main selling point is the Django ORM, which keeps me coming back, but even that is just the best of a lot of bad options. And a lot of Django patterns (class-based views, template tags, middleware, signals) are just obfuscating features that are handled much more simply with raw Python features. They let you write 80% of your behavior with 20% of the effort, but drastically impede your progress on the other 20%, and create debugging nightmares. Beware projects with impressive quickstart guides.
    - cogman10 7y ago

mumphster 7y ago

Parcel (https://parceljs.org/ https://parceljs.org/) fits this bill nicely and I use it for all my personal frontend development needs (node and browser targeted). You just add a script tag that points to a js/typescript/rust/(whatever else the author eventually adds) file and run parcel on said html file and you get hot reloading, decent error reporting, bundling, and asset loading via `import` without having to configure a single thing (other than npm installing sass and react and whatever other libraries you want to use))

bauerd 7y ago
Yep, tried this recently after being out of JS land for a while, and Parcel just worked. So +1
tghw 7y ago
It's also significantly faster the webpack, at least in my experience.
jjeaff 7y ago
This is what I was going to suggest. I am working on moving towards react and some other better practices for our current jQuery/spaghetti code front end and I needed to be able to handle multiple entrypoints and types. I messed around with webpack and create react app and gulp and several other things for days before coming across parcel. It just works. Want to build your react app? Just tell parcel where your index.js is and it will see your react and react dom imports and just build it. No config needed. Want to do react in typescript? Just change your entrypoints to index.ts. Done. Even handled the yarn add commands for you. This allowed me to easily have a few different react entrypoints as well as just a few random .ts files for use on pages that aren't built in react yet and then I just watch or build using a wildcard and it takes care of it all. So far, I'm a big fan.

turtlebits 7y ago

I really like svelte, there is a build/compile step, but it’s pretty much batteries included. I have not needed to touch any of the config files and it “just works”. I got turned off by React and Vue where you need to learn a build tool and write your own config.

lastmjs 7y ago
Zwitterion could add support for .svelte files rather easily

kabes 7y ago

Meteor comes pretty close being a zero-config build tool and free choice of frontend framework. But you do need to understand the framework

solarkraft 7y ago

> My C# editor Which do you use?

tyingq 7y ago

Svelte was mentioned here yesterday. It's not like the old jQuery days, but it did look simplified to me as compared to other popular toolsets. https://svelte.dev/ https://svelte.dev/ Some examples: https://svelte.dev/examples https://svelte.dev/examples

kerkeslager 7y ago

If you don't need to support older browsers, just write raw JS and use module imports. This means that you're pulling down a lot of different files instead of one big blob, but a lot of those files will already be cached in the user's browser from CDNs anyway. Yes, you don't get JSX this way, but I've always seen people's obsession with syntactic sugar as bikeshedding. Typing out code isn't the bottleneck for development, it's just one of the easiest things to optimize, so people obsess over optimizing syntax while much more significant problems like debugging and traceability are largely ignored because people don't understand them as well. Worrying about losing the benefits of JSX when you're writing a language that still fails silently when you reference a mis-spelled property on an object is like worrying about your haircut while you bleed out from an arterial wound.

cogman10 7y ago
Browser support is fairly new, I was actually surprised when you mentioned you could do this now :). But yeah, probably not a terrible way to go. If you are working with an http2 server today then this will work really well.
- fzzzy 7y ago
  Chrome, Safari and Edge have supported it since late 2017; Firefox since May 2018. So it should be quite safe to use by now.
kaoD 7y ago
> a lot of those files will already be cached in the user's browser from CDNs anyway Not anymore. https://www.jefftk.com/p/shared-cache-is-going-away https://www.jefftk.com/p/shared-cache-is-going-away
- kerkeslager 7y ago
  Interesting. That means that the module approach isn't faster than bundling, but with HTTP2, the module approach shouldn't be slower than bundling.

lastmjs 7y ago

I encourage you to try Zwitterion, that's exactly its goal