I'm reminded of back in 1997 (maybe 98, anyway long time ago), I had been on a JavaScript course with a British guy, and went over to his house. He showed me the little cv site he'd been working on, it had quite a nice design, much better than I would ever do if asked to design something. I looked at the code - it was all tables, so I decided to show him CSS at the end of which he thunderously proclaimed "That's what's wrong with this industry, there's always something new to learn!"
I think he's doing something with Sitecore now, make of that what you will.
The funny thing is, we've just been finding more and more complicated ways to make table-based layouts ever since, but they're better because they are CSS based? I dunno, I don't have to squint hard at CSS-Grid to see old table layouts peeking back at me.
With HTML Tables, it's easy to switch on the grid (border=1) and see what's really going on. Maybe I'm old fashioned, but WYSIWYG sure the hell made life easier. Unless you are a dedicated UI specialist, you'll probably spend way too much time dinkering with the web UI because it's not WYSIWYG. It's like trying to park an 18-wheeler truck in a normal lot: you can't just "go there"; you have to plan it all out in 7 steps and hope it all works. Bicycle science is now rocket science. I'd like scientific proof "it must be this way" to get whatever wonderful benefit non-WYSIWYG has. Device size handling? Make 2 UI's: fat and skinny; that's easier than parking the 18-wheeler.
> With HTML Tables, it's easy to switch on the grid (border=1) and see what's really going on.
With CSS it's actually easy to display the grid `\*{border=1;}`. With tables, you have a lot of them, and must go into each line of your page adding that clause.
Not long ago I had to write some JS (had to, not wanted to) to do something on a site, and got something working based on what I knew, only to be derided by a "real JS developer" that my code was "deprecated", "not following best practices", "not modern", etc.
He gave me his version which was around 10x more code and only worked in a subset of the latest browsers, while mine not only did but would probably work in everything since maybe IE5 or so...
Maybe that's considered a bug, but I don't want any of this trend-chasing. I write code to get things done. My users don't care, and they want to get things done too.
I think he probably doesn't know JavaScript at that point. I remember I got invited to an interview one time and they were impressed by my code for their coding assignment partially because it could print out in less than a page (no minification), and they referred to another applicant whose code had taken 6 pages. And I was just like - how could it take that much code?
if someone ended up with 10X the code using 'modern' JS and it did not work cross-browser while yours worked cross-browser including IE6 and up, then I strongly suspect I would prefer yours.
I think the should be improved is implicit in the first step, does can be improved imply a suggestion - if not the third step is a suggestion, and it's that third step I'm always seeing problems in, not to mention the third step in a scenario of too much too learn runs into the XKCD standards problem https://xkcd.com/927/
> It looks like 2018 was mostly a continuation of the trends we already observed last year.
> That's bad news for us, because we can't come out with a big scoop on how React's days are numbered, or the next big thing is this new state management library created by a 17-year-old Vietnamese high-schooler in her spare time.
> But that's great news for you, because it means you can spend less time worrying about what to use, and more time actually using it!
Then stop learning the frameworks and start learning the core of the language.
I got dizzy from all the options out there so I spent some time improving my knowledge of JavaScript itself instead of focusing on someone else's library.
In the end, those frameworks are "nothing" but a lot of JavaScript patterns stuck together.
Switching from one framework to another should't cause THAT much friction.
The main problem with frameworks isn't the frameworks but the MBA's who finished reading "Lean In", congratulated themselves for finally finishing a whole chapter book, and set out to "conquer the world" under the assumption that developing software is trivial, and the fact that it's not done yet is because the programmers are lazy and stupid and aren't using the right frameworks, googled "good web frameworks" and forwarded the first link to the engineering organization with the title "FYI".
I suppose the analogy in medicine would be to have this "medical hacker" mentality where you just go and do things, all the while learning. First you start with leeches, then you develop your own theory or four humours, https://en.wikipedia.org/wiki/Humorism, then you figure out there was this guy called Hippocrates who had lots of great ideas about medicine which you should totally read, but hey, who has the time nowadays, so you just skim through a blogpost with the summary of the most interesting tidbits.
You keep hearing the name "Pasteur" and the "germ theory of disease" which sounds mildly intimidating. Instead, make your own plague doctor mask with a organic herbs as a safekeep. That'll keep the germs away.
People think your plague doctor mask is really cool in instagram and you become moderately famous. People start asking medical advice from you. They keep mentioning something called "vaccines", which sounds really convenient. You read an obscure reference about primitive vaccination to smallpox and decide that's a great idea. You start scratching yourself with random things you find in the street to increase your "resistance" to all ills.
You create a blog around this cool concept of "resistance" and invite other people to scratch themselves. Someone dies from infection and you say they just can't use the tool right....
etc.
I presume the protagonist will eventually reach modern medicine if he's alive still, but it would be so much more convenient for all parties if he had become familiar with established standards before starting to share his ideas with the greater public.
The problem isn't that you have to learn another framework (although it does become a problem when they're all slightly similar and they start to meld together after the umphteenth, not to mention that learning slows down with age). The problem is that each frameworks brings along new edge cases, new problems and forces you to reinvent tools you already had for this new framework. Although learning new shit can be exiting, at some point, you gotta stick to something for a while so you can also actually build a lasting product with it, rather than building a new prototype but never finishing anything because you're distracted by a new shiny.
No one forces you to learn anything new if you don't want to. People aren't stupid, if they invent new something (and pour shit ton of effort into it like with Vue or React) they probably have a good reason to (previous PITA first comes to mind). And anyone's "I don't want to learn" whining is in no way a reason to not invent that new something because that will actually slow down progress of tech field (which we can't have under any circumstance, this is the backbone of my argument). Get your act together or give way to those who will.
Besides, client development is a cutting edge field.
I'm sure glad we're advancing beyond the abstractions we have in, say, Cocoa development (which is evolving as well). Seems incredibly selfish to suggest that everyone is incompetent and nothing new is good because you don't want to have to learn new things.
Yet somehow HNers convince themselves that it's scathing sociotechnological criticism of an ecosystem because we tolerate it for some reason. Meanwhile everyone would roll their eyes if you suggested something like "ugh, Objective-C replaced by Swift is like watching Apple read old books."
Well, it would be, and it should be, except for the unreasonable expectations from the "owners" who assume that everything they don't understand must be simple to do.
No.. NO, it isn't.