6 ms·

This is nice, patterns over libraries. I would question the choice to use ES5, as it makes it significantly more complicated to handle dependencies between mod

by tobr 6y ago

This is nice, patterns over libraries. I would question the choice to use ES5, as it makes it significantly more complicated to handle dependencies between modules in a scalable way. I understand the point of avoiding a build step, but if the code can run in modern clients without it I don’t think it breaks the spirit of the project to use a bundler to support certain older browsers. It’s a lot like using polyfills when needed.

rablackburn 6y ago
Agreed, I originally thought this might be an older project from a couple of years ago because of the ES5. “Vanilla” doesn’t have to mean “supports IE11” in 2020 (before anyone jumps on me, yes, depending on your users you may very well still need to support it, but it’s very clearly on the way out - finally) I love the motivation behind the repo though. The author’s write-up is fantastic and refreshingly reasonable in the dogmatic webdev world. It gives great insight into the places where real value _is_ provided by frameworks and build tools
- morrvs 6y ago
  Thank you very much! This is quite exactly what I'm trying to achieve. Very happy that you like it :)
brodo 6y ago
I did not know how widespread ES5 is nowadays: https://caniuse.com/es6 https://caniuse.com/es6 says 94.69% of users worldwide use a browser that fully supports it.
morrvs 6y ago
Original author here - thanks! Yes, ES5 is a huge pain. However, I believe 5% of users (see other comment) are not a joke for many apps. There's always the question of minimum critical APIs required: If you build a 3D or webcam app you can forget ES5 altogether, of course. > It’s a lot like using polyfills when needed. Never thought of it this way, thanks for that! As is state in the conclusion, the study would likely be more convincing with ES6 and build steps. So yeah, ES5 is questionable :)
- jeroenhd 6y ago
  I very much appreciate proof that we don't need modern frameworks as much as people claim we do. As for ES5 support, would you consider using something like Babel to be close enough to using polyfills to consider them? Transpiling ES6 into ES5 fixes your compatibility issue with ES6 just like I would argue adding a polyfill for WebP images would.
  - morrvs 6y ago
    Thanks, although I wouldn't claim it to be "proof" :) and yeah, the choice of ES5 vs. ES6 seems to be a major weakness of the study as others here have said as well. In any case I believe switching the current product to ES6 would make the results even more convincing.
- DarkWiiPlayer 6y ago
  Partly I agree, 5% of users is a lot. However, this number will only continue to decrease as time goes on, and it also has to be questioned for any specific product whether that number is bigger or smaller on average. Both for the (near?) future when ES6 is near-universal and for projects that have the luxury of just ignoring older browsers even today, it would be nice to have a proof of concept project like this that uses modern ES6 features, since many of them address precisely the types of problems that many pre-processors also fix. Template-strings, custom elements, etc. add a huge amount of possibilities for web-application development and imo should get way more attention outside of a small circle of excited people.
  - morrvs 6y ago
    Completely agree. In hindsight the choice of ES5 is questionable and in the study I actually conclude that another ES6-based experiment is desirable. Also, as others here have noted, you could start with ES6, see if it works for enough of your users, and only if not orthogonally introduce transpilation to ES5 as a production optimization.
- runarberg 6y ago
  Most of the websites I write these days don’t have a build step for development, only for production. Modern browsers (and modern node) support ES modules, so there is no need to build anything until you ship to a legacy browser. The only pain point of not building during development is when I need to pull in a third party dependency (since node and browsers pull from different sources; and import-maps is not is still not a standard), but if your are not using any third party dependencies, you should be fine.

by tobr 6y ago

rablackburn 6y ago

Agreed, I originally thought this might be an older project from a couple of years ago because of the ES5. “Vanilla” doesn’t have to mean “supports IE11” in 2020 (before anyone jumps on me, yes, depending on your users you may very well still need to support it, but it’s very clearly on the way out - finally) I love the motivation behind the repo though. The author’s write-up is fantastic and refreshingly reasonable in the dogmatic webdev world. It gives great insight into the places where real value _is_ provided by frameworks and build tools

morrvs 6y ago
Thank you very much! This is quite exactly what I'm trying to achieve. Very happy that you like it :)

brodo 6y ago

I did not know how widespread ES5 is nowadays: https://caniuse.com/es6 https://caniuse.com/es6 says 94.69% of users worldwide use a browser that fully supports it.

morrvs 6y ago

Original author here - thanks! Yes, ES5 is a huge pain. However, I believe 5% of users (see other comment) are not a joke for many apps. There's always the question of minimum critical APIs required: If you build a 3D or webcam app you can forget ES5 altogether, of course. > It’s a lot like using polyfills when needed. Never thought of it this way, thanks for that! As is state in the conclusion, the study would likely be more convincing with ES6 and build steps. So yeah, ES5 is questionable :)

jeroenhd 6y ago
I very much appreciate proof that we don't need modern frameworks as much as people claim we do. As for ES5 support, would you consider using something like Babel to be close enough to using polyfills to consider them? Transpiling ES6 into ES5 fixes your compatibility issue with ES6 just like I would argue adding a polyfill for WebP images would.
- morrvs 6y ago
  Thanks, although I wouldn't claim it to be "proof" :) and yeah, the choice of ES5 vs. ES6 seems to be a major weakness of the study as others here have said as well. In any case I believe switching the current product to ES6 would make the results even more convincing.
DarkWiiPlayer 6y ago
Partly I agree, 5% of users is a lot. However, this number will only continue to decrease as time goes on, and it also has to be questioned for any specific product whether that number is bigger or smaller on average. Both for the (near?) future when ES6 is near-universal and for projects that have the luxury of just ignoring older browsers even today, it would be nice to have a proof of concept project like this that uses modern ES6 features, since many of them address precisely the types of problems that many pre-processors also fix. Template-strings, custom elements, etc. add a huge amount of possibilities for web-application development and imo should get way more attention outside of a small circle of excited people.
- morrvs 6y ago
  Completely agree. In hindsight the choice of ES5 is questionable and in the study I actually conclude that another ES6-based experiment is desirable. Also, as others here have noted, you could start with ES6, see if it works for enough of your users, and only if not orthogonally introduce transpilation to ES5 as a production optimization.
runarberg 6y ago
Most of the websites I write these days don’t have a build step for development, only for production. Modern browsers (and modern node) support ES modules, so there is no need to build anything until you ship to a legacy browser. The only pain point of not building during development is when I need to pull in a third party dependency (since node and browsers pull from different sources; and import-maps is not is still not a standard), but if your are not using any third party dependencies, you should be fine.