8 ms·

If you look at the history of the web it's clear that the tendency has always been towards "shinier things". This "historic separation" was the result of techni

by simias 7y ago

If you look at the history of the web it's clear that the tendency has always been towards "shinier things". This "historic separation" was the result of technical limitations, see how popular Flash used to be for instance. HTML and CSS standards were always at least 10 years too late. If you wanted something that looked modern you've always had to use browser-specific extensions, plugins or, at best, "beta" features. Seriously, I know that nowadays many devs have started straight with web technologies and don't have a lot of experience besides that but if that's your case do yourself a favor and give a quick look at a proper UI toolkit like Qt. Would it blow your mind if I told you that you can create a complex treeview without having to use third-party libraries or reinventing half the wheel yourself? Crazy, I know. If anything this "historic separation" and people who still hold onto it might be one of the reasons the modern web is such a messy patchwork of technologies, if web engineers had accepted that an open source Flash was actually the endgame and not a problem we might have saved us some time and some trouble. To be clear I'm not saying that it's a bad idea per-se, I personally believe that the web is way too complicated as it is, I just feel like it's similar to arguing that "literally" shouldn't be used to mean "extremely" in modern English. Sure, I get your point, but I don't think it's a battle you can win.

Pete_D 7y ago
The change in dev culture worries me more than the change in technology. At least Flash sites used to be considered bad taste. Dare to grumble about something unnecessarily requiring gratuitous JS now, and you'll get berated as an out-of-touch Luddite who needs to shut up and get with the times.
- throwaway894345 7y ago
  My impression was the criticisms of flash stemmed from its security issues, it’s closed nature, it’s relative unfamiliarity (compared to popular languages of the time), and the nuisance that was making sure you had the right version running on your machine at any given time. Modern JavaScript addressed these issues, hence its popularity over Flash. This doesn’t endorse the gratuitous application of JS for fundamentally static content, but it sets the context for your perceived “shift in dev culture”.
  - als0 7y ago
    > Modern JavaScript addressed these issues, hence its popularity over Flash I think that while this is technically true, technical adequacy didn't lure developers away from Flash player. I believe that the real turning point was when Apple decided to break Adobe's monopoly on the web by disallowing Flash player on all their products.
    - throwaway894345 7y ago
      I agree that that was a turning point for usage, but we're discussing popularity among developers. Flash was unpopular among developers long before Apple banned it.
      - als0 7y ago
        Flash was on approximately 30% of websites before. It's hard to understand the argument that it was unpopular amongst devs.
        throwaway894345 7y ago
        Devs hated Flash for all of the reasons cited above, but browsers didn't support anything better for many use cases.
        ppseafield 7y ago
        Indeed. As an example for a long time you had to have Flash to play a video on your page. The HTML5 video support eventually ended the need for Flash to do this, but it came much later and very slowly became supported cross-browser.
    - jayflux 7y ago
      Although that event was a nail in the coffin, developers were moving away from flash long before Apple banned it.
  - pmontra 7y ago
- root_axis 7y ago
  By definition, everyone agrees that "gratuitous" use of JS is bad. You're glossing over the nuance of the debate which comes down to the specifics of when something is actually gratuitous.
  - salawat 7y ago
    You mean when the amount of JS you have to download eclipses the size of the original DOOM executable?
danShumway 7y ago
> Would it blow your mind if I told you that you can create a complex treeview without having to use third-party libraries No, not any more than C#'s giant standard library blows my mind. Keeping the web small is a strategic decision -- it may look like chaos, but it's really just that we realized that embracing 3rd-party libraries is a better architectural decision than polluting the core spec with features that will be outdated in a few years. QT doesn't have these problems because QT doesn't have to be infinitely backwards-compatible. If QT makes a mistake, it can fix it in the next version. The web can't do that, so we have to be more careful. If anything, my biggest criticism of the web is that we move too quickly and stick too many "modern" features in. I would have been happy to drop Classes and Arrow Functions from the JS spec, and I would have been happy to drop `sticky` from the CSS spec. As an engineer, I absolutely don't want a hamburger menu as a core HTML component. I've had people argue to me that HTML needs more 2-way data binding and element types -- they want the ability to tie a list to a JSON object or something, instead of needing to render out separate `<li>` elements. These people are missing the point. HTML is your user-presented state. We have a few elements that break this convention, but for the most part we want your final HTML to be static and human-readable. It's not for you, it's for your users. And 2-way data bindings would get in the way of that. For laying things out and creating complicated lists, we have third-party libraries/frameworks -- and honestly, they work fine. If you think the web is overcomplicated or has too many frameworks right now, just wait until we start stuffing a new first-party component into it every time any design trend becomes popular. And even if we did add all of that nonsense, people would just ignore those components anyway. No manager I've ever worked with has ever said to me, "you know, pure HTML select inputs look great and I don't mind them rendering differently in different browsers." I would be reimplementing them in JS anyway just to get the styling consistent between IE and Firefox. The good HTML components I can actually use are the low-level ones like simple input fields -- because they're small and simple enough that they can be styled and incorporated into larger custom-built solutions. Heck, I've had managers complain to me about scroll-bar styling before. But sure, they'd totally be happy with a giant, pre-built, monolithic tree-view component that's using mid-2000s styling.
- pier25 7y ago
  > These people are missing the point Maybe not. If data binding, dynamic markup, reactivity, etc, were baked into browser we'd save a ton of kbs and CPU cycles.
no_identd 7y ago
The reason behind 'the Web' resembling the mess unfortunately best exemplified by 'the Net' has a much simpler and trivial reason: We have globally networked local Networks of locally networkable Networks and most of us naively think that this Global Network of Local Networks networking Local Networks actually functions as a universally internetworking Internetwork of universally internetworkable Internetworks internetworking internetworkable Internetworks internetworking internetworkable Networks[([¹]1)], because we trust the people who've labeled both IPv4 and IPv6 as the "Internet Protocol" despite it not in any way, shape or form having the ability to perform what the people who came up with the concept of internetworking (no, NOT the ARPA people.) actually meant by the term.[2] As the simplest proof of this fact: We've almost reached 2020 and all of our 'solutions' for multi homing don't ACTUALLY work in a not-pants-on-head-dysfunctional despite the fact that we've faced that issue since, to quote Wikipedia, "In 1972, Tinker Air Force Base wanted connections to two different IMPs for redundancy. ARPANET designers realized that they couldn't support this feature because host addresses were the addresses of the IMP port number the host was connected to (borrowing from telephony)." Our 'Inter'net at the moment still resembles just a global network, aka just plain old phone calls, with extra steps. Which explains both the mess we call the WWW, and the global dominance of large telcos.Can't give an AS number and BGP access to just anyone[([²]4)] , as we know ever since L0pht Heavy Industries testified before the US Senate, over 2 decades ago, back in 1998.[3] NOTHING has fundamentally changed about this since. We've just written bigger and bigger macros ignorant of why we keep having to fight windmills & having to reinvent the wheel over and over again. [1 (¹ yes, I did intentionally phrase that in & as a reference to a certain Cisco exam question.)] [2 see https://news.ycombinator.com/item?id=21108796 https://news.ycombinator.com/item?id=21108796, but also see http://ict-arcfire.eu/index.php/rina/ http://ict-arcfire.eu/index.php/rina/ & http://ict-arcfire.eu/wp-content/uploads/2018/06/OCARINA-industryday.pdf http://ict-arcfire.eu/wp-content/uploads/2018/06/OCARINA-ind... ] [3 https://youtu.be/VVJldn_MmMY https://youtu.be/VVJldn_MmMY] [4 (² Of course, I don't advocate that we should. No. I do however argue that each of these situations shouldn't exist in the first place.)]
sproketboy 7y ago
> proper UI toolkit like JavaFX FTFA
jackewiehose 7y ago
> This "historic separation" was the result of technical limitations, see how popular Flash used to be for instance. I thought HTML was developed with HATEOAS in mind. So I don't see the seperation as a technical limitation but a powerful abstraction. Flash was what people wanted but HTML was what a good web needed (imagine the internet with only Flash/WebAsm from the beginning).
amw-zero 7y ago
You hit the nail on the head. At this point I’ve done about equal amounts of time building native apps and web apps. I’m very fortunate in that I don’t have to “pick a side” because I understand the strengths of both platforms and I try and learn from the strengths of both and apply that to whatever I’m working on. For example I’m a huge fan of the declarative UI trend going on in the web community. Now, granted, Microsoft came out with MVVM and XAML way before React or Angular existed, but native UI libraries are so historically imperative that declarative UI wasn’t making much of a dent in the native sphere. But even though these older native frameworks are imperative, they are much more powerful than anything like React out of the box. They’re much more comparable to component frameworks like Bootstrap, SemanticUI, AntD, etc. But even still, those libraries don’t come anywhere close to the power of Qt or UIKit in iOS. If you’ve used both, I can’t imagine you saying that it’s even close. But it’s precisely because of the tension between the web as a document platform vs. the web as an application platform. The web has never doubled down on being an application platform, it always keeps its document roots in the background in some way. Personally, I’m torn. I love the transparency and inspectability of the web. Literally yesterday I opened up the dev tools inn twitter and I learned about its timeline architecture just from inspecting the requests. This is the biggest thing I miss when I’m working on a native app. But WebAssembly may be the web finally doubling down on being an application platform. Whether that’s good or bad is irrelevant at this point. It’s the direction it’s headed in.
com2kid 7y ago
> Would it blow your mind if I told you that you can create a complex treeview without having to use third-party libraries or reinventing half the wheel yourself? Crazy QT is a third party library that wraps the underlying OS primitives. A really fancy tree view in JS is 10KB, maybe 15KB, given desktop+mobile support, proper accessibility, and good support for theming. And that is if you are getting really fancy. A simple one is just some DIVs and a CSS animation for opening and closing. That is assuming you even bother with JS, since you can do a treeview in the browser with CSS alone[1]. UI toolkits exist for the web as well, and they tend to be rather small, browsers ship with a lot of UI primitives after all! The UI portion of code for my B2B web-app with all custom UI elements and with mobile+desktop support is around 100KB unminified. Now the libraries I pull in to do the real time database streaming and authentication to my back end? Those dwarf the UI code (they are hundreds of KB each), but the native versions of those libraries are far larger (10x)[2], than the JavaScript equivalents. > Would it blow your mind if I told you that you can create a complex treeview without having to use third-party libraries or reinventing half the wheel yourself? The browser comes with a lot of wheels included, very few are getting re-invented unless someone wants indulge themself. > To be clear I'm not saying that it's a bad idea per-se, I personally believe that the web is way too complicated as it is Get rid of the weird things that happen to make advertising possible and most websites are pretty simple. Even complex web-apps are pretty easy to understand now days, though you'll have to learn whatever data-binding technique the dev team decided to use, but that is the same case for modern desktop applications. [1]https://codepen.io/kobusvanwykk/pen/NqXVNQ https://codepen.io/kobusvanwykk/pen/NqXVNQ [2]https://stackoverflow.com/questions/41750553/what-is-the-estimated-file-size-of-firebase-sdk https://stackoverflow.com/questions/41750553/what-is-the-est...
- numtel 7y ago
  For your #1 example, there is now the details and summary element that accomplish this too.
6gvONxR4sf7o 7y ago
I agree that the web is heading in a direction where it'll be easier to build cool websites. I think a possibly unintentional side effect of HTML as a base was that everything was hackable. It's like everything was open source and DRM free, whether you like it or not. I think this was probably a driver of the web becoming what it did. Imagine building pagerank when you can't scrape text or hyperlinks.

by simias 7y ago

Pete_D 7y ago

The change in dev culture worries me more than the change in technology. At least Flash sites used to be considered bad taste. Dare to grumble about something unnecessarily requiring gratuitous JS now, and you'll get berated as an out-of-touch Luddite who needs to shut up and get with the times.

throwaway894345 7y ago
My impression was the criticisms of flash stemmed from its security issues, it’s closed nature, it’s relative unfamiliarity (compared to popular languages of the time), and the nuisance that was making sure you had the right version running on your machine at any given time. Modern JavaScript addressed these issues, hence its popularity over Flash. This doesn’t endorse the gratuitous application of JS for fundamentally static content, but it sets the context for your perceived “shift in dev culture”.
- als0 7y ago
  > Modern JavaScript addressed these issues, hence its popularity over Flash I think that while this is technically true, technical adequacy didn't lure developers away from Flash player. I believe that the real turning point was when Apple decided to break Adobe's monopoly on the web by disallowing Flash player on all their products.
  - throwaway894345 7y ago
    I agree that that was a turning point for usage, but we're discussing popularity among developers. Flash was unpopular among developers long before Apple banned it.
    - als0 7y ago
      Flash was on approximately 30% of websites before. It's hard to understand the argument that it was unpopular amongst devs.
      - throwaway894345 7y ago
        Devs hated Flash for all of the reasons cited above, but browsers didn't support anything better for many use cases.
        ppseafield 7y ago
        Indeed. As an example for a long time you had to have Flash to play a video on your page. The HTML5 video support eventually ended the need for Flash to do this, but it came much later and very slowly became supported cross-browser.
  - jayflux 7y ago
    Although that event was a nail in the coffin, developers were moving away from flash long before Apple banned it.
- pmontra 7y ago
root_axis 7y ago
By definition, everyone agrees that "gratuitous" use of JS is bad. You're glossing over the nuance of the debate which comes down to the specifics of when something is actually gratuitous.
- salawat 7y ago
  You mean when the amount of JS you have to download eclipses the size of the original DOOM executable?

danShumway 7y ago

> Would it blow your mind if I told you that you can create a complex treeview without having to use third-party libraries No, not any more than C#'s giant standard library blows my mind. Keeping the web small is a strategic decision -- it may look like chaos, but it's really just that we realized that embracing 3rd-party libraries is a better architectural decision than polluting the core spec with features that will be outdated in a few years. QT doesn't have these problems because QT doesn't have to be infinitely backwards-compatible. If QT makes a mistake, it can fix it in the next version. The web can't do that, so we have to be more careful. If anything, my biggest criticism of the web is that we move too quickly and stick too many "modern" features in. I would have been happy to drop Classes and Arrow Functions from the JS spec, and I would have been happy to drop `sticky` from the CSS spec. As an engineer, I absolutely don't want a hamburger menu as a core HTML component. I've had people argue to me that HTML needs more 2-way data binding and element types -- they want the ability to tie a list to a JSON object or something, instead of needing to render out separate `<li>` elements. These people are missing the point. HTML is your user-presented state. We have a few elements that break this convention, but for the most part we want your final HTML to be static and human-readable. It's not for you, it's for your users. And 2-way data bindings would get in the way of that. For laying things out and creating complicated lists, we have third-party libraries/frameworks -- and honestly, they work fine. If you think the web is overcomplicated or has too many frameworks right now, just wait until we start stuffing a new first-party component into it every time any design trend becomes popular. And even if we did add all of that nonsense, people would just ignore those components anyway. No manager I've ever worked with has ever said to me, "you know, pure HTML select inputs look great and I don't mind them rendering differently in different browsers." I would be reimplementing them in JS anyway just to get the styling consistent between IE and Firefox. The good HTML components I can actually use are the low-level ones like simple input fields -- because they're small and simple enough that they can be styled and incorporated into larger custom-built solutions. Heck, I've had managers complain to me about scroll-bar styling before. But sure, they'd totally be happy with a giant, pre-built, monolithic tree-view component that's using mid-2000s styling.

pier25 7y ago
> These people are missing the point Maybe not. If data binding, dynamic markup, reactivity, etc, were baked into browser we'd save a ton of kbs and CPU cycles.

no_identd 7y ago

The reason behind 'the Web' resembling the mess unfortunately best exemplified by 'the Net' has a much simpler and trivial reason: We have globally networked local Networks of locally networkable Networks and most of us naively think that this Global Network of Local Networks networking Local Networks actually functions as a universally internetworking Internetwork of universally internetworkable Internetworks internetworking internetworkable Internetworks internetworking internetworkable Networks[([¹]1)], because we trust the people who've labeled both IPv4 and IPv6 as the "Internet Protocol" despite it not in any way, shape or form having the ability to perform what the people who came up with the concept of internetworking (no, NOT the ARPA people.) actually meant by the term.[2] As the simplest proof of this fact: We've almost reached 2020 and all of our 'solutions' for multi homing don't ACTUALLY work in a not-pants-on-head-dysfunctional despite the fact that we've faced that issue since, to quote Wikipedia, "In 1972, Tinker Air Force Base wanted connections to two different IMPs for redundancy. ARPANET designers realized that they couldn't support this feature because host addresses were the addresses of the IMP port number the host was connected to (borrowing from telephony)." Our 'Inter'net at the moment still resembles just a global network, aka just plain old phone calls, with extra steps. Which explains both the mess we call the WWW, and the global dominance of large telcos.Can't give an AS number and BGP access to just anyone[([²]4)] , as we know ever since L0pht Heavy Industries testified before the US Senate, over 2 decades ago, back in 1998.[3] NOTHING has fundamentally changed about this since. We've just written bigger and bigger macros ignorant of why we keep having to fight windmills & having to reinvent the wheel over and over again. [1 (¹ yes, I did intentionally phrase that in & as a reference to a certain Cisco exam question.)] [2 see https://news.ycombinator.com/item?id=21108796 https://news.ycombinator.com/item?id=21108796, but also see http://ict-arcfire.eu/index.php/rina/ http://ict-arcfire.eu/index.php/rina/ & http://ict-arcfire.eu/wp-content/uploads/2018/06/OCARINA-industryday.pdf http://ict-arcfire.eu/wp-content/uploads/2018/06/OCARINA-ind... ] [3 https://youtu.be/VVJldn_MmMY https://youtu.be/VVJldn_MmMY] [4 (² Of course, I don't advocate that we should. No. I do however argue that each of these situations shouldn't exist in the first place.)]

sproketboy 7y ago

> proper UI toolkit like JavaFX FTFA

jackewiehose 7y ago

> This "historic separation" was the result of technical limitations, see how popular Flash used to be for instance. I thought HTML was developed with HATEOAS in mind. So I don't see the seperation as a technical limitation but a powerful abstraction. Flash was what people wanted but HTML was what a good web needed (imagine the internet with only Flash/WebAsm from the beginning).

amw-zero 7y ago

You hit the nail on the head. At this point I’ve done about equal amounts of time building native apps and web apps. I’m very fortunate in that I don’t have to “pick a side” because I understand the strengths of both platforms and I try and learn from the strengths of both and apply that to whatever I’m working on. For example I’m a huge fan of the declarative UI trend going on in the web community. Now, granted, Microsoft came out with MVVM and XAML way before React or Angular existed, but native UI libraries are so historically imperative that declarative UI wasn’t making much of a dent in the native sphere. But even though these older native frameworks are imperative, they are much more powerful than anything like React out of the box. They’re much more comparable to component frameworks like Bootstrap, SemanticUI, AntD, etc. But even still, those libraries don’t come anywhere close to the power of Qt or UIKit in iOS. If you’ve used both, I can’t imagine you saying that it’s even close. But it’s precisely because of the tension between the web as a document platform vs. the web as an application platform. The web has never doubled down on being an application platform, it always keeps its document roots in the background in some way. Personally, I’m torn. I love the transparency and inspectability of the web. Literally yesterday I opened up the dev tools inn twitter and I learned about its timeline architecture just from inspecting the requests. This is the biggest thing I miss when I’m working on a native app. But WebAssembly may be the web finally doubling down on being an application platform. Whether that’s good or bad is irrelevant at this point. It’s the direction it’s headed in.

com2kid 7y ago

> Would it blow your mind if I told you that you can create a complex treeview without having to use third-party libraries or reinventing half the wheel yourself? Crazy QT is a third party library that wraps the underlying OS primitives. A really fancy tree view in JS is 10KB, maybe 15KB, given desktop+mobile support, proper accessibility, and good support for theming. And that is if you are getting really fancy. A simple one is just some DIVs and a CSS animation for opening and closing. That is assuming you even bother with JS, since you can do a treeview in the browser with CSS alone[1]. UI toolkits exist for the web as well, and they tend to be rather small, browsers ship with a lot of UI primitives after all! The UI portion of code for my B2B web-app with all custom UI elements and with mobile+desktop support is around 100KB unminified. Now the libraries I pull in to do the real time database streaming and authentication to my back end? Those dwarf the UI code (they are hundreds of KB each), but the native versions of those libraries are far larger (10x)[2], than the JavaScript equivalents. > Would it blow your mind if I told you that you can create a complex treeview without having to use third-party libraries or reinventing half the wheel yourself? The browser comes with a lot of wheels included, very few are getting re-invented unless someone wants indulge themself. > To be clear I'm not saying that it's a bad idea per-se, I personally believe that the web is way too complicated as it is Get rid of the weird things that happen to make advertising possible and most websites are pretty simple. Even complex web-apps are pretty easy to understand now days, though you'll have to learn whatever data-binding technique the dev team decided to use, but that is the same case for modern desktop applications. [1]https://codepen.io/kobusvanwykk/pen/NqXVNQ https://codepen.io/kobusvanwykk/pen/NqXVNQ [2]https://stackoverflow.com/questions/41750553/what-is-the-estimated-file-size-of-firebase-sdk https://stackoverflow.com/questions/41750553/what-is-the-est...

numtel 7y ago
For your #1 example, there is now the details and summary element that accomplish this too.

6gvONxR4sf7o 7y ago

I agree that the web is heading in a direction where it'll be easier to build cool websites. I think a possibly unintentional side effect of HTML as a base was that everything was hackable. It's like everything was open source and DRM free, whether you like it or not. I think this was probably a driver of the web becoming what it did. Imagine building pagerank when you can't scrape text or hyperlinks.