81–90 of 154 posts
Earlier quoted context omitted.
Most of the code people have written in Vue 2 is compatible with Vue 3. Vue 3 has just added some additional features. Sure, there are breaking changes, but not to an alarming degree.
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.
Earlier quoted context omitted.
Original author here. During the study, I explicitly forbid myself from writing general-purpose helpers which would make up a framework. Would you mind elaborating what in your view makes up the "custom framework"? Thanks!
Not OP, but in my reading of your case study, you still made a framework. Instead of having a code-based framework, where the methods and classes enforce how you implement your system - you created a convention-based framework (use a specific CSS naming technique, model your JS on this template, etc.).
Earlier quoted context omitted.
Most of the code people have written in Vue 2 is compatible with Vue 3. Vue 3 has just added some additional features. Sure, there are breaking changes, but not to an alarming degree.
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.
Earlier quoted context omitted.
I can't speak to React. But, both Vue and Angular have seen dramatic changes over the last few years.
Most of the code people have written in Vue 2 is compatible with Vue 3. Vue 3 has just added some additional features. Sure, there are breaking changes, but not to an alarming degree.
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…
I don't know who originally said it but "If you're not using a framework, you're building a framework". This repo even has the following caveat: (2) These usually end up becoming a custom micro-framework, thereby questioning why you didn't use one of the established and tested libraries/frameworks in the first place. That said, I don't hate it. For quite some time, I've taken the stance that a web development team ne…
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.
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 trying more and more to use frameworks, just to be able to hire more easily.
I appreciate this project a lot! As someone exploring webdev as a hobby, everything is new to me and there are a variety of frameworks. I'm hesitant to start from somewhere that isn't "vanilla". As someone only a little familiar with JavaScript, the script seems surprisingly comprehensible.
Earlier quoted context omitted.
Sorry :D nothing wrong with server-rendered HTML and forms for many use cases. Unfortunately, by the limits of connectivity, if you want to build something that is interactive, data-driven, and responsive at the same time you will always be forced to render on the client-side at some point.
> if you want to build something that is interactive, data-driven, and responsive at the same time you will always be forced to render on the client-side I'm not sure I personally agree with this blanket statement. Connection times can be, for a vast majority of users, measured in tens of milliseconds, giving us a pretty good budget for processing and rendering while still appearing to be "instantaneous" (100ms) or "…
I love it! It's definitely an exercise worth taking. Nice transfer size, and I'm happy to see that the code is quite maintainable. I do my wordsandbuttons.online in similar spirit: no dependencies, and all the pages are kept below 64KB. However, as the code base grows, I'm starting to employ scripts to do the grunt work for me. So while I don't have dependencies per se, code patterns become dependency it its own righ…
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.