111–120 of 154 posts
This is odd (public/scripts/TodoList.js): el.innerHTML = [ ' ', ' ', ].join('\n'); I wonder why aren't they using `DOM.createElement` instead of innerHTML since they will query for those nodes later anyway.
Earlier quoted context omitted.
Sure, so which subset of HTML are we talking about? Because unless I'm misremembering things, HTML 2.0 (literally the first version intended to be a standard going forwards) came out exactly the same year that JS dropped in a commercial browser (1995), and superseded the previous HTML and HTML+ markups. So surely you don't mean HTML with things like file uploads, or GIF support. Because that's not "vanilla" in your w…
/s all you want but the distinction between documents and applications is clear.
Are Web Components ( https://developer.mozilla.org/en-US/docs/Web/Web_Components ) considered to be a library/framework? If not have you considered trying to update the repo to use them
No, I'd consider them a standard and a candidate for implementing the case study. When I started the study I was thrown off by this: https://caniuse.com/?search=components - and very huge polyfills. In hindsight I'm not sure if I dismissed WC too quickly. This is probably thin ice, especially since I've never built anything with WC, but they always seemed slightly over-engineered. I will try to learn about WC a bit m…
Web components are supported in all current browsers. Unless you support IE11 you don't need to worry about polyfills.
I saw a draggable package on mom that is less than 2k. Does Vanilla mean we can't use npm or we pack or browserify or anything?
Earlier quoted context omitted.
Using frameworks is far more about hiring and human resources than technology I feel. However, if your "micro framework" follows language idioms and is thin enough you get the best of both worlds, whilst releasing yourself from some of the downsides that come with using a general purpose framework.
Frameworks make hiring a bit easier it's true. I'm amazed at the number of developers who can't seem to cope with working with custom in house frameworks. I'm talking about fully working systems, with full source code and being walked through the code by the author / maintainer. They fall apart, constantly complaining that the approach is non standard, deprecated, dangerous, unprofessional, untestable. So we are tryi…
Earlier quoted context omitted.
In other words, the good old MVC pattern. (M) Model is your `data`. (V) View is what your function returns. (C) Controller is the functions your elements may use to mutate the data.
MVC doesn't mean "has data, logic, and UI". MVC is a model for how the UI communicates with the data store.
Earlier quoted context omitted.
> Often a custom micro-framework better suits the needs of a particular project. Fitting the needs of a particular project is frequently a local optimum however. Often, it's much more optimal to focus on the needs of a whole team or even whole company. You can hire people who already know React/Vue/whatever, but there is no one in the world who knows your micro-framework.
But due to its micro-size, it won't take long to learn.
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 w…
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 likel…
Using ES5 is pretty much always a mistake in 2020.
Earlier quoted context omitted.
React has been stable since ~2015, and there are no signs of that changing.
Disagree; the "done thing" in React has shifted since then (moving from class-based components and HOCs to functional components and hooks), and in the wider ecosystem, Redux is being abandoned in favor of more React native things like Context. While React apps in 2015 probably still work with the newest versions of React, you can't put a 2015 React dev in a 2020 project and vice-versa as if nothing's changed.
Earlier quoted context omitted.
Most of the code people have written in Vue 2 is compatible with Vue 3. All of the code written with React 15 is compatible with React 16. And React 17. And React 18. And so on probably.
This is simply not true. React 15 is not compatible with React 16 and it can even take substantial effort to upgrade if you used componentWillReceiveProps (though which in hindsight could be avoided in the first place)