I disagree.
Web devs aren't discussing characters and plots but instead argue which typewriter to use.
Better tools don't make better apps just like word processors don't make better books. The best web dev tools are worthless if the UX is bad.
Better tools don't make better apps just like word processors don't make better books. The best web dev tools are worthless if the UX is bad.
But, consider, dream weaver and early design tools were ridiculously advanced compared to what most of us are creating in web sites. Flash tooling was a whole other level.
Many - most? - software devs know multiple ways they could make their apps higher quality, but they just don’t have the time or ability right now, or they have other priorities, or so on.
Better tools can, and do, enable engineers to simply do more than they otherwise could, and sometimes “more” actually does mean “better.”
Then the best most can do is two views (mobile and desktop) which adapt to some various widths in an obvious way, using loads of whitespace as a solution.
1) you have smaller screen estate and have to split some forms into multiple page wizards ( on desktop if you lack space you just popup yet another window wherever it popups)
2) you have to support different screen orientations (portrait, landscape)
3) you have to support corners cases like notch or foldable screens
4) you have to support different screen sizes and different screen aspect ratio (on desktop still many apps don't allow resizing and its ok)
5) you don't have precision input such as mouse where you can hover on some small button and see via tooltip what it does.
6) you don't have physical keyboard instead a virtual keyboard that on appear eats almost half of your already screen estate and covers other form controls.
7) mobile OS make limitation what you can do in the background, how much memory you can use
8) mobile OS don't allow just dragging windows and resizing, and switching windows easily using native UI
I know it's not how the world works, but I wish, if we could just show "them" how good the programs can be, how efficient the user interfaces can be, how awesome it is to use a real proper computer with real proper computer programs, instead of the toys on tablets... But I know I'm in the wrong.. I know it's "just me" and everyone else enjoys their glass plates. grumpy old man shows himself out
Worrying about making it work in mobile is an external requirement that arises due to the world we live in, not because of funsies. If someone could say "fuck supporting the shitty options" without bleeding a metric-fuck-ton of money for it, they would
I assume you mean any significant amount of time. I often write something quick on mobile, which works okay. However if it is more than a sentence or two give me a keyboard. The mobile is with me all the time though, my nice desktop with a full sized keyboard, large monitors and all that is back at home. Thus the compromise of often using mobile to write even though it is overall a worse experience.
Especially if all you wanted was to show a quick html output. It's incredibly common to see giant dynamic web stuff used for tiny static output that could have done without.
I've done both in large volume websites and I find now that using as little "framework" as possible and a limited number of "libraries" works better in terms of cost, bugs, dev attrition, business desire implementation and user speed of render.
Picture a giant mess of node dependencies surrounding a central giant quirky framework like VueJS. 5 years of dev, all devs left. You need to maintain that, is that going to be easy ? Wasn't for me.
It's why when I have greenfield I do vanilla web components, with a little lit-html sprinkled in for fast rendering.
I've seen so many developers complain about how complex vanilla web components are, and they'll turn around and do React / Vue / Angular and Redux or (shudder) rxjs, etc...
I just don't get it.
Like, if you need reactivity... Stick a render call into the setter of a plain old property.
If you don't, use a variable.
The whole computed() thing with Vue makes things so complex... I have to deal with a huge rabbit hole of that stuff all the time.
I think to myself... I could just use a property, and I wouldn't need a whole painful build step, type definitions, framework version specific DSLs, massive complex source maps that don't work, Rube Goldberg state machines, crazy pseudo DOM elements that aren't really DOM elements, unless they are, or a ref to something magic that might end up being a DOM element someday, obscure dependency injection cruft that's done way better by just using dynamic imports...
I remember when I couldn't wait for Proxy to be widely supported by browsers.
Now I'd do anything to be able to shove that toothpaste back into the tube.
I don't know.
I don't see any of this providing any value.
I feel like the emperor has no clothes, but everyone else thinks he's wearing Armani.
To this day I just do mysql/php/js and simple ajax calls for a lot of solutions. Most clients are in the 100k-500k of hits and it works fine.
A large "ecosystem" is touted as a great advantage of some frameworks, but the reality is that it's mostly unmaintained low-quality libraries that could be replaced by a few lines of easier to understand code. "The Ecosystem" is about quantity over quality, all the way down. And when those unmaintained libraries break, you're also in the hook for fixing them, but it takes way more time and coordination than fixing it if it were your own code.
You can build bad apps with good tools and good apps with bad tools. Just because it gets easier for the web dev doesn't makes it easier for the user and vice versa.
Yes, with a high probability. Try to put all your screwdrivers away and then try to build a shelf without them. Not only will you need lots of time just for fastening the parts that you cannot spend on thinking on a more optimal layout of the shelf, making the result worse -- you will also judge every layout idea on how hard it will be to build without a screwdriver, instead of judging it on whether it is useful as part of the final shelf.
> You can build bad apps with good tools and good apps with bad tools.
This is a (probably unintentional) strawman. The argument was that tools make the task substantially easier and therefore improve the quality of the end result, not that they make it possible at all.
> Just because it gets easier for the web dev doesn't makes it easier for the user and vice versa.
Again, the argument was that tools make it easier to build a good product, not that tools themselves guarantee a good product. Of course with good tools you can build a bad product, and you can even build it easier than without good tools.
Everyone in web dev uses tools of some sort. The argument might be that some tools are so advanced, it's like using a robot arm for tightening a few screws. Some devs will embrace robot arms, others will use a screwdriver.
Maybe it isn't the tools because there are great apps on the web,s some of them even without many tools. Maybe it's time to stop blaiming the tooling and focus on the developers and their environment.
I'm not a bad painter because of the wrong brushes, I'm just not good at it (yet).
probably you build the same quality shelves slightly faster, being able to build things faster allows you to learn faster, by not focusing mental and physical energy on the relatively stupid task of removing screws you have more mental and physical energy to focus on things that maybe actually help you build better shelves.
A lot of the badness of the apps however is somewhat business driven, dark patterns etc.
Similarly, I doubt that better web development tools improve the quality of apps. It likely just makes them cheaper.
Our industry is built on layers and layers, every layer is a tool to the next layer, how can we claim better tools don't make better applications?
Sure, it does not guarantee it, because what the tool does is raising the baseline, however raising the baseline gives you time to push the top higher.
The layers are there to make developers more productive, not to make code quality better. In fact, layering is probably the most expensive thing that computers do today.
Let's do the music one: how an instrument feels (to you) is intricately linked with how well you can express yourself musically.
I guess there are two different view points here, those who think the things used to create something have no bearing on the essence of the thing that is being created and those who think that you cannot divorce the two.
Isn't that just a discussion about platonism in disguise?
On the other hand, if your web app takes forever to load because of a huge React payload or poor server performance, I do care.
Frameworks are the scaffolding, the skeleton. They dictate the shape. It's literally in the name.
> : a skeletal, openwork, or structural frame
Tools are the things you use to build within that skeleton.
More pragmatic: Rails is a framework that dictates an MVC shape, with an RDS, that produces server side rendered HTML or data in a RESTfull manner.
The tools you use for Rails development are your IDE, a CI, revision control, a terminal, maybe even the IAAS provider.
So maybe words like tool, scaffolding (and even framework) are just not entirely up to the job of describing what a 'software framework' is and ultimately lead to confusion.
A framework is not a tool. It is previous work that you build upon so you are not starting from scratch. It is a canvas, already assembled and sized.
Your toolset also dictates the shape like a screwdriver dictates the shape of the usable screws.
That is the semantic difference between tools and frameworks.
This doesn't mean one cannot ever use a framework as a tool, or a tool as a framework. But I'd argue in those cases one stops being resp. a framework or tool and starts being a tool or framework.