3 ms·

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

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

chrischen 6y ago
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.
- ratww 6y ago
  > 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/domz / https://www.npmjs.com/package/htm https://www.npmjs.com/package/htm / https://www.npmjs.com/package/react-hyperscript https://www.npmjs.com/package/react-hyperscript
  - chrischen 6y ago
    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.

chrischen 6y ago

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.

ratww 6y ago
> 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/domz / https://www.npmjs.com/package/htm https://www.npmjs.com/package/htm / https://www.npmjs.com/package/react-hyperscript https://www.npmjs.com/package/react-hyperscript
- chrischen 6y ago
  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.