4 ms·

Seeing so many web frameworks come in and mostly fail over the years makes me wonder if there isn't a inherent problem to the web development environment that i

by hibikir 12y ago

Seeing so many web frameworks come in and mostly fail over the years makes me wonder if there isn't a inherent problem to the web development environment that is inherently harder than what we've dealt with native apps. People have been able to be quite productive writing apps in all kinds of all frameworks: Visual Basic, Swing, Delphi... not every framework has been well regarded, but many allowed inexperienced developers to write very interactive applications successfully. On the web, we have a whole lot more people, and they are not inherently worse than the ones that gave us those old frameworks. And yet, we have a billion little frameworks now that don't age very well, and don't really make us more productive than in the old days. I can't blame the framework developers, or the new application developers, so the problem must be further down. Is it the DOM? Is it Javascript itself? Is it the lack of strong components? I am not sure, but I sure wonder what makes web development such a problem.

noir_lord 12y ago
I think it's because the webs "ABI/API" is so broken and inconsistent. Delphi, Swing, Visual Basic all had fixed static targets (in the case of Delphi and VB, the Win32 API which had excellent backwards compatibility) in the case of Swing the JVM which is legendary for that. The web "ABI/API" is just broken by comparison, the primary language is a single threaded language that has much brain damage (controversial but I'll defend it) which isn't that surprising when it wasn't designed for what we are using it for (even nominally, insert joke about Win32 API as you please). The other issue is that because the web is so damn big it has massive inertia making it very difficult to get people to move to newer technologies, in my dream world the web would have a proper (not asm.js) secure VM in the browser that could be directly used, the "webby" bit that renders HTML/JS would just be an application in that vm and other stuff could directly target the underlying VM, can't see it ever happening though as it requires the browser vendors to simultaneously agree on supporting an open standard without screwing each other over and then sticking to it. That would be my dream web though.
- icebraining 12y ago
  As a user, your dream web is a bunch of closed blobs that I can't hope to shape or process in any way. Forget Ad-blocking, Greasemonkey scripts, Reddit Enhancement Suites or any kind of personalization not granted by the author. Changing a bit of a page becomes the equivalent of having to patch a binary instead of writing a couple of XPath expressions. Scraping changes from reading a DOM tag to extracting in-memory structures or in the limit having to do OCR. Give me the very flawed, but still much more open web any day.
  - noir_lord 12y ago
    That is a problem but the lack of a viable way to do native feeling apps on mobile devices has (I think) to a large extent driven walled garden app stores which are just as pernicious. It's not all roses in any case.
thom 12y ago
In a native client, global mutable state makes many problems straightforward to solve. The web takes that away, puts the state in a funny format in a database or a very limited session store. Even native apps that relied on remote databases still had to orchestrate a bunch of state around the UI, and that was vastly easier without the world resetting every time someone clicked a button, which is traditionally what happens on the web.
forgottenpass 12y ago
I sure wonder what makes web development such a problem. It's not any one bit, it's the fundamental design upon which it was all built. We're stuffing applications into a document viewer. A very good document viewer that has through the path of least resistance had more and more tacked on until it evolved into the terrible application VM we know it as today.
mattgreenrocks 12y ago
It's because the Web is a giant pile of hacks upon hacks. It is the ultimate manifestation of New Jersey design philosophy. Systems can only be as conceptually sound as their underpinnings allow. In this case, the broken design of the Web forces everything built on top of it to be a ridiculous mix of HTML/CSS/JS. Users not closing their tags? It's OK, we'll complicate the parser to accommodate them. Users want to interact with what should be static documents? No problem, we'll throw a scripting language in there. Users want to interact with hardware peripherals? OK, we'll just expose that. The real tragedy is how much of systems research has died at the hands of this crappy sentiment of Good Enough that pervades the Web. Literally everything the Web touches gets infected with Good Enough.
- 3pt14159 12y ago
  I upvoted you, but I disagree with you. The Web is built on a system of hacks, but those hacks are usually temporary and we can ultimately ignore most of them eventually. I was writing JavaScript back in '98, it is much easier now (and we have CoffeeScript to make it even easier!). Browser incompatibilities are slowly going away (and we have jQuery to make it even easier!). Things that used to be hard, like organizing an application to take keyboard input and respond to property changes, are now easy with things like Ember (and soon EmberUI will be out of alpha, and common things like searchable selects, buttons, date pickers, etc., will be easier) and other JS frameworks. I would reword it to "Good Enough For Now", because things do get fixed after the cool kids have kinda hacked around it for a while.
  - mattgreenrocks 12y ago
    Why should we have to hack around it? This is exactly the sort of defeatism and learned helplessness I was alluding to. We've accepted this crappy universal platform because it distributes software well. Despite being in a discipline where we can easily change the tools to work better for us, we just sit here and take it.
    - eric_h 12y ago
      We've accepted this crappy universal platform because it is universal. Replacing something that is used by literally Billions of people is decidedly non-trivial and takes _decades_.
frik 12y ago
* RAD (rapid application development) tools: Visual Basic and Delphi were tools with beginner friendly programming language. We had FrontPage and Dreamweaver to design earlier HTML4 frame & table based layouts. But there are no RAD tools to create modern CSS based web page designs. * Client only vs. client-server: Client-server web applications are a lot harder (software architecture), than Win32 client-only. * Consistent API: The WinAPI that was exposed through COM was easy to understand and more consistent than the HTML, JS, CSS that has grown over the years thanks to various vendor extensions/additions (Netscape, Microsoft, etc). * Documentation, books, articles in magazines (copy&paste examples): We used to have good API documentation and MSDN used to have a good relevant search (no C# API result if one search for C/C++ or VB API) and an index. Various magazines had really good articles with short example source code that one could type or copy&paste (web). Books shipped with a CD-Rom with a CHM file (earlier ebook format, Windows Help) that was similar to epub/mobi but the Windows Help viewer was far superior. * Common controls: Windows shell offers various common controls that are available in some form in VB, Delphi. The HTML standard still offers only very limited form controls. Were is the file list control, the menu bar control, etc?? Instead every website has come up with its own menu bar - thanks to DHTML movement. * APIs vs. Frameworks: In the Win32 world one used libraries (in form of DLLs) and its public API. In the web world one can do the same old fashion way by using C++ like languages like PHP with its hundreds libraries (exposes C API directly and optional object oriented boilerplate API) or the framework style (Ruby on Rails, etc., house of cards). If you know what you (and your team) is doing, you know what to choose in the long term anyway. -- Nevertheless, I kind of prefer the HTML5 web app world over the vendor-lockin yet again that is Android vs. iOS apps. And real Win32 development is uncommon lately. But I would like a innovative RAD tool, a next-gen FrontPage/Dreamweaver - something that made Visual Basic so easy to use.

by hibikir 12y ago

noir_lord 12y ago

I think it's because the webs "ABI/API" is so broken and inconsistent. Delphi, Swing, Visual Basic all had fixed static targets (in the case of Delphi and VB, the Win32 API which had excellent backwards compatibility) in the case of Swing the JVM which is legendary for that. The web "ABI/API" is just broken by comparison, the primary language is a single threaded language that has much brain damage (controversial but I'll defend it) which isn't that surprising when it wasn't designed for what we are using it for (even nominally, insert joke about Win32 API as you please). The other issue is that because the web is so damn big it has massive inertia making it very difficult to get people to move to newer technologies, in my dream world the web would have a proper (not asm.js) secure VM in the browser that could be directly used, the "webby" bit that renders HTML/JS would just be an application in that vm and other stuff could directly target the underlying VM, can't see it ever happening though as it requires the browser vendors to simultaneously agree on supporting an open standard without screwing each other over and then sticking to it. That would be my dream web though.

icebraining 12y ago
As a user, your dream web is a bunch of closed blobs that I can't hope to shape or process in any way. Forget Ad-blocking, Greasemonkey scripts, Reddit Enhancement Suites or any kind of personalization not granted by the author. Changing a bit of a page becomes the equivalent of having to patch a binary instead of writing a couple of XPath expressions. Scraping changes from reading a DOM tag to extracting in-memory structures or in the limit having to do OCR. Give me the very flawed, but still much more open web any day.
- noir_lord 12y ago
  That is a problem but the lack of a viable way to do native feeling apps on mobile devices has (I think) to a large extent driven walled garden app stores which are just as pernicious. It's not all roses in any case.

thom 12y ago

In a native client, global mutable state makes many problems straightforward to solve. The web takes that away, puts the state in a funny format in a database or a very limited session store. Even native apps that relied on remote databases still had to orchestrate a bunch of state around the UI, and that was vastly easier without the world resetting every time someone clicked a button, which is traditionally what happens on the web.

forgottenpass 12y ago

I sure wonder what makes web development such a problem. It's not any one bit, it's the fundamental design upon which it was all built. We're stuffing applications into a document viewer. A very good document viewer that has through the path of least resistance had more and more tacked on until it evolved into the terrible application VM we know it as today.

mattgreenrocks 12y ago

It's because the Web is a giant pile of hacks upon hacks. It is the ultimate manifestation of New Jersey design philosophy. Systems can only be as conceptually sound as their underpinnings allow. In this case, the broken design of the Web forces everything built on top of it to be a ridiculous mix of HTML/CSS/JS. Users not closing their tags? It's OK, we'll complicate the parser to accommodate them. Users want to interact with what should be static documents? No problem, we'll throw a scripting language in there. Users want to interact with hardware peripherals? OK, we'll just expose that. The real tragedy is how much of systems research has died at the hands of this crappy sentiment of Good Enough that pervades the Web. Literally everything the Web touches gets infected with Good Enough.

3pt14159 12y ago
I upvoted you, but I disagree with you. The Web is built on a system of hacks, but those hacks are usually temporary and we can ultimately ignore most of them eventually. I was writing JavaScript back in '98, it is much easier now (and we have CoffeeScript to make it even easier!). Browser incompatibilities are slowly going away (and we have jQuery to make it even easier!). Things that used to be hard, like organizing an application to take keyboard input and respond to property changes, are now easy with things like Ember (and soon EmberUI will be out of alpha, and common things like searchable selects, buttons, date pickers, etc., will be easier) and other JS frameworks. I would reword it to "Good Enough For Now", because things do get fixed after the cool kids have kinda hacked around it for a while.
- mattgreenrocks 12y ago
  Why should we have to hack around it? This is exactly the sort of defeatism and learned helplessness I was alluding to. We've accepted this crappy universal platform because it distributes software well. Despite being in a discipline where we can easily change the tools to work better for us, we just sit here and take it.
  - eric_h 12y ago
    We've accepted this crappy universal platform because it is universal. Replacing something that is used by literally Billions of people is decidedly non-trivial and takes _decades_.

frik 12y ago

* RAD (rapid application development) tools: Visual Basic and Delphi were tools with beginner friendly programming language. We had FrontPage and Dreamweaver to design earlier HTML4 frame & table based layouts. But there are no RAD tools to create modern CSS based web page designs. * Client only vs. client-server: Client-server web applications are a lot harder (software architecture), than Win32 client-only. * Consistent API: The WinAPI that was exposed through COM was easy to understand and more consistent than the HTML, JS, CSS that has grown over the years thanks to various vendor extensions/additions (Netscape, Microsoft, etc). * Documentation, books, articles in magazines (copy&paste examples): We used to have good API documentation and MSDN used to have a good relevant search (no C# API result if one search for C/C++ or VB API) and an index. Various magazines had really good articles with short example source code that one could type or copy&paste (web). Books shipped with a CD-Rom with a CHM file (earlier ebook format, Windows Help) that was similar to epub/mobi but the Windows Help viewer was far superior. * Common controls: Windows shell offers various common controls that are available in some form in VB, Delphi. The HTML standard still offers only very limited form controls. Were is the file list control, the menu bar control, etc?? Instead every website has come up with its own menu bar - thanks to DHTML movement. * APIs vs. Frameworks: In the Win32 world one used libraries (in form of DLLs) and its public API. In the web world one can do the same old fashion way by using C++ like languages like PHP with its hundreds libraries (exposes C API directly and optional object oriented boilerplate API) or the framework style (Ruby on Rails, etc., house of cards). If you know what you (and your team) is doing, you know what to choose in the long term anyway. -- Nevertheless, I kind of prefer the HTML5 web app world over the vendor-lockin yet again that is Android vs. iOS apps. And real Win32 development is uncommon lately. But I would like a innovative RAD tool, a next-gen FrontPage/Dreamweaver - something that made Visual Basic so easy to use.