61–64 of 64 posts
The code looks a bit messy to be honest, maybe it's just the variable naming. `const input$ = sources.DOM.select('.field').events('input')` Why not name it the same as the DOM function `querySelector` ? `const name$ = input$.map(ev => ev.target.value).startWith('')` Wouldn't in this case `name$` be a boolean, but then `map` is called on a boolean. I just find the syntax very confusing.
I am definitely an advocate for reactive programming, as I have used React Native to develop a cross-platform mobile application ( https://dedicate.datasilk.io ), but when it comes to web development, I am very much an advocate for using the basic tools that were given to us web developers to build web applications. These tools include mainly HTML & CSS, and when needed, "vanilla" JavaScript (and maybe even a compact…
This is an unnecessarily absolutist position. If HTML, CSS and JavaScript are a "near-perfect solution to a very complex, graphically interactive problem", then why did people come up with front-end frameworks in the first place? Because they're useful! Frontend developers aren't just cargo culting their architecture decisions; they're trying to finding that the benefits outweigh the downsides, particularly with comp…
When you take a few hours to build and maintain your own micro-js libraries, you eventually get to a point where you no longer require using 3rd party js frameworks that are bloated and buggy. Why? Because you took the time to learn JavaScript! I would also argue that the only reason why those dev teams realized that they needed abstractions was because they were bad at maintaining & documenting their own micro-libraries. Also, once you build a micro-library for JavaScript, what's the point of maintaining it? Standards are here to stay, no modern web browser will significantly change the way things work, so once you build a JS library that works well, there is no need to maintain it unless you want to add new features or fix bugs.
The level of abstraction that cycle & react & angular and all these frameworks create is unnecessary because again, it leads programmers astray from writing HTML and utilizing JavaScript properly.
My (so-called absolutist) perspective is a coming from a culmination of 18+ years of development time, building VB desktop apps, ASP web app, ASP.NET Web Forms & MVC web app, ASP.NET Core web apps, C# desktop + windows service apps, Magento ecommerce sites, Concrete5 sites, old-school Flash/PHP web apps, a React Native mobile app, and many static websites. I've built a jQuery clone library in under 5kb in size, bootstrap clones with theme support, various drag & drop CMS platforms, and everything in between. I've used failed technologies throughout my career and I've received funding for my projects in the past, I've had to develop sites that support IE 5.5, 6, 7, 8, 9, 10, 11... and from all of my experience, I can say without a doubt that HTML, CSS3, and hand-written JavaScript along with REST APIs is by far the best way to develop a web application, period.
People create front-end frameworks for various reasons. Maybe so they desire fame, maybe because their company had a need for it, maybe because they don't like HTML & "vanilla" JavaScript. Whatever the reason, it doesn't matter. Every framework has its benefits and its drawbacks, and none of them are worth investing time into learning because they all hide behind a layer of JavaScript that doesn't need to exist, period. It's just another thing that every single user will have to download & cache when they visit your site, and if the framework is poorly developed, it'll become another list of things every single user will have to download & cache when they visit your site.
It's really unacceptable, especially to see nearly every major website require visitors to download over 1 MB of unnecessary resources whenever visiting their website. Why? Because of JavaScript bloat.
I am definitely an advocate for reactive programming, as I have used React Native to develop a cross-platform mobile application ( https://dedicate.datasilk.io ), but when it comes to web development, I am very much an advocate for using the basic tools that were given to us web developers to build web applications. These tools include mainly HTML & CSS, and when needed, "vanilla" JavaScript (and maybe even a compact…
I’ve been writing single-page apps for about 4 years now, and somewhat agree with your sentiment. Lately I’ve been experimenting with Jekyll and Vue. The approach is not perfect but it’s a lot closer to the simplicity of the old-school approach you are preaching.
Earlier quoted context omitted.
I’ve been writing single-page apps for about 4 years now, and somewhat agree with your sentiment. Lately I’ve been experimenting with Jekyll and Vue. The approach is not perfect but it’s a lot closer to the simplicity of the old-school approach you are preaching.
Vue is very close to a straight-forward approach. I would argue that Mustache.js would be a more straight-forward approach than Vue since it is simply a string parsing library for binding JSON objects to templates. No event binding, no black box, just simple template rendering and then you can do whatever you want with the rendered string.
For example, right now I'm working on a form with dropdowns that filter the next dropdown and with Vue I can do that with very concise code which is simple and easy to reason about.
With Mustache or jQuery it would be tedious. I'd need functions for every little change of the DOM and multiple event listeners and its handlers.
Data-binding is great for this kind of data driven stuff. Not so great for other use cases. Last week I was working on a drag and drop solution with React and it was a pain to figure out how to do it.