Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In web design, everything easy is hard again

frankchimero.com

Post reply on HN
Print view View original

131–140 of 335 posts

Re: In web design, everything easy is hard again

#131

Post by kaoD »

hnzix wrote: post #81
BigJono wrote: post #60

Earlier quoted context omitted.

I've been a professional Javascript dev for over 5 years and never once run into a bug due to any of these problems. I agree that they are problems, but their impact on day to day use of the language is zero. If you want examples of real problems that give good front end devs hell day in and day out, start looking at some of the libraries, tooling and abhorrent "best practices" that get thrown out and cargo culted to…

I've spent days tracking down a bug around a color picker widget, turns out JS was implicitly casting my string value to octal. I've worked with heaps of toy languages like Lingo, vbscript and ActionScript, and nothing has made me as viscerally angry as JavaScript (ok maybe PHP's complete lack of naming consistency). JS is an accident of history that has somehow become the de facto standard. I guess worse really is b…

> turns out JS was implicitly casting my string value to octal

How exactly? I'm really curious. AFAIK it's pretty hard for a JS string to be casted into anything (pretty easy the other way around though).

I guess maybe parseInt can do that, but that's neither casting not implicit.

Re: In web design, everything easy is hard again

#132

Post by bryanrasmussen »

baq wrote: post #64
nawitus wrote: post #54

Earlier quoted context omitted.

Modern JavaScript is not a very badly designed programming language. It's a good, productive programming language. Most of the quirks can be disabled with a linter, and optionally a lot safety can be brought in with typing (using e.g. TypeScript). On the other hand, many developers don't know much about programming and JavaScript, and therefore tend to have unjustified criticism of the language. JavaScript was a perf…

this is all wrong, sorry. modern js is still js. the fact that linters are _required_ to keep code sane is proof enough. typescript is a different language, i'd wager it doesn't count, even though i agree it's a considerable improvement. au contraire, many developers know exactly what programming in js looks like, especially compared to other languages. i used to think that c++ and boost compilation was crazy. now i…

What language do you use that does not have a linter?

Re: In web design, everything easy is hard again

#133

Post by mafribe »

bitL wrote: post #103
pka wrote: post #53

Earlier quoted context omitted.

> If anyone has advice on how someone who prefers rigour, simplicity, elegance, and decent PL design over the latest trend should approach web dev that would be massively helpful Sounds like Elm [0] (pure, functional, very very easy to start with but lacks abstractions), Purescript [1] (pure, functional, powerful, the best language for the web right now, imo) or ReasonML [2] (functional but impure, familiar syntax, f…

And for non-functional languages? Not everybody wants to spend next 5 years learning thinking bottom-up, mastering category theory, monads and all that for such a task like writing a silly webpage you wouldn't rather be doing. [rant] Frankly, I am not sure why is functional paradigm considered a savior and better approach for inherently non-concurrent web frontend technology. I program in Haskell/Scala but pushing fu…

I'm surprised that you think FP requires mastering category theory. Au contraire. It's perfectly possible (and indeed easier for programmers) to understand the abstractions that Haskell and Scala pioneer (higher-kinded types, and things like type-classes as well as monads which are basically enabled by HKTs) without category theory. It is true that monads were discovered via category theory, but in retrospect programmers could have discovered them -- after all they are (simplifying a bit) merely a way of generalising composition.

Scala and ML-variants like Ocaml, F#, Reason.js are perfectly good imperative languages. They don't force you to go purely functional. I always recommend that my students (whose first language is Java) start by treating Scala as a "nicer Java", and then slowly explore Scala's more powerful features. Indeed, I'd argue that Scala and the aforementioned ML-variants are (slightly) better general-purpose imperative languages than the Javas, Pythons, PHPs and Javascripts of this world, because they are more consistent, they have types/type-inference, and their statefulness fully supports higher-order state and powerful modularisation without restriction, not to mention pattern matching.

Being able to use functional idioms without compromise if and when desired (including, but not restricted to, pure functional programming) is another benefit of Scala and ML-variants.

Re: In web design, everything easy is hard again

#134

Post by adventured »

gaius wrote: post #129
bryanrasmussen wrote: post #128

Earlier quoted context omitted.

it may be, on a fundamental level, an incredibly stupid thing to even try, but it also seems to have been an incredibly necessary thing and incredibly appreciated thing by most of the world.

Necessary how? All the actually useful things you can do on the web you could have done with a 90s browser. I bet Amazon still works in one! Moving apps into browsers is a step backwards for most apps and most users. I was using Jupyter the other day; it’s clunky as hell compared to MathCAD from 20 years ago. We use 1000x the computing power, literally, to deliver 10% of the experience. Keeps a lot of devs employed I…

> All the actually useful things

You're pre-emptively trying to define what's useful for everybody else. That's the only way your premise works.

In my equally subjective view, XMLHttpRequest radically altered and improved the useful things you can do with the Web.

You can't use a 90s browser for Google Maps, Gmail, YouTube, nearly any online productivity software, and dozens of other common activities on the Web today. You would have to strip the services down to make them work, ie turn them into completely different products.

Simply put, most of the things most people do online today, can't function in a 90s browser. Just try using IE 5 or Netscape 4 with nearly any of the major Web services today. You can't. IE 5 with Facebook's non-mobile site? You have to build an entirely different product to make that work, basic interactivity drops to near zero.

1990s MapQuest sucked, big time. Google Maps is a radical improvement. How about simple things, such as smooth, fast, highly interactive stock charts, or real-time updating stock quotes, without having to reload the page constantly? 1998 browser? Nope.

Would the user experience be better if everything on the Web adhered to strict 1998 standards? That's an obviously subjective opinion. I don't think so. Do people like to see instant previews of the content they're about to post to Facebook or Twitter? When they click the little upvote arrow, do they like to see an appropriate reaction? When posting basic content or interacting with simple site features, do they like having to reload the entire page?

Re: In web design, everything easy is hard again

#135

Post by user15672 »

cc81 wrote: post #79
Donzo wrote: post #74

Earlier quoted context omitted.

One of the best things about working for myself is that I write all my web stuff in vanilla JS. While I occasionally make errors, they are easy to identify, understand, and debug because the native features of JS are well-understood by modern browsers. Sometime in the last decade, modern web development moved on without me. I can no longer recognize what people are doing with all of these package managers and why the…

Sure that works, especially if you tend to write more web sites than advanced web applications. But that is true for back end as well, a one man operation can write Python or Java in a style and using libraries from 10 years ago and it would work perfectly fine. But depending on what they are doing they might not be as productive as they could be. If you want to try for example React it is incredibly easy to get star…

This made me chuckle, since modern Python and Java styles are very, very similar, if not identical in places, to those of 10 years ago. Some of the libraries have changed, but many are the same as well. Shoot, I can still run Python code I wrote 10 years ago on the latest version (yep, that means something originally written for Python 2.3 can run fine on Python 3.6).

And no, that doesn't make Python and Java old hat or redundant.

Re: In web design, everything easy is hard again

#136

Post by z3t4 »

randomsearch wrote: post #9

This 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…

can your web site be pre-rendered or rendered on the fly? then do server side rendering - only send html to the client. if you need dynamic rendering - use static js - only for those parts. if you need everything to be dynamic rendered eg live push, multiplayer games etc do full js rendering but do not use static html! only css/js. i think the complexity comes from web devs familiar with server rendering tries to use the same paradigm with dynamic sites for example angular and react. you should do it more like a desktop app instead of web page. if it makes sense do the rendering in canvas instead of the dom.

Re: In web design, everything easy is hard again

#137

Post by xtrapolate »

When I'm thinking about bloated web frameworks and inefficient libraries, I often come back to memories of 64k demos released by groups such as Farbrausch. Here's what they've pulled off in 2000: https://www.youtube.com/watch?v=Y3n3c_8Nn2Y - as somewhat of a "contrast", jQuery alone (3.0.0-alpha1, minified) weighs 84522 bytes.

Use (what you deem as) the right tool for the job. As to how we've got to where we are today, there are lots of reasons - but personally, I feel it's pointless to constantly talk about it. Whether things are more complex than they used to be is up for debate, it's entirely subjective.

It's natural for things to evolve given the rising popularity and increased demands - but they evolve organically. People flock to frameworks because there's abstraction, and the "dirty work" has been offloaded to a third-party. This saves people time and effort. It's a bet - frameworks come and go, maintainers disappear; that's just the nature of it.

Re: In web design, everything easy is hard again

#138

Post by hnzix »

kaoD wrote: post #131
hnzix wrote: post #81

Earlier quoted context omitted.

I've spent days tracking down a bug around a color picker widget, turns out JS was implicitly casting my string value to octal. I've worked with heaps of toy languages like Lingo, vbscript and ActionScript, and nothing has made me as viscerally angry as JavaScript (ok maybe PHP's complete lack of naming consistency). JS is an accident of history that has somehow become the de facto standard. I guess worse really is b…

> turns out JS was implicitly casting my string value to octal How exactly? I'm really curious. AFAIK it's pretty hard for a JS string to be casted into anything (pretty easy the other way around though). I guess maybe parseInt can do that, but that's neither casting not implicit.

Looks like it's been fixed in ES5. From memory I was performing an operation on a html color string and if you clicked a color with a certain prefix it would crash.

I could easily reproduce the bug but it took me forever to work out why JS was choking. I think I added in some ridiculous string padding to prevent the auto casting.

https://stackoverflow.com/questions/2547836/why-doesnt-an-oc...

Re: In web design, everything easy is hard again

#139

Post by jugularkill »

randomsearch wrote: post #9

This 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…

You said it. You're not an expert. You are comparing a prototype based language to oop languages. You're basically putting the wrong fuel in a car and blaming the car. You are lazy in my opinion because yes there are few resources that teach you how to use the language properly but plenty that compensate for those who want to make it familiar to back end devs. If you looked for good resources you will slowly discover that most JavaScript developers do not understand the language well because of the same assumptions you are making. It's a highly misunderstood language due to human stupidity.

Re: In web design, everything easy is hard again

#140

Post by yoodenvranx »

baq wrote: post #64
nawitus wrote: post #54

Earlier quoted context omitted.

Modern JavaScript is not a very badly designed programming language. It's a good, productive programming language. Most of the quirks can be disabled with a linter, and optionally a lot safety can be brought in with typing (using e.g. TypeScript). On the other hand, many developers don't know much about programming and JavaScript, and therefore tend to have unjustified criticism of the language. JavaScript was a perf…

this is all wrong, sorry. modern js is still js. the fact that linters are _required_ to keep code sane is proof enough. typescript is a different language, i'd wager it doesn't count, even though i agree it's a considerable improvement. au contraire, many developers know exactly what programming in js looks like, especially compared to other languages. i used to think that c++ and boost compilation was crazy. now i…

> wonder how we got there

I fully blame the virtually non-existant standard build- and module system in C/C++/JS for a lot of the current problems.

This is one of the reason I really want to learn Rust. Compared to make/npm/gulp its infrastructure looks heavenly.

Post reply on HN