> A lot things can be easier if you do things the "wrong way".

> It depends on your setup and use cases whether or not something is overkill, but for any reasonably large app just doing some HTML and javascript is not going to be enough to keep things maintainable...

I don't think you are responding to the point that the previous comment is making. The point is that there is a spectrum from let's say, traditional, to full-on SPA.

When presented with most spectrums of choice like this, it's expected that most people will weigh in requirements first and choose the solution based on the requirements (if they are an engineer, or pretending to be one.) In terms of expertise, they might love to write SPAs, but they realize that the other options on the spectrum exist for reasons other than being in, or out of fashion.

The problem is that some folks overemphasize what's in fashion. There are many reasons for this, and it's something that happens across other disciplines, not just programming. That said, we have a unique situation with programming in that someone can be quite an expert while only understanding one end of the spectrum. It's very easy for these folks to hold sway.

When it comes to the "wrong way", I agree with you, but I'd go further. If the requirements demand a SPA then you need to go all in and use the best modern tools. There are a lot of things created as we moved out of the full page render ages which don't result in good SPA development (for users or devs.) Embrace Typescript, React, etc because these solutions have evolved from that in-between stage.

Using "browser compatibility, accessibility concerns, localization/internationalization" isn't a great argument here. These are often orthogonal requirement. It's easy to argue that full page rendering, or static HTML meets all these more easily. These apps can't compete if you need particular interactive experiences.

I did address that it depends on your requirements. But my point is that it is highly unlikely that any requirements would be better served by vanilla JS + html than say writing your code with ES Next or React, unless you truly have some sort of limited use one-off thing.

Tools like webpack, babel, and react are also orthogonal to whether or not you're doing an SPA. These new tools aren't just to make your app a SPA, but are meant to decouple the maintainability of your code from the implementation details. React itself isn't even a framework but a paradigm which just happens to have a specific implementation that requires their runtime. The most recent shift is to turn your components into pure functions, and this is less about the framework and more about decoupling your app rendering logic from the react implementation. There's no objective argument that writing vanilla JS is better than writing modern ES next code. These language improvements are done to improve the failings of the javascript language after all.

You can totally use React to purely statically render your website. This is what most SSR implementations do, and the only reason JS is still activated is most modern apps require interactivity.

If you start doing vanilla JS and HTML you're doing a direct implementation. That's almost always the wrong way just because of browser differences between operating systems, mobile vs desktop, and all the other features that aren't really bells and whistles but more and more necessary as technology serves a bigger role. Perhaps in 1990 it's fine that a website can be made for a specific user for a specific purpose.

I have been working with various SPA frameworks for about 5 years now, from the bad old days of AngularJS to mostly React nowadays.

Your comment about 1990 seriously rubs me the wrong way because it seems to imply React et al. actually does something to address the points you make. It does not, at all. You still need to test your code on every viewport you support. And now you have to deal with an insane build process that rivals some C++ projects while doing it.

And there is absolutely an objective argument that staying close to the web platform is preferable than 200 layers of leaky abstraction and a 10MB uncompressed bundle of transpiled JS. The language itself is pretty okay in 2020, certainly not worse than anything else from the TIOBE top 10. I would definitely say writing a bunch of plain JavaScript is all that’s needed for most applications out there. If you can’t manage that without a frontend framework, the problem is certainly not with the platform or language.

Yes you still have to test your app on different platforms and browsers, but the point of the build process is that they make them work on those various platforms, whereas before you would have to manually fix those failed tests and hack in fixes for obscure conditions. That's what frameworks and libraries are for. They've abstracted away things so you can focus on higher level things. Tests are always going to be required, even if your framework and libraries are perfect.

We don't need to stay close to the platform because abstractions allow for more advanced applications. That's why most web apps don't use C, and should never use C, because 99% of the coding work is higher level tasks that don't need the bare-metal performance optimizations.

> Tools like webpack, babel [...] but are meant to decouple the maintainability of your code from the implementation details.

Let's be real, the only reason we really need WebPack and Babel at this point is for IE11 compatibility and JSX.

Currently >90% of the browsers (that depends on the country) are evergreen, and have support for most ES6 features, including ES6 modules. As soon as we're able to drop IE11 (when will Google remove IE11 support from Youtube?), the only reason to keep those tools will be JSX, which is frankly a minor convenience compared to the rest of React, and there are multiple alternatives to it that are not that terrible. [2]

Apart from that, WebPack and Babel are extremely hit-and-miss and terrible slow for anything but small-ish projects.

If you're doing SaaS or enterprise, chances are most of your customer-base is already 99.9% on Chrome or, in the worst case, in enterprise Windows-centric companies, Edge and that 0.01% is just waiting for something to tip them off.

I really can't wait to get rid of those two shitshows. Or maybe replace them with something actually useful, like Typescript compiled directly to modules.

-

[1] https://www.npmjs.com/package/domz / https://www.npmjs.com/package/htm / https://www.npmjs.com/package/react-hyperscript

Babel is there so you can write your code with the latest Javascript features and separate your written code from what is actually deployed. JSX and IE11 are a subset of problems that this type of abstraction can solve.

This is miles better than the previous alternative: manually importing shims or adding in css prefixes. Babel and webpack also enable macros and static code analysis tools so you can write code in "inefficient" ways that's more readable, and automatically generate more performant code automatically.

Browsers are still split, even if considering only desktop users. If you add in mobile users then all those iOS people are using Safari, not Chrome.

And because of this fragmentation you can't expect the latest ES features to be usable on day one. So you'll always want Babel so you can write the code the way you want, and have platform targeting be a separate concern.

It sounds like you believe that we should be writing very platform specific code for the web, which is a bad practice in general. Nobody should write platform specific code. Leave that to the compiler.

Nope. You're the one advocating targeting a specific platform, and it's called Babel.

What I'm advocating is targeting evergreen browsers whenever possible: Chrome, Safari, Firefox, Edge, and their forks. They already have most ES6 features. Even Safari has great ES6 support. iOS is known for being very up to date. Fragmentation in Javascript is a thing of the past, as long as you only use features available for +90% of the people on caniuse.com.

If you're targeting evergreen browsers you can already write the latest Javascript, and would only need Babel for something like JSX. All those browsers have async/await, ES6 modules (aka import), arrow functions, and destructuring.

To separate your written code from what is actually deployed is much more of a con than a pro. I'd rather not need a compilation step if possible. My time is valuable. Babel and Webpack are slow as a dog for non-toy projects.

Manually importing shims are a thing of the past when you're targeting evergreen browsers. You can use something like Polyfill.io for edge cases, and it will cover the small number of

CSS prefixes have nothing to do with Babel or Webpack, they're normally handled by tools like PostCSS. Nothing to do with Javascript. Static Analysis is normally handled by tools like ESLint that can use Babel but can be completely decoupled from the compilation step. Or Typescript, which actually brings a lot to the table compared to Babel.

Again, this might be hard: maybe you need to handle customers with IE11. But to not need Babel is something we should aim for.

I honestly can't wait for Babel to be 100% unnecessary and to die. It is valuable in a world where Internet Explorer exists, but there is zero advantage in using it when it's unnecessary.

> than say writing your code with ES Next or React

Say again? One is a framework, the other is an updated version of the language that can be transpiled to ES3 for (non-mathematically) provably identical results.

React isn't a framework. It's a library for writing functional components which can, at the moment, target native mobile components and HTML components so that you are not writing the components manually in a platform specific way.