[andybak]

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?

[mumphster]

Parcel (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))

[jjeaff]

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.

[bauerd]

Yep, tried this recently after being out of JS land for a while, and Parcel just worked. So +1

[tghw]

It's also significantly faster the webpack, at least in my experience.

[Filligree]

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.

[gherkinnn]

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]

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]

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.

[Filligree]

Perhaps that's the case. I'm assuming small-scale/personal sites, where there's no team and one person does all the work.

[z3t4]

Frameworks are managers pipe dream. Vanilla never gets old.

[krapp]

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.

[duhi88]

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.

[turtlebits]

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]

Zwitterion could add support for .svelte files rather easily

[kerkeslager]

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.

[kaoD]

> 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

[kerkeslager]

Interesting.

That means that the module approach isn't faster than bundling, but with HTTP2, the module approach shouldn't be slower than bundling.

[kaoD]

Bundling also deletes dead code so it can potentially save a lot, especially if you import huge libraries and only use a small part of them.

[z3t4]

Can you give an example of a bundler that removes dead code and not just minifies it? Dead code removal in JS is a bit tricky, unless we are only talking about code after return statements and other low hanging fruit.

[kaoD]

IIRC as long as you use ES modules, tree-shaking is trivial?

EDIT: not that trivial https://webpack.js.org/guides/tree-shaking/

[kerkeslager]

A much better solution is to not import huge libraries you will only use a small part of.

[cogman10]

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]

Chrome, Safari and Edge have supported it since late 2017; Firefox since May 2018. So it should be quite safe to use by now.

[tyingq]

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/

Some examples: https://svelte.dev/examples

[kabes]

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

[wayneftw]

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

[archie2]

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.

[cnorthwood]

You don't have to use React. The template gives it to you, but if you delete all the code and never import React, you're never using it. I use CRA nowadays for either simple vanilla JS/SCSS brochure-ware sites, or for simple TypeScript sites

[kerkeslager]

What have you been doing that React doesn't handle?

I'm one of those people who is very, very suspicious of imports, and barely ever uses anything outside Vanilla JS, but even with that mentality I have to admit that some libraries have their place. These days I usually use Preact (basically a stripped-down React) and I've not really come across much that it can't handle.

The key for me has been to just write isolated components, and avoid the "full page application" anti-pattern that is so common in web applications today. React doesn't force the anti-pattern on you like other frameworks, so I've had pretty good luck with this. It results in fairly clean, reusable code, and users see positive benefits because it allows me to create consistent, predictable interfaces.

[christophilus]

I’ve been doing React for years and haven’t experienced this. What kinds of apps are you building?

[gherkinnn]

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.

[nicoburns]

Everyone worries about these choices in react, but you don't need to, for most apps, they're all good choices: use redux or mobx, doesn't really matter. Use lodash or underscore, doesn't really matter.

There are minor advantages to some of the tools, and the nice thing about the react ecosystem is that it lets you pick if you really need to, but for getting started, just pick one and move on.

IMO this is highly preferrable to the angular world, where some things just can't done without digging through poorly documented internals (at least this was the case wirh v4 when I last used it)

[kerkeslager]

> Everyone worries about these choices in react, but you don't need to, for most apps, they're all good choices: use redux or mobx, doesn't really matter. Use lodash or underscore, doesn't really matter.

I'd argue that they're all bad choices.

Redux/Mobx are just causing you to use global state, which forces you into a single-page application anti-pattern. I've stopped using either and my code has become massively less complex.

Lodash/Underscore are massive libraries that you end up using only a few functions from. Many of these functions can be written in <10 lines of code yourself, and some are equivalent to ones that already exist in newer versions of vanilla JS. In the latter case I'll often use polyfills, and remove them as support for the new features gets good enough.

[gherkinnn]

I agree. And since much of that is often superfluous, you end up with a “minimal” setup. Though this does require at least one experienced dev to make those choices.

And my experience tells me that fewer than 1 in 10 React devs can make those calls.

[kerkeslager]

I've used React for a while now, and I agree with you that most of these libraries are pretty garbage. I've solved this problem by just not using any of them.

These days I use two libraries: Preact and Immer. And I only introduce Immer to a project if state management becomes a pain point in the project, so I often don't even use Immer. I import these in my project with:

    <!-- in my base HTML template -->
    <script src='path/to/immer.js'></script>

    // in my JS
    import { h, Component, render } from './path/to/preact.js';
    import produce from immer;

This is sort of janky because Immer doesn't provide a real JS module, but basically all this does is pull in a total of four variables: h, Component, render, and produce.

[nfRfqX5n]

i think this is what happens when you do a lot of reading about web dev instead of just building and trying things out

[omegabravo]

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

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]

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.

[duxup]

>need to do anything outside of what it provides

Can you elaborate on what you run into?

[rhlsthrm]

They have an eject function which lets you modify The environment and extend it however you want.

[ccday]

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

[kerkeslager]

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.

[ravenstine]

I'm curious, when was the last time you used it? The Ember of today is a lot different from the Ember of 2015, and even the Ember of 2018. As of a week ago, it's now fully switched to a component library that can be used independently of the framework, and they're now template-only by default. It'd certainly be a shame if you completely gave up on it because of a version still using Ember.View.

EDIT: Forgot to mention component template co-location, which is pretty great, too.

[kerkeslager]

The last time I used it was early 2017.

However, I also remember that the rapid breaking of reverse-compatibility was also a problem. The fact that Ember is very different over time is a bug, not a feature.

To Ember's credit, their documentation is superb, and that includes detailed migration plans with each release. All the problems I ran into over time were solvable with the "RTFM" strategy. But I would rather use tools that I can keep a fairly-accurate model of the tool in my head, rather than ones that require deep dives into documentation for updates and trivial changes.

[ravenstine]

That's funny, because my perspective is the opposite on both points. I actually appreciate that they've been able to move forward with new ideas without worrying too much about backward compatibility. (though usually both new and deprecated features are moved into modules that can be imported separately) As far as documentation goes, well, I think it leaves something to be desired. If you like dozens of broken links, the Ember guides are for you. hahaha

Your criticism is totally fair, though. Part of the reason why I asked is because I'm going to be giving a talk at an Ember meetup I'll be hosting in a few weeks and part of it might be about why people are choosing not to use Ember and how we can make it better. So thanks for providing your perspective.

[kerkeslager]

> If you like dozens of broken links, the Ember guides are for you.

I suspect this happens when you fall behind their rapid release cycle, but I always kept my dependencies fairly current when I was using Ember. It's painful, but it's far less painful than falling behind and being forced to make updates all at once later (and with broken docs, apparently).

> Part of the reason why I asked is because I'm going to be giving a talk at an Ember meetup I'll be hosting in a few weeks and part of it might be about why people are choosing not to use Ember and how we can make it better.

My suggestion would be to find a way to make Ember more of a library and less of a framework, if that makes any sense.

I think what React does really well is that it's not weird or difficult to use a few React components in a completely non-React codebase, and it's not weird or difficult to use completely non-React code in a React-heavy codebase. React components are just that: components--there isn't a pervasive MVC structure that makes it difficult or weird to do stuff outside of it. If you have component A and component B, it's easy to have A on one page, B on another page, and A and B on a third page, or two A's, or two B's on the same page. Components are composable and isolated.

With Ember you have a few options to achieve this result: 1) duplicating code to allow the "components", 2) spinning up multiple MVCs in a page to isolate them from interactions, 3) writing some hairy conditional logic inside the "components", so that at least one of the components has to be concerned about the rest of the page.

2 isn't a bad option from a high level, but Ember assumes you'll only be running one MVC per page, and does a bunch of things which makes this nontrivial.

React Components aren't entirely unlike a little MVC, but the assumption from the beginning is that a React component may never have to interact with any other React component. Isolation is the assumption, rather than a single-page app full of entangled components.

But I completely realize that my suggestion is basically, "Make Ember more like React" and as someone with no investment in Ember at this point, there's not really a reason I'd choose Ember over React, which is supported and used by a bunch of much bigger and more mature codebases than Ember is, even if Ember were to switch to a more React-like model.

[cogman10]

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]

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]

Yeah, The big problem with these frameworks is that, by their very nature, they punish you severally if you ever step outside of the framework. This can cause a whole bunch of headaches if you decide you want to pull in new functionality perhaps not supported by the framework.

An example of that is when you want to mix things like Jquery or React elements in with Angular. It is (or at least was) far to easy to step outside of what react expects you to do. The end result is a break on minor updates. So, instead, you'll often end up with these janky half maintained library like "Jquery-ui-datepicker-angular" (made up) Or whatever that try to bridge the gap as best they can.

[lastmjs]

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

[solarkraft]

> My C# editor

Which do you use?