6 ms·

Author seems to think the goal of SPAs was to simplify web dev, but it’s actually to allow you to build fully featured, highly interactive, apps in a browser.

Author seems to think the goal of SPAs was to simplify web dev, but it’s actually to allow you to build fully featured, highly interactive, apps in a browser. What the author is really getting at, I would guess, is that front end dev is awful, due to this weird combination of the Blub issue and a historical trajectory that has caused many problems. The blub issues is mostly simple enough to pin down. Experienced programmers know that JS is an awful language. But there’s also a tooling or SDK “blub problem”. For example, compare npm and webpack vs gradle and javac (not to defend the Java ecosystem, but it does get some things right, or more right than others). More idiosyncratically, there’s this historical arc of encountering fundamental problems, and trying to solve them within the current constraints of the web, rather than perhaps waiting for the web to standardise and evolve. This seems to be a mixture of lack of experience outside of this ecosystem (a bit like Blub) and, for this and other reasons, fixing problems “in your app” that should be fixed in the fundamental infrastructure of the web. It feels like technical solutions to social problems or, to use another metaphor, we are patching downstream what should be fixed upstream... if you build a house on sand, it will never be robust, no matter how many layers of infrastructure you add. That’s where the complexity arises. It’s an enlightening exercise to step back and ask how you would build SPA infrastructure if starting anew. You certainly wouldn’t use a language like JS, you certainly would want to provide visual design tools as far as possible, APIs would be replaced with standard protocols, and probably you’d use a relatively small XML for layout. So perhaps only the HTML is anything like what you’d use. There’d be no transpilation, no webpack, no polyfills, no CSS, no JS. In fact, what you’d end up with would look remarkably similar to the dev process for a Java applet!

TacoSteemers 6y ago
> not to defend the Java ecosystem, but it does get some things right, or more right than others Out of curiosity, as a Java enthusiast, I was wondering if you could give examples of what you feel is wrong? In my HN browsing I find Java is rarely actually discussed here, though often dismissed. I don't know why.
- rytill 6y ago
  For me, Java’s ties with Oracle and the nightmare stories about complicated `MetaAbstractBaseClassFactoryClassFactory` are why I seek alternatives, or would be dismissive.
  - grandinj 6y ago
    Just noting that the abstraction stuff is mostly a consequence of the CORBA-derived, over-engineered "Enterprise Java" space, and provided you stay out of that tar-pit, and choose your libraries/dependencies wisely, Java is really nice to work with. Even if you need to implement some kind of "Enterprise Java" app, you can do so with much better libraries and tools than back then, that do not suffer from the excessive abstraction problem.
    - BossingAround 6y ago
      I still see factories on a daily basis. They are a useful design pattern that is utilized in Java. My anecdotal evidence is that I have never seen the over-engineered "Enterprise Java horrors" OP is talking about despite working in the Java EE (now Jakarta EE) space. I suspect it's a story from the times of J2EE, or something similar.
      - lmm 6y ago
        > I still see factories on a daily basis. They are a useful design pattern that is utilized in Java. A separate factory type means you have to write twice as much code for no real benefit. In most languages you'd just use a first-class function (and in post-8 Java you can do the same: rather than a FooFactory you accept a Supplier<Foo> and people can pass ::Foo . It's still more cumbersome than in most languages though). Or, in a lot of other cases, the factory is just a clunky way to achieve named arguments. > My anecdotal evidence is that I have never seen the over-engineered "Enterprise Java horrors" OP is talking about despite working in the Java EE (now Jakarta EE) space. Have you worked on a reputable codebase in a low-overhead language like Python or Ruby? If you don't recognise factories as bloat then you may well miss the other cases (famously, the majority of the Gang of Four patterns can just be replaced by passing a function).
throwaway189262 6y ago
> In fact, what you’d end up with would look remarkably similar to the dev process for a Java applet! Yeah, it's increasingly clear to me that Java was just 20 years ahead of its time. Java really would make a great front end language. People lament the complexity and size of the JVM... But these days V8 is just as bad. The complexity is a trade-off for runtime performance. It's compiled into a compact easy to parse bitcode format similar to WASM. It's faster than JS and shares many basic design decisions. The packaging system is and always was basically a better version of NPM. It has pretty good cross-platform UI, probably the best there is outside of QT. WASM apps are eventually going to be built identically to Java cross-platform desktop apps. Probably using Java, Go, C#
- theshrike79 6y ago
  Not even Java applets, but Silverlight. Hoo boy it was awesome to work with. But. It came out at the wrong time. Linux was coming up as a desktop, MS was still evil. Mono was mostly a hobby project. The backlash of trying to use "proprietary M$ crap" for web was too big of a hurdle to cross, even if the technology behind Silverlight was lightyears ahead of the drek that was Java Applets.
- lmm 6y ago
  > Probably using Java, Go, C# I hope not. The world is finally waking up to the need for sum types. A big part of the reason Java is so hated for doing simple things in is that lacking sum types meant it had to implement a horrible "checked exception" system.
- jfengel 6y ago
  I feel like the mistake Java made was ceding the DOM to Javascript. It turned out that users like the browser and didn't particularly want either native widgets or a new system. The browser is familiar and good enough for a vast majority of tasks. If the JVM had access to the DOM, you could write SPAs in Java and everybody would be happy. Instead Java sealed itself off separately from the browser, and Javascript went from little toys to full-blown UI applications. And then developers wanted to use the same code on both client and server so they made Node, working in the space where Java is so much clearly better. So we end up with the worse language running the world. Fortunately, JS has finally become a mediocre language (or even a decent one with TS), and here we are.
deepstack 6y ago
>Author seems to think the goal of SPAs was to simplify web dev, but it’s actually to allow you to build fully featured, highly interactive, apps in a browser. Typical hipster web dev now days! Go back to the basic.
yoz-y 6y ago
> You certainly wouldn’t use a language like JS, I disagree with this. You might not want to use JS but a language “like” JS such as TS or Lua would definitely be on the table. Or just JS without the biggest warts. > you certainly would want to provide visual design tools as far as possible, I feel that the promise of visual design tools fell quite short. Issues with version control and general traceability of changes and the ultimate non feature parity with code make me think that code first interfaces are the future. > APIs would be replaced with standard protocols, Could you elaborate what do you mean? I assume REST apis but that is basically just HTTP. > and probably you’d use a relatively small XML for layout. As long as the language is robust enough to not move stuff around when the UI slightly changes. I feel that XML (and to an extent html) is too lax to express a programmatically created interface. > So perhaps only the HTML is anything like what you’d use. There’d be no transpilation, no webpack, no polyfills, no CSS, no JS. In a different world you could replace these steps by compilation, compiler, backwards compatibility libraries, a styling framework and a language of choice. I think you have shown that JS ecosystem has grown very organically. I think this is because the nature of web developers was to put stuff out rather than really think about how do make it the correct way. I believe this is because of constraints, on a native platform you had the option to go down to assembly or create a new language or paradigm. On web only the browser vendor has this power, all the dev had was JavaScript.
- lmm 6y ago
  > You might not want to use JS but a language “like” JS such as TS or Lua would definitely be on the table. Or just JS without the biggest warts. When you remove the warts from JS there's not much left. And I'd be pretty skeptical of someone starting a new project in Lua today. I think the mainstream choice for a "blank slate" language today would look something like Swift or Kotlin; Typescript can gets close, but it still has a lot of JavaScript baggage you'd want to strip out. > I feel that the promise of visual design tools fell quite short. Issues with version control and general traceability of changes and the ultimate non feature parity with code make me think that code first interfaces are the future. All the big UI libraries end up offering some kind of markup/constraint-based interface - which is ultimately data rather than code. And for editing that, a visual form designer makes a lot of sense. I like Qt's approach - you visually edit a markup form that's compiled into a class you can subclass, so you don't have to deal with the problems of code generation, and the markup is relatively version-control-friendly. > Could you elaborate what do you mean? I assume REST apis but that is basically just HTTP. I'm not the person you replied to, but thrift/gRPC are a lot nicer to work with than REST APIs. Standardised protocol definitions that let you understand what kind of changes are or aren't forward/backward compatible, and no need to write a bunch of boilerplate by hand. > I think you have shown that JS ecosystem has grown very organically. I think this is because the nature of web developers was to put stuff out rather than really think about how do make it the correct way. I believe this is because of constraints, on a native platform you had the option to go down to assembly or create a new language or paradigm. On web only the browser vendor has this power, all the dev had was JavaScript. It's the same story as "no-code" tools: IT departments won't let anyone install an application runtime, but they're happy to install a "document browser" and let it run arbitrary code. It's understandable, but depressing.
jhanschoo 6y ago
What's the blub problem?
- TacoSteemers 6y ago
  It is described here, specifically in the "The Blub Paradox" section: http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html My understanding is that everyone understands the features and ecosystem benefits of languages they work with, but not necessarily understands those of other languages. As a result, the value of their opinions on other languages may be mixed.
  - jhanschoo 6y ago
    Thanks!
glaucon 6y ago
What is a "blub issue". I tried a slang dictionary but couldn't find anything. Thanks.
- ndosnfiwjaijx 6y ago
  https://wiki.c2.com/?BlubParadox https://wiki.c2.com/?BlubParadox
- adamnew123456 6y ago
  https://wiki.c2.com/?BlubParadox https://wiki.c2.com/?BlubParadox The basic idea being that you know a tool that's obviously superior to a lot of alternatives, but you're blind to how different alternatives are superior to it because you can't grok the power beyond their initial "weirdness".
arcturus17 6y ago
> Experienced programmers know that JS is an awful language BS blanket statement. Some - many, maybe - programmers that in all likelihood multiply your experience and talent by orders of magnitude believe it's a great language. Not everyone working with JS is doing so with a gun to their heads.
- mercer 6y ago
  I don't know any polyglot programmers who would consider javascript better than at least one of the other languages they use, and would ditch js for those if they had the option. TypesScript, maybe.
  - arcturus17 6y ago
    Note how I didn't say that many polyglots may think it's the best language, just that it's great as opposed to awful. I know as a fact from watching tech conferences and talking to people that some elite-level polyglot programmers make it their main working language out of pure choice. Surely one can't assume that everyone doing bleeding-edge Javascript at places like Google is programming every day in absolute misery, or that it's the only thing that they know. Me personally, I've possibly enjoyed programming in C, OCaml, Swift or Python more at times, but I think ES6+ Javascript is great and I'm happy to use it. Javascript appears as the 11th most loved language in the SO dev surveys, with 66% of devs working with it reporting to love it, while it appears quite far down in the dreaded list. Typescript indeed fares much better. [1] Of course, there is the question of whether respondents are True Programmers™ or posers, but I think that's another debate. [1] https://insights.stackoverflow.com/survey/2019#most-loved-dreaded-and-wanted https://insights.stackoverflow.com/survey/2019#most-loved-dr...
    - mercer 6y ago
      > Note how I didn't say that many polyglots may think it's the best language, just that it's great as opposed to awful. Fair enough :). I think 'great' is a bit of a vague concept, but I definitely would agree that it's far from awful. I remember when I wrote a lot of JS back in the day ("Javascript: The Good Parts"), I did feel that stripped from the bad parts, I often preferred the elegance of the basic good parts over, say, Ruby and its "blocks, procs and lambda's" (for example).

TacoSteemers 6y ago

> not to defend the Java ecosystem, but it does get some things right, or more right than others Out of curiosity, as a Java enthusiast, I was wondering if you could give examples of what you feel is wrong? In my HN browsing I find Java is rarely actually discussed here, though often dismissed. I don't know why.

rytill 6y ago
For me, Java’s ties with Oracle and the nightmare stories about complicated `MetaAbstractBaseClassFactoryClassFactory` are why I seek alternatives, or would be dismissive.
- grandinj 6y ago
  Just noting that the abstraction stuff is mostly a consequence of the CORBA-derived, over-engineered "Enterprise Java" space, and provided you stay out of that tar-pit, and choose your libraries/dependencies wisely, Java is really nice to work with. Even if you need to implement some kind of "Enterprise Java" app, you can do so with much better libraries and tools than back then, that do not suffer from the excessive abstraction problem.
  - BossingAround 6y ago
    I still see factories on a daily basis. They are a useful design pattern that is utilized in Java. My anecdotal evidence is that I have never seen the over-engineered "Enterprise Java horrors" OP is talking about despite working in the Java EE (now Jakarta EE) space. I suspect it's a story from the times of J2EE, or something similar.
    - lmm 6y ago
      > I still see factories on a daily basis. They are a useful design pattern that is utilized in Java. A separate factory type means you have to write twice as much code for no real benefit. In most languages you'd just use a first-class function (and in post-8 Java you can do the same: rather than a FooFactory you accept a Supplier<Foo> and people can pass ::Foo . It's still more cumbersome than in most languages though). Or, in a lot of other cases, the factory is just a clunky way to achieve named arguments. > My anecdotal evidence is that I have never seen the over-engineered "Enterprise Java horrors" OP is talking about despite working in the Java EE (now Jakarta EE) space. Have you worked on a reputable codebase in a low-overhead language like Python or Ruby? If you don't recognise factories as bloat then you may well miss the other cases (famously, the majority of the Gang of Four patterns can just be replaced by passing a function).

throwaway189262 6y ago

> In fact, what you’d end up with would look remarkably similar to the dev process for a Java applet! Yeah, it's increasingly clear to me that Java was just 20 years ahead of its time. Java really would make a great front end language. People lament the complexity and size of the JVM... But these days V8 is just as bad. The complexity is a trade-off for runtime performance. It's compiled into a compact easy to parse bitcode format similar to WASM. It's faster than JS and shares many basic design decisions. The packaging system is and always was basically a better version of NPM. It has pretty good cross-platform UI, probably the best there is outside of QT. WASM apps are eventually going to be built identically to Java cross-platform desktop apps. Probably using Java, Go, C#

theshrike79 6y ago
Not even Java applets, but Silverlight. Hoo boy it was awesome to work with. But. It came out at the wrong time. Linux was coming up as a desktop, MS was still evil. Mono was mostly a hobby project. The backlash of trying to use "proprietary M$ crap" for web was too big of a hurdle to cross, even if the technology behind Silverlight was lightyears ahead of the drek that was Java Applets.
lmm 6y ago
> Probably using Java, Go, C# I hope not. The world is finally waking up to the need for sum types. A big part of the reason Java is so hated for doing simple things in is that lacking sum types meant it had to implement a horrible "checked exception" system.
jfengel 6y ago
I feel like the mistake Java made was ceding the DOM to Javascript. It turned out that users like the browser and didn't particularly want either native widgets or a new system. The browser is familiar and good enough for a vast majority of tasks. If the JVM had access to the DOM, you could write SPAs in Java and everybody would be happy. Instead Java sealed itself off separately from the browser, and Javascript went from little toys to full-blown UI applications. And then developers wanted to use the same code on both client and server so they made Node, working in the space where Java is so much clearly better. So we end up with the worse language running the world. Fortunately, JS has finally become a mediocre language (or even a decent one with TS), and here we are.

deepstack 6y ago

>Author seems to think the goal of SPAs was to simplify web dev, but it’s actually to allow you to build fully featured, highly interactive, apps in a browser. Typical hipster web dev now days! Go back to the basic.

yoz-y 6y ago

> You certainly wouldn’t use a language like JS, I disagree with this. You might not want to use JS but a language “like” JS such as TS or Lua would definitely be on the table. Or just JS without the biggest warts. > you certainly would want to provide visual design tools as far as possible, I feel that the promise of visual design tools fell quite short. Issues with version control and general traceability of changes and the ultimate non feature parity with code make me think that code first interfaces are the future. > APIs would be replaced with standard protocols, Could you elaborate what do you mean? I assume REST apis but that is basically just HTTP. > and probably you’d use a relatively small XML for layout. As long as the language is robust enough to not move stuff around when the UI slightly changes. I feel that XML (and to an extent html) is too lax to express a programmatically created interface. > So perhaps only the HTML is anything like what you’d use. There’d be no transpilation, no webpack, no polyfills, no CSS, no JS. In a different world you could replace these steps by compilation, compiler, backwards compatibility libraries, a styling framework and a language of choice. I think you have shown that JS ecosystem has grown very organically. I think this is because the nature of web developers was to put stuff out rather than really think about how do make it the correct way. I believe this is because of constraints, on a native platform you had the option to go down to assembly or create a new language or paradigm. On web only the browser vendor has this power, all the dev had was JavaScript.

lmm 6y ago
> You might not want to use JS but a language “like” JS such as TS or Lua would definitely be on the table. Or just JS without the biggest warts. When you remove the warts from JS there's not much left. And I'd be pretty skeptical of someone starting a new project in Lua today. I think the mainstream choice for a "blank slate" language today would look something like Swift or Kotlin; Typescript can gets close, but it still has a lot of JavaScript baggage you'd want to strip out. > I feel that the promise of visual design tools fell quite short. Issues with version control and general traceability of changes and the ultimate non feature parity with code make me think that code first interfaces are the future. All the big UI libraries end up offering some kind of markup/constraint-based interface - which is ultimately data rather than code. And for editing that, a visual form designer makes a lot of sense. I like Qt's approach - you visually edit a markup form that's compiled into a class you can subclass, so you don't have to deal with the problems of code generation, and the markup is relatively version-control-friendly. > Could you elaborate what do you mean? I assume REST apis but that is basically just HTTP. I'm not the person you replied to, but thrift/gRPC are a lot nicer to work with than REST APIs. Standardised protocol definitions that let you understand what kind of changes are or aren't forward/backward compatible, and no need to write a bunch of boilerplate by hand. > I think you have shown that JS ecosystem has grown very organically. I think this is because the nature of web developers was to put stuff out rather than really think about how do make it the correct way. I believe this is because of constraints, on a native platform you had the option to go down to assembly or create a new language or paradigm. On web only the browser vendor has this power, all the dev had was JavaScript. It's the same story as "no-code" tools: IT departments won't let anyone install an application runtime, but they're happy to install a "document browser" and let it run arbitrary code. It's understandable, but depressing.

jhanschoo 6y ago

What's the blub problem?

TacoSteemers 6y ago
It is described here, specifically in the "The Blub Paradox" section: http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html My understanding is that everyone understands the features and ecosystem benefits of languages they work with, but not necessarily understands those of other languages. As a result, the value of their opinions on other languages may be mixed.
- jhanschoo 6y ago
  Thanks!

glaucon 6y ago

What is a "blub issue". I tried a slang dictionary but couldn't find anything. Thanks.

ndosnfiwjaijx 6y ago
https://wiki.c2.com/?BlubParadox https://wiki.c2.com/?BlubParadox
adamnew123456 6y ago
https://wiki.c2.com/?BlubParadox https://wiki.c2.com/?BlubParadox The basic idea being that you know a tool that's obviously superior to a lot of alternatives, but you're blind to how different alternatives are superior to it because you can't grok the power beyond their initial "weirdness".

arcturus17 6y ago

> Experienced programmers know that JS is an awful language BS blanket statement. Some - many, maybe - programmers that in all likelihood multiply your experience and talent by orders of magnitude believe it's a great language. Not everyone working with JS is doing so with a gun to their heads.

mercer 6y ago
I don't know any polyglot programmers who would consider javascript better than at least one of the other languages they use, and would ditch js for those if they had the option. TypesScript, maybe.
- arcturus17 6y ago
  Note how I didn't say that many polyglots may think it's the best language, just that it's great as opposed to awful. I know as a fact from watching tech conferences and talking to people that some elite-level polyglot programmers make it their main working language out of pure choice. Surely one can't assume that everyone doing bleeding-edge Javascript at places like Google is programming every day in absolute misery, or that it's the only thing that they know. Me personally, I've possibly enjoyed programming in C, OCaml, Swift or Python more at times, but I think ES6+ Javascript is great and I'm happy to use it. Javascript appears as the 11th most loved language in the SO dev surveys, with 66% of devs working with it reporting to love it, while it appears quite far down in the dreaded list. Typescript indeed fares much better. [1] Of course, there is the question of whether respondents are True Programmers™ or posers, but I think that's another debate. [1] https://insights.stackoverflow.com/survey/2019#most-loved-dreaded-and-wanted https://insights.stackoverflow.com/survey/2019#most-loved-dr...
  - mercer 6y ago
    > Note how I didn't say that many polyglots may think it's the best language, just that it's great as opposed to awful. Fair enough :). I think 'great' is a bit of a vague concept, but I definitely would agree that it's far from awful. I remember when I wrote a lot of JS back in the day ("Javascript: The Good Parts"), I did feel that stripped from the bad parts, I often preferred the elegance of the basic good parts over, say, Ruby and its "blocks, procs and lambda's" (for example).