This is so true and I'm certain it's related to the noticeable downgrade in web performance and usability over the past five years. So many sites are flabby and slow now because they're retrieving countless packages from CDN's, each time of course with a ssh handshake, etc etc. You can see endless retrievals flashing on the bottom bar, sometimes literally never stopping, as the site keeps doing one thing after another to anticipate what you might want to do, load new content, or whatever. I find the web only barely enjoyable to use anymore. Even the simplest things seem to blow up now, e.g. very often I get "not found" for the Google homepage. Huh? That one's probably on me somehow, but I'm not doing anything different that I know of, but what has changed that I know of is the extreme increase in complexity of internet delivery and programming. And I will just vent one more pet peeve. Not EVERY part of a web page needs to pop something up in your face when you put the mouse over it. Thank you.
In web design, everything easy is hard again
261–270 of 335 posts
Re: In web design, everything easy is hard again
#262Earlier quoted context omitted.
I wonder which recent new web standards you think are fads. Push notifications? Offline web apps? Multithreading? async/await?
Not a fad but an example of what I mean (and the only one I can think of this early in the morning). "box-sizing". This seems to have been created because people are unwilling or unable to understand the standard "box model". People find box-sizing is easier for them but it is not necessary as it only combines already available and well understood sizing properties. Worse, many even use the '*' hack to apply it to ev…
> iirc, there was, or is, even an effort to make emojis part of the standard!
Part of what standard? What are you talking about? Emojis are defined in Unicode.
Re: In web design, everything easy is hard again
#263This is my experience of web development, every time I return to it. I’m really not an expert in web dev, but it _feels_ like web dev has been badly engineered. JavaScript is a very badly designed programming language (yes, even in its modern form), which I think has caused a lot of problems. Many JS developers don’t know much about programming language design, so they can’t see how bad it is, and they make matters w…
[deleted]
Re: In web design, everything easy is hard again
#264This is my experience of web development, every time I return to it. I’m really not an expert in web dev, but it _feels_ like web dev has been badly engineered. JavaScript is a very badly designed programming language (yes, even in its modern form), which I think has caused a lot of problems. Many JS developers don’t know much about programming language design, so they can’t see how bad it is, and they make matters w…
TLDR;
The language design of JavaScript is not the problem. There are 2 problems in my opinion:
1. Our reliance on typed languages, compile-time errors, and IDEs
2. Too many choices for frameworks and libraries.
I wouldn't agree that JS is a poorly designed language. I will come back to that soon.
I would argue, like some others here that we are just too lazy. We enjoy the safety provided by typed languages and compile-time errors. That is one reason to love our IDEs.
Back to the problem. There are a lot of things that you are saying. I will try and address them one at a time.
> web dev has been badly engineered. * Yes, no, and it depends. Web Dev is a very board, it encompasses many technologies, like HTTP, HTML, CSS, JS, Application servers, etc. So you are saying HTTP id bad? or HTML is bad? I know I'm reading it out of context, but bear with me. I believe you meant JS is bad. That brings us to your next opinion.
> JavaScript is a very badly designed programming language. * When you say badly designed language, what is it that you exactly mean? Is it the syntax? Is it the grammar? Or is it the fact that it is loosely typed dynamic interpreted language? And what are the problems you talk of, any examples?
> Is JS a recognized terribly designed language?
* Who recognized it, any sources? Like the U.S.A. recognizes ISIS as a terrorist organization. I'm pretty sure the developers of node.js do not recognize that JS is a terribly designed language.
> There are many frameworks for the same tasks, that try to do everything.
* Yeah, I agree. I really hate having so many choices. I have to spend too much time investigating which is the best one for my use-case. I'm just too lazy. (sarcasm was intended) That said, I still agree, and it does make life hard. But too many choices is not a bad thing necessarily.
> There "appears" to be an excessive number of package managers.
* There is only NPM, everything else is either deprecated or based on NPM. Please inform yourself better.
> ... range of solid and well-designed languages and technologies, but at the front end ... choose the least poor of a bunch of crazy options.
* WHAT? There is only 1 option on the web today; JavaScript. Period. Unlike backend. What you are talking about are framework and libraries. Check the "too many choices" point above. If you believe that backend development has fewer choices involved, then I assume that you sir have limited experience.
Anyway only recently has the community invested in improving this. Give it time, unless you believe something else can replace it before that.
Re: In web design, everything easy is hard again
#265Earlier quoted context omitted.
My Web pages are based on tables and have not even one DIV element! Why do I have to use DIV? Actually, I never saw any good explanation on what DIV did. What the heck is DIV good for? Why use DIV? Why can't I use tables?
> Why can't I use tables? I think it's harder to make design changes to the page. You also end up doing crazy rowspan and colspan things. You end up with more html tags (though probably less css). It's probably fine. Though it's probably hard to make mobile-friendly. A lot of html emails use tables for layout because they can't trust the layout will work with divs+css.
Okay. So far I haven't had to use the span thingys.
For mobile, I'm just assuming that the users smartphone has a Web browser. For fitting on the smartphone screen, each page is just 800 pixels wide, and smartphone screens are that wide? But even if not, my pages are still usable with only 300 pixels wide.
My most complicated page sends for just 400,000 bits which seems small enough. There are just two files, HTML and JavaScript (JS). The JS file is written by ASP.NET and is small and optional -- so I'm expecting fast page loading.
I didn't see any good reasons to do anything special or different for mobile. What am I missing?
Re: In web design, everything easy is hard again
#266Earlier quoted context omitted.
I would argue that web development have never been as easy as it is now and that a lot of people just does not take it seriously enough to bother to learn it properly. People think that just because that they did some jQuery development 10 years ago they should be able to use to the same skills now and discard all new developments. Being able to use modern JavaScript and with linting/prettier will in practice make it…
Easy? No, I believe it's very hard to setup a frontend project.
1. install node.js
2. npm install create-react-app
3. create-react-app your-app
4. npm start
Now you have a react app with a development up and running. To create a production build write "npm run build". To add a package write "npm install the-package".
Re: In web design, everything easy is hard again
#267Earlier quoted context omitted.
All those things existed before they became web sites, and they aren’t web sites for any particularly good reason today. Email is a good example. GMail is Outlook rewritten in VBA running inside Word. Let me guess... you’re a JS dev and you think “little upvote arrows” are where the real value is?
Except for the fact that most people use these services in the browser even when there are native clients available? In nearly all of the listed cases the bottleneck is almost always the network and not the JS runtime. Clearly the users are wrong, I guess? Perhaps you should explain to them why your delicate design sensibilities dictate that they should download native clients because you think HTTP has gone off spec…
you're a COBOL dev and think computers should have never developer GUI
Not quite that old, but I was doing web and Java professionally in 1995, so I’ve seen it all.
The users are not wrong; they’ve simply been trapped in a local minima by inexperienced developers who would rather reinvent the wheel than make progress. Except every time the wheel gets squarer.
Re: In web design, everything easy is hard again
#268Earlier quoted context omitted.
This isn't really true. jQuery's compatibility can stretch all the way back to IE8, up to the newest devices. If you require the web to be more than a document viewer, then you might in fact need some different tools; but HTML/CSS/jQuery didn't solve those if you're going back that far, Flash did. But HTML/CSS/jQuery still work to solve the problems they always did. And they're still used in production today. Accordi…
> According to W3Techs, jQuery is still present in 96.2% of the sites they could determine a JavaScript framework for But that doesn't mean jquery was used exclusively on these sites. Look at any major website, in addition to some modern framework, they will often include jquery for just a few old hacks (I've seen popular sites include 3-5 different jquery versions on the same page).
Many sites hang onto jQuery solely for the Ajax abstraction that allows older versions of IE to function.
Re: In web design, everything easy is hard again
#269I read this article in reader view of the browser.
Re: In web design, everything easy is hard again
#270Earlier quoted context omitted.
If you're using ClojureScript/Elm/whatever, there's going to be a lot more hassle to use existing tooling, such as e.g. test runners, syntax highlighters, etc.
There are plenty of tools for ClojureScript, including syntax highlighters and test runners. ClojureScript, like Clojure, also embraces the host platform, and can call out directly to JavaScript, so a lot of existing JS tooling is available as well. For example, the Karma test runner is frequently used. I’m not familiar with the Elm ecosystem, but I would be surprised if they don’t have pretty good (or likely excelle…
Yeah I mean, many compile-to-JS languages have pretty good ecosystems (I know Elm is one, and I believe you that ClojureScript is too), but it's always going to be a pain in the ass at some point. Hell, I've been wrestling with just setting up Jest with TypeScript not that long ago, and measuring code coverage still isn't perfect. You're not going to tell me that you never run into those sort of things with non-JS languages that compile to JS.