3 ms·

What is curious is that the tech industry has been very conservative about rethinking these 6 things that you just listed. Why rows in a relational database? Wh

What is curious is that the tech industry has been very conservative about rethinking these 6 things that you just listed. Why rows in a relational database? Why objects? Why Javascript? And why HTML? We'd surely be in a better place if we got rid of these things and rethought our approach from first principles. I've written about these issues many times before. Regarding the problem with objects, I wrote "Object Oriented Programming Is An Expensive Disaster Which Must End": http://www.smashcompany.com/technology/object-oriented-programming-is-an-expensive-disaster-which-must-end http://www.smashcompany.com/technology/object-oriented-progr... Regarding the problems of HTML, I wrote "The problem with HTML": http://www.smashcompany.com/technology/the-problem-with-html http://www.smashcompany.com/technology/the-problem-with-html To answer the question "Why Is Front-End Development So Unstable?" the answer is surely, in part, the fact that we refuse to build technologies that are designed to be great front-end technologies.

tigershark 8y ago
There have been decades of attempts at databases with a different model than relational and we have seen what happened. The reality is that a relational model is very well suited for general purpose databases. For specific needs you can use timeseries databases or key/value store, but at this point I seriously doubt that the Nth attempt of killing the relational model will succeed. And honestly I prefer an enforced relational schema rather than an ungodly mess of schemaless documents.
Cthulhu_ 8y ago
There have been attempts at rethinking it though; noSQL was the buzzword of a couple of years ago, and even nowdays there's mature tools like Firebase that allow you to store and retrieve data much more directly than e.g. SQL. The challenge in nosql storage is of course data migrations and whatnot. But yeah, in theory you can just open up a MongoDB instance to your front-end and not have to bother with SQL or much of a back-end. And your last comment doesn't make much sense tbf; the big frameworks, most notably Angular and React (and its ecosystem) were both designed to be great front-end technologies.
- lkrubner 8y ago
  Angular and React both rely on Javascript and HTML, so you can't describe them as "designed to be great front-end technologies". HTML was designed for document exchange, it is a descendent of SGML. Javascript was initially meant to be a light weight scripting language that allowed dynamic elements in HTML. It's gotten better over the years, but it is still far from what you would expect if you were trying to build a great programming environment for the front end. As to the limits of HTML, just consider forms. In the last 20 years, there have been very few new form elements added. Compare the form elements available in HTML in 2018 to what VisualBasic 6 had achieved by 1999, or what Netbeans/Swing offered by 2003.
  - unclebucknasty 8y ago
    I've been saying the same for years. As long as we are working directly with HTML, we will have these impedance problems. The component/event model a la Swing et. al. is a far more elegant match for modern Web development, which is now essentially the same as building window-based native applications. OTOH, HTML was designed for static content delivery. Even if a framework must generate some HTML to remain compatible with browsers, there's no reason we have to work or think in HTML as our central interface model. Give me a canvas, let me lay out (and style) components, then let me respond to events.
  - emodendroket 8y ago
    > HTML was designed for document exchange, it is a descendent of SGML. Javascript was initially meant to be a light weight scripting language that allowed dynamic elements in HTML I always see people saying this, but why does it matter? Electricity was originally piped into homes for lighting, but we don't need an alternate way to power all the electric devices in our home. Unix was designed for computers that are quite different from the ones we use today. And so on.
    - lkrubner 8y ago
      I can't repeat all of my arguments in a comment on Hacker News. I would ask that you read what I wrote in "The Problem With HTML": http://www.smashcompany.com/technology/the-problem-with-html http://www.smashcompany.com/technology/the-problem-with-html
BjoernKW 8y ago
HTML is declarative if you use it that way. You can even use it as an API: https://bjoernkw.com/2018/05/20/html-is-an-api/ https://bjoernkw.com/2018/05/20/html-is-an-api/ HTML is a good compromise between procedural / event-based UI frameworks (such Java Swing or Apache Wicket) and visual UI design tools (such as RAD Studio, Apple's Interface Builder or Adobe Dreamweaver) that allow you to implement the most common patterns fairly easily while often making the design of more custom UIs much more difficult.
emodendroket 8y ago
I don't know what you're talking about. People keep trying to replace all of those things.
chrisco255 8y ago
HTML has lots of problems, but it's there, sitting on every computer and mobile phone that you can think of. There's not really another viable cross-platform alternative. Your only option would be to render to HTML5 canvas and create some alternative rendering model from the DOM (not unlike Flash). There are tools that exist to do that today (CreateJS, for example), but they're not mainstream. You pay a huge penalty by going against the standard platform. All the interop, tooling, and libraries out in the world work on HTML/JS. Re-inventing that from scratch and coming up with your own hacks/solutions for accessibility, responsive design, style sheets, components, etc, is expensive and unlikely to succeed. I agree that OOP is an expensive disaster...but thankfully JS is flexible enough to code using functional patterns.

tigershark 8y ago

There have been decades of attempts at databases with a different model than relational and we have seen what happened. The reality is that a relational model is very well suited for general purpose databases. For specific needs you can use timeseries databases or key/value store, but at this point I seriously doubt that the Nth attempt of killing the relational model will succeed. And honestly I prefer an enforced relational schema rather than an ungodly mess of schemaless documents.

Cthulhu_ 8y ago

There have been attempts at rethinking it though; noSQL was the buzzword of a couple of years ago, and even nowdays there's mature tools like Firebase that allow you to store and retrieve data much more directly than e.g. SQL. The challenge in nosql storage is of course data migrations and whatnot. But yeah, in theory you can just open up a MongoDB instance to your front-end and not have to bother with SQL or much of a back-end. And your last comment doesn't make much sense tbf; the big frameworks, most notably Angular and React (and its ecosystem) were both designed to be great front-end technologies.

lkrubner 8y ago
Angular and React both rely on Javascript and HTML, so you can't describe them as "designed to be great front-end technologies". HTML was designed for document exchange, it is a descendent of SGML. Javascript was initially meant to be a light weight scripting language that allowed dynamic elements in HTML. It's gotten better over the years, but it is still far from what you would expect if you were trying to build a great programming environment for the front end. As to the limits of HTML, just consider forms. In the last 20 years, there have been very few new form elements added. Compare the form elements available in HTML in 2018 to what VisualBasic 6 had achieved by 1999, or what Netbeans/Swing offered by 2003.
- unclebucknasty 8y ago
  I've been saying the same for years. As long as we are working directly with HTML, we will have these impedance problems. The component/event model a la Swing et. al. is a far more elegant match for modern Web development, which is now essentially the same as building window-based native applications. OTOH, HTML was designed for static content delivery. Even if a framework must generate some HTML to remain compatible with browsers, there's no reason we have to work or think in HTML as our central interface model. Give me a canvas, let me lay out (and style) components, then let me respond to events.
- emodendroket 8y ago
  > HTML was designed for document exchange, it is a descendent of SGML. Javascript was initially meant to be a light weight scripting language that allowed dynamic elements in HTML I always see people saying this, but why does it matter? Electricity was originally piped into homes for lighting, but we don't need an alternate way to power all the electric devices in our home. Unix was designed for computers that are quite different from the ones we use today. And so on.
  - lkrubner 8y ago
    I can't repeat all of my arguments in a comment on Hacker News. I would ask that you read what I wrote in "The Problem With HTML": http://www.smashcompany.com/technology/the-problem-with-html http://www.smashcompany.com/technology/the-problem-with-html

BjoernKW 8y ago

HTML is declarative if you use it that way. You can even use it as an API: https://bjoernkw.com/2018/05/20/html-is-an-api/ https://bjoernkw.com/2018/05/20/html-is-an-api/ HTML is a good compromise between procedural / event-based UI frameworks (such Java Swing or Apache Wicket) and visual UI design tools (such as RAD Studio, Apple's Interface Builder or Adobe Dreamweaver) that allow you to implement the most common patterns fairly easily while often making the design of more custom UIs much more difficult.

emodendroket 8y ago

I don't know what you're talking about. People keep trying to replace all of those things.

chrisco255 8y ago

HTML has lots of problems, but it's there, sitting on every computer and mobile phone that you can think of. There's not really another viable cross-platform alternative. Your only option would be to render to HTML5 canvas and create some alternative rendering model from the DOM (not unlike Flash). There are tools that exist to do that today (CreateJS, for example), but they're not mainstream. You pay a huge penalty by going against the standard platform. All the interop, tooling, and libraries out in the world work on HTML/JS. Re-inventing that from scratch and coming up with your own hacks/solutions for accessibility, responsive design, style sheets, components, etc, is expensive and unlikely to succeed. I agree that OOP is an expensive disaster...but thankfully JS is flexible enough to code using functional patterns.