12 ms·

If anything, this understates the problem. A modal web application today takes an absolute minimum of five programming languages and three frameworks: * HT

If anything, this understates the problem. A modal web application today takes an absolute minimum of five programming languages and three frameworks: * HTML * CSS * JS * A server-side language (eg Python) * SQL And then come the (leaky) abstractions on top of them: * A framework to make JS bearable (eg Angular) * A framework to make server-side bearable (eg Django) * A framework to make CSS bearable (eg Bootstrap) ...and often... * A framework to make SQL bearable (eg SQLAlchemy...) When someone asks me how to learn to build web apps - even someone who can already program a bit - I feel embarrassed explaining to them what a pile of patches the Web is. Even if the languages themselves were saner, this is a monstrous amount of complexity for something that takes one language and a drag'n'drop GUI builder on any other platform. Trying to fix this, at least for simple apps, is why we built Anvil - https://anvil.works https://anvil.works - where everything is in Python, and the GUI is drag'n'drop.

erlich 10y ago
You can literally use Javascript for all of this.
- meredydd 10y ago
  I think you may be misunderstanding my point. If you have to invoke a brand new JS framework with limited uptake and many competitors, and "one of a million" CSS frameworks, in order to declare this problem solved, you are perpetuating the problem. I don't want to knock these tools too hard, because I can readily believe that (eg) Flow, or Typescript, or whatever we'll all be using next week, is much better than using vanilla JS/CSS. But the fact that we need to know all of Flow, and all of JS, and all of bootstrap, and all of CSS, and we're still not even off the client yet, is exactly why the web is a mess.
  - erlich 10y ago
    My thinking on this is that everytime someone has tried to unify these tools it hasn't gone well. Think about Google Web Toolkit, or Microsoft's XAML. It's better to have everyone experimenting, blogging and doing their thing, and the best ideas rise to the top. 2015 was probably the worst time to be a web developer on a greenfield project. You had Angular deprecation and the Flux wars, and Babel 5 -> 6 migration. I do agree its a mess and a freaking nightmare most of the time. I've spent hundreds of hours setting my toolchain up and if something like webpack were to lose favour, I would be devastated. I think we are in need of a Rails for modern JS. My prediction is that we will see this emerge soon. A shift from project-templates to simple, generic plugin system. Webpack seems quite strong as the packager. Angular 2 CLI just migrated to webpack from Brocolli for example. React and Redux are standard now. And npm is the package manager of choice.
    - rpeden 10y ago
      Did GWT or XAML really try to unify things? Back in 2009, I worked on a complex SPA using GWT. With GWT, you could pretend to know nothing about HTML/CSS by just using the ugly build in components, but none of the GWT users I met did that. Our app used a Model-View-Presenter structure, dependency injection, and event bus for asynchronous communication to let components know when their data had updated, plus UIBinder templates for defining the look of components (which are mostly just HTML and CSS). So although it was nicely structured, it was very much a web app, and the development experience felt pretty comparable to what I experience in React today. XAML is mostly just a way to declaratively specify the layout and structure of UI components. Actually, I think it's just a declarative syntax for creating a hierarchy of object instances. If I remember correctly, the XAML and its corresponding C# file are both partial implementations of the same class, since .NET allows partial classes. Now, I'm not saying that I think the current state of JavaScript tooling is the worst thing ever. But I do think that that some of the 2009-2010 era JavaScript frameworks provided a more sane and cohesive development experience. React and Angular are nice, but I also remember that in 2010 it felt pretty neat to create an interface in OSX's Interface Builder, and have it show up in my browser exactly the way I'd drawn it.
      - erlich 10y ago
        The point I'm making is that when people have tried to develop a UI framework in a single language from scratch and offer the same functionality as the web, they fail. Performance sucks, or its not flexible enough to deliver certain functionality. By XAML I guess I mean WPF or whatever it is called. The bet was that Silverlight would be installed in every browser and you could build more powerful apps. I remember reading a post about how Evernote rewrote their WPF app because performance was never good enough. GWT tried to make a nicer API for building UIs. The API was nice, but I guess the whole transpilation caused issues with debugging etc. --- HTML, JS, CSS is evolving in such unpredictable ways, each time getting better and better. It just has such a large community using it and experimenting with it all the time - I don't think anyone can compete with the hive mind of web devs.
- chx 10y ago
  That leads to the MEAN stack (Mongo, Express, Angular, Node) and I am not so sure whether that's where the rosy future is.
  - unclebucknasty 10y ago
    Exactly. Intuitively, I don't think the problem can be solved with the same "let's glue together a bunch of stuff and call it a stack" approach that got us here.
    - erlich 10y ago
      I'm hoping it is. We have ended up with really good tools compared to what we had before. Think about using commonjs requires, compared to the craziness of the Rails asset pipeline and sprockets, or manually specifying js files. We just need to standardize the glue...
      - unclebucknasty 10y ago
        Better bad is not the same as good. The approach itself yielded the issues such as that you reference, which have only been partially resolved by subsequent iterations of the same approach. I don't believe we should give credit for an approach that yields what is still a net-negative. It's a new thinking that we need, not reluctant acceptance of the best sub optimal execution the old thinking can deliver.
      - rpeden 10y ago
        The best part will be when we're all standardized on ES2015 modules instead of commonJS modules. I agree with you that CommonJS requires are nice to use, but since they're not statically analyzable the way ES2015 imports are, optimizing compilers like the Closure Compiler can't really analyze your entire application, including its dependencies. Once we've completely made the ES2015 transition (at least for front end modules), we might be in a position to see some really great front end tooling.
        10y ago
- deleted 10y ago
  [deleted]
9point6 10y ago
I think your use of "minimum" is wrong here. If you're using React running on Node and Webpack as your task-runner you just need Javascript and that's it. Node allows you to run isomorphic JavaScript that runs on both your server side and client side (to ensure you don't end up with the Angular-style skeleton pages coming from the server), You can pick a nice ORM (like sequelize) to abstract away SQL, and Webpack allows modules to specify their styles in JavaScript to allow compossible CSS for each given page. Yes this is still using a couple of frameworks, but I personally prefer the approach of a lightweight standard library to the everything-and-the-kitchen-sink approach that other languages have.
- meredydd 10y ago
  I still count three frameworks :) (React, Node, sequelize, I'm not counting webpack but I probably would if it's anything like as much of a pain as Grunt or Gulp or... And as you say, this is the lightweight version.)
  - 9point6 10y ago
    Ah I wouldn't count Node as a framework as I'd equate it to the JVM in Java world. But you are right, I'd probably lump webpack in there as it does have a fair bit of depth to it if you want to get the most out of it.
    - aclsid 10y ago
      You still need to use Express or something similar on the server side for Javascript, I mean, if we are talking about standard procedures here. Plus with React, you are still doing that Javascript/CSS thingy and HTML of course at some point, so there is no avoiding that, and clearfixes, polyfills, etc, etc.
      - tracker1 10y ago
        But all of these things you're bitching about combined are far smaller than even ASP.Net without including anything client-side.
sesutton 10y ago
HTML, CSS and SQL aren't programming languages, if Turing completeness is a requirement to be a programming language.
- coldpie 10y ago
  This is a language lawyer nit-pick comment that doesn't add anything to the discussion.
- throwaway729 10y ago
  > if Turing completeness is a requirement to be a programming language Many languages (in the formal sense) aren't Turing complete, so this certainly isn't a requirement to be a formal language. It would be odd to come up with a definition of language that excludes regular languages, for example. TBF you did say "programming language", not just "language". But once we move from the mathematical setting of formal languages into the informal engineering setting of programming languages, I don't see why a formal concept such as Turing completeness should be the deciding criterion for what constitutes a programming language. I think a more reasonable criterion is that a programming language needs to have at least 1) a syntax; 2) a semantics or an implementation that could, with enough effort, be given a semantics; and 3) whose primary use is giving instructions to some computational machine (Turing or otherwise). According to this criterion, SQL is certainly a language. If you think about it for a moment, HTML and CSS are perfectly reasonable languages as well. Their semantics, however hairy, would be given for instance terms of manipulating objects in R^2.
  - Bartweiss 10y ago
    This seems like a great place to observe that Magic The Gathering is Turing-complete. If your requirements suggest that MTG is a programming language, but HTML isn't, they're probably bad requirements. The syntax/semantics/instructions option seems like a way better basis. And honestly, most of us can get by with a Potter Stewart style standard of "know it when I see it".
- mirages 10y ago
  HTML + CSS seems to be Turing complete : http://lemire.me/blog/2011/03/08/breaking-news-htmlcss-is-turing-complete/ http://lemire.me/blog/2011/03/08/breaking-news-htmlcss-is-tu... As does SQL : http://stackoverflow.com/questions/900055/is-sql-or-even-tsql-turing-complete http://stackoverflow.com/questions/900055/is-sql-or-even-tsq...
contingencies 10y ago
You forgot something for the mobile strategy, something for web stats, something for monitoring, something for source control, something for issue management, something which shall remain nameless for team communication that breaks store and forward and interrupts you constantly, something for 'social', etc. Oh wait, and your infrastructure automation solution. And your third party DDoS protection/web cache integration... and all of this is TRULY NORMAL. We are underpaid.
- douche 10y ago
  You forgot containers, and a platform for orchestrating(?) or swarming or cat-herding or whatever it is one does with a gaggle of microservices.
- vram22 10y ago
  You forgot integrating all of that, keeping it integrated (aka working) as versions of pieces change, and debugging it all.
Bartweiss 10y ago
"A framework to make Foo bearable" seems like a huge portion of the issue here. We have a bunch of tools so hideously unfriendly to everyday development that we have to pile framework on framework in an attempt to actually get something built in a timely manner. And the result, of course, is an unmaintainable stack of dependencies and inefficiencies. Any time anything changes, anywhere, the whole thing falls apart again. Security folks talk about "threat surface" - I wonder if it would help to have an idea of "development surface" to signify the risks of bloat and dependency chaining?
jackhack 10y ago
Good post which jogged a memory for me, HN discussed this very thing 7.5 years ago: five languages in 7 lines of code -- how now to do web development : https://news.ycombinator.com/item?id=492321 https://news.ycombinator.com/item?id=492321
- tantalor 10y ago
  That doc is broken.
sheriffderek 10y ago
I would exclude the 3rd framework. You do not need or want to use a CSS framework if you actually understand and have experience writing CSS.
- sheriffderek 10y ago
  Whenever I hear this argument, I think of those guys out there on the freeway laying asphalt in the middle of the night. Or those people who are dead - inside the dam's cement. They probably wish they didn't have to use tools or try new techniques or combine skills and continue to learn new ways of building complex structures. They probably wish things didn't go wrong. They probably wish there was a task manager that just put all the dirt into the wheelbarrow and rolled it where it needed to go. As we move to a computer-based way of building things, it seems that we have already become spoiled and self-deserving. It seems like most 'developers' took a "rails for zombies" tutorial and are angry that things aren't as easy as that. That's why front-end developers get paid 4 times a much as most people / to make crappy software for other developers to track their time or catalog their toys or rants with their friends about how much they hate programming. I think everyone who doesn't like writing code, should get a job on a contractor's team for a summer - if they'll have you. Then while you are thinking about how much that job sucks, dream up a new box-model CSS type thing and be the hero.
clifanatic 10y ago
... and usually ... Five or six competing frameworks that do the same thing in different, incompatible ways, because either the guy who understood EXT-JS left the company or one group like jQuery better than DOJO and they both went off to do their own things only to be brought back together later.
cosinetau 10y ago
I remember being warned about engineers that get used to using frameworks too often. Their ability to work outside of it eventually suffers. We might need less abstraction, and let the engineers work that out.
- tracker1 10y ago
  LOL, all of the frameworks mentioned, even express are pretty light abstractions... that said, I feel angular, as an example goes TOO far.. way too far. These days, I hesitate to even use lodash, let alone jquery or larger bits. Though I'll still bring in moment if I have to deal with a lot of date/time logic and formatting (hate the size of it though).
- joesmo 10y ago
  Yeah, I'm all up for writing everything in machine language using punch cards. Anything else is clearly too much abstraction and obviously a sign of bad engineers.
  - dllthomas 10y ago
    Cards? No, you need to feel the bits, inputting them with manual switches.
tracker1 10y ago
OR... * JavaScript (client and server) * Redux (state management) * React (UI Control framework) * MaterialUI Controls (toolkit, one of many) * JS Friendly DB With a database that has a native adapter such as RethinkDB (or Mongo if you really want it), it's really transparent.
BinaryIdiot 10y ago
> If anything, this understates the problem. A modal web application today takes an absolute minimum of five programming languages If you're going to call HTML a programming language than when you talk about server-side work you must include XML as a programming language (I see markup far different, more simplistic than a programming language). CSS is simply properties applied to the same markup but I digress; I could see the argument argued either way. Regardless, you can minimize what you're saying down to just HTML, CSS and a server-side language. You can make good applications without a single line of JavaScript and depending on your purpose you may not need persistent storage in the backend. In fact you can write an entire web application with just HTML, CSS and JS if you want and have no backend (beyond a CDN unless you want to be super pedantic and call that a "backend" but I think that would exceptionally overstate what it does). > And then come the (leaky) abstractions on top of them: God, you don't need any of these. JS isn't that bad anymore. It's actually kinda nice in some ways. Same with CSS it's rather easy and there are far lighter projects than bootstrap if you want to do minimal stuff, quickly (but there isn't any reason you can't look at tutorials if you're new and get a CSS layout working pretty quickly sans framework). For server side this depends on your language. Node has a great built in http capability that many seem to ignore (it's quite easy to write your own web server using it; in fact it doesn't take much more code than plugging into express or hapi). Alternatively other languages have even better, built-in ways of handling server-side logic. > ...and often... Ugh, SQL is so easy I don't understand why people even bother with these. Every single time I've been involved in a team that used these abstractions it worked great initially and then steered us off a cliff in the end. Just don't. RDMS is easy.
- meredydd 10y ago
  > If you're going to call HTML a programming language [...] CSS is simply properties [...] Whatever they are, they're complicated. They've each got syntax, enormous sets of tags/keywords to learn, and quirks coming out of their ears. There are even people down-thread pointing out that HTML+CSS is Turing complete. > God, you don't need any of these [abstractions] With respect, almost everyone else in this thread seems to disagree with you. I'd challenge you to find a major public-facing web app written with - let's be charitable - fewer than two of the frameworks on that list. I do tend to agree with you on the merits of SQL, though. We built a very simple database for Anvil, that doesn't do anything except store and retrieve tuples of data, and for anything more complicated, we say "great, SQL is over there" :-P
ohgh1ieD 10y ago
What you basically do, is hiding and abstracting facts. That comes at a cost, namely when someone has a special requirement, then that person has to dig very deep into your framework. It's almost the same like Java GWT or Vaddin. If you stick to the recommended way, everything is just fine, but don't ever try to solve some exceptional problem because then you are in a world of pain where it's just smarter to embrace JS and CSS. The problem is, abstracting things away doesn't make them disappear, because WEB DEVELOPMENT IS BROKEN BY DESIGN. I never used your app nor do I know how it behaves, this is just general speaking about the scenario when people try to 'abstract' things away, I hope you understand that I'm not speaking about your app but the idea of hiding things. The sames goes for all those frameworks who tried to hide HTTP ( I'm looking at you asp.net and some older Java frameworks ), this lead to a pile of shit, newer frameworks accept the fact that we use HTTP and we got less problems by doing that. Since you mentioned ORM's, it's called the Vietnam of computer science[0], everyone tries to hide SQL, if you are doing some basic CRUD applications everything is fine but if you need more sophisticated queries you are already fighting the ORM which is supposed to help you and not making you developer life miserable, we don't need another DSL for databases, SQL is already the best language to make queries. I guess, what I'm trying to point out here is that I use those simple tools because I know my way around, I know how to debug it which wouldn't be possible with some abstraction. [0] https://blog.codinghorror.com/object-relational-mapping-is-the-vietnam-of-computer-science/ https://blog.codinghorror.com/object-relational-mapping-is-t...
- meredydd 10y ago
  I assume you're talking about https://anvil.works https://anvil.works here. That tension ("hiding facts") is there in every abstraction, but there are some luxuries to the way we do it. By putting a whole, consistent layer over the top of the web platform (in our case, Python and a traditional UI toolkit with a GUI designer), rather than patching little holes in usability here and there, we can prevent you from stubbing your toe on (eg) Javascript-isms every five minutes. The tradeoff is that if you want to use an obscure feature of the underlying platform (and boy does the web have those), you need to explicitly abandon our abstraction. There's always an escape hatch for this - you can drop down and write HTML/JS/CSS if you need to. (And something similar on the server side too.) All abstractions leak. Anvil leaks deliberately and rarely, whereas abstractions built in the classic HTML/JS/CSS world leak constantly and unpredictably. We think that's worth the trade-off.
tedmiston 10y ago
+ A framework to make the web app framework more suitable for API development (eg Django Rest Framework)
LBarret 10y ago
this is a bit disingenuous. the back-end technologies are quite stable and based on not-perfect-but-reasonable semantics. Django/SQLALchemy don't change that much. Front-end on the other end is a mess. JS/HTML/CSS as tools are clearly unfit for the current needs.
- scriptkiddy 10y ago
  I think backend frameworks do change. I think the difference lies in the velocity of change. Front-end frameworks tend to move laterally; e.g. implementing a new design pattern or changing the workflow with an existing API. Back-End frameworks tend to move vertically; e.g. adding new features or abstractions and developing generic bootstrapping procedures. I'm glad you brought up Django here. I work with Django as my primary back-end. I think it does a great job abstracting the stuff you don't normally need to worry about while persisting the ability to modify it if need be. It seems like every update to Django is designed to make the developer's life easier. It doesn't require complicated build tools. It has a built in dev server. It includes a fantastic and secure ORM. It has it's own easy to use templating language. You can build an entire web application with Django and no 3rd-party packages if you wanted to. Contrast that with something like Node/Express/whatever and you can see the two different camps of developers a bit more clearly. Sure, maybe my Python runtime is slightly slower than a Node runtime. Maybe the lack of async request handling(not really a problem with channels or celery) means I can't handle as many concurrent requests. Here's the thing. Hardware is cheaper than developer time. If I have an overloaded server, I can just spin up another with the push of a button and pay 10 bucks to run it for a whole month. 10 bucks is like 20 minutes of developer pay. That's not to knock on Node, it has it's use cases, but the ecosystem it exists in is one of infinite dependencies and breaking changes. In conclusion, I think back-end frameworks do change. I believe that changes to back-end frameworks have a different velocity to those on the front-end. I also believe that the changes made are a direct result of a framework's ecosystem. I hope that made sense.
  - 3ch1dna 10y ago
    The problem is that I think a lot of back-end frameworks change (and/or are created in the first place) as just a means to pad the developer(s) that coined it. All the new implementations of JS that are increasingly more backend just seem like a lazy way of not having to learn a "real" OOP language and just pressing boundaries. Which is great in some respects, but I feel like we could be making better headway as a collective resource by working on improving what's already there (without breaking it in the process) instead of making new things so the new kids to the game don't have to try so hard. HTML is akin to translating. I know devs who have done front end for 20 years who can't begin to wrap their heads around scripting because it's not just wrapping text in brackets to translate to a screen, but they can pull of tricks in CSS like a shark breathes water. Yes, CSS is a mess and I think a lot of that was trial and error and needs to be standardized, but it's an example still of working to make something that is already there do its job better rather than making something new and shiny to replace it so you can add another language to your portfolio.
YeGoblynQueenne 10y ago
>> A modal web application today takes an absolute minimum of five programming languages and three frameworks: I haven't done it myself, but you could try to replace most of your stack from the database up, with a single language: http://www.swi-prolog.org/FAQ/PrologLAMP.txt http://www.swi-prolog.org/FAQ/PrologLAMP.txt You'll still need the three stooges but at least you'll have a single language behind them.

erlich 10y ago

You can literally use Javascript for all of this.

meredydd 10y ago
I think you may be misunderstanding my point. If you have to invoke a brand new JS framework with limited uptake and many competitors, and "one of a million" CSS frameworks, in order to declare this problem solved, you are perpetuating the problem. I don't want to knock these tools too hard, because I can readily believe that (eg) Flow, or Typescript, or whatever we'll all be using next week, is much better than using vanilla JS/CSS. But the fact that we need to know all of Flow, and all of JS, and all of bootstrap, and all of CSS, and we're still not even off the client yet, is exactly why the web is a mess.
- erlich 10y ago
  My thinking on this is that everytime someone has tried to unify these tools it hasn't gone well. Think about Google Web Toolkit, or Microsoft's XAML. It's better to have everyone experimenting, blogging and doing their thing, and the best ideas rise to the top. 2015 was probably the worst time to be a web developer on a greenfield project. You had Angular deprecation and the Flux wars, and Babel 5 -> 6 migration. I do agree its a mess and a freaking nightmare most of the time. I've spent hundreds of hours setting my toolchain up and if something like webpack were to lose favour, I would be devastated. I think we are in need of a Rails for modern JS. My prediction is that we will see this emerge soon. A shift from project-templates to simple, generic plugin system. Webpack seems quite strong as the packager. Angular 2 CLI just migrated to webpack from Brocolli for example. React and Redux are standard now. And npm is the package manager of choice.
  - rpeden 10y ago
    Did GWT or XAML really try to unify things? Back in 2009, I worked on a complex SPA using GWT. With GWT, you could pretend to know nothing about HTML/CSS by just using the ugly build in components, but none of the GWT users I met did that. Our app used a Model-View-Presenter structure, dependency injection, and event bus for asynchronous communication to let components know when their data had updated, plus UIBinder templates for defining the look of components (which are mostly just HTML and CSS). So although it was nicely structured, it was very much a web app, and the development experience felt pretty comparable to what I experience in React today. XAML is mostly just a way to declaratively specify the layout and structure of UI components. Actually, I think it's just a declarative syntax for creating a hierarchy of object instances. If I remember correctly, the XAML and its corresponding C# file are both partial implementations of the same class, since .NET allows partial classes. Now, I'm not saying that I think the current state of JavaScript tooling is the worst thing ever. But I do think that that some of the 2009-2010 era JavaScript frameworks provided a more sane and cohesive development experience. React and Angular are nice, but I also remember that in 2010 it felt pretty neat to create an interface in OSX's Interface Builder, and have it show up in my browser exactly the way I'd drawn it.
    - erlich 10y ago
      The point I'm making is that when people have tried to develop a UI framework in a single language from scratch and offer the same functionality as the web, they fail. Performance sucks, or its not flexible enough to deliver certain functionality. By XAML I guess I mean WPF or whatever it is called. The bet was that Silverlight would be installed in every browser and you could build more powerful apps. I remember reading a post about how Evernote rewrote their WPF app because performance was never good enough. GWT tried to make a nicer API for building UIs. The API was nice, but I guess the whole transpilation caused issues with debugging etc. --- HTML, JS, CSS is evolving in such unpredictable ways, each time getting better and better. It just has such a large community using it and experimenting with it all the time - I don't think anyone can compete with the hive mind of web devs.
chx 10y ago
That leads to the MEAN stack (Mongo, Express, Angular, Node) and I am not so sure whether that's where the rosy future is.
- unclebucknasty 10y ago
  Exactly. Intuitively, I don't think the problem can be solved with the same "let's glue together a bunch of stuff and call it a stack" approach that got us here.
  - erlich 10y ago
    I'm hoping it is. We have ended up with really good tools compared to what we had before. Think about using commonjs requires, compared to the craziness of the Rails asset pipeline and sprockets, or manually specifying js files. We just need to standardize the glue...
    - unclebucknasty 10y ago
      Better bad is not the same as good. The approach itself yielded the issues such as that you reference, which have only been partially resolved by subsequent iterations of the same approach. I don't believe we should give credit for an approach that yields what is still a net-negative. It's a new thinking that we need, not reluctant acceptance of the best sub optimal execution the old thinking can deliver.
    - rpeden 10y ago
      The best part will be when we're all standardized on ES2015 modules instead of commonJS modules. I agree with you that CommonJS requires are nice to use, but since they're not statically analyzable the way ES2015 imports are, optimizing compilers like the Closure Compiler can't really analyze your entire application, including its dependencies. Once we've completely made the ES2015 transition (at least for front end modules), we might be in a position to see some really great front end tooling.
      - 10y ago
deleted 10y ago
[deleted]

9point6 10y ago

I think your use of "minimum" is wrong here. If you're using React running on Node and Webpack as your task-runner you just need Javascript and that's it. Node allows you to run isomorphic JavaScript that runs on both your server side and client side (to ensure you don't end up with the Angular-style skeleton pages coming from the server), You can pick a nice ORM (like sequelize) to abstract away SQL, and Webpack allows modules to specify their styles in JavaScript to allow compossible CSS for each given page. Yes this is still using a couple of frameworks, but I personally prefer the approach of a lightweight standard library to the everything-and-the-kitchen-sink approach that other languages have.

meredydd 10y ago
I still count three frameworks :) (React, Node, sequelize, I'm not counting webpack but I probably would if it's anything like as much of a pain as Grunt or Gulp or... And as you say, this is the lightweight version.)
- 9point6 10y ago
  Ah I wouldn't count Node as a framework as I'd equate it to the JVM in Java world. But you are right, I'd probably lump webpack in there as it does have a fair bit of depth to it if you want to get the most out of it.
  - aclsid 10y ago
    You still need to use Express or something similar on the server side for Javascript, I mean, if we are talking about standard procedures here. Plus with React, you are still doing that Javascript/CSS thingy and HTML of course at some point, so there is no avoiding that, and clearfixes, polyfills, etc, etc.
    - tracker1 10y ago
      But all of these things you're bitching about combined are far smaller than even ASP.Net without including anything client-side.

sesutton 10y ago

HTML, CSS and SQL aren't programming languages, if Turing completeness is a requirement to be a programming language.

coldpie 10y ago
This is a language lawyer nit-pick comment that doesn't add anything to the discussion.
throwaway729 10y ago
> if Turing completeness is a requirement to be a programming language Many languages (in the formal sense) aren't Turing complete, so this certainly isn't a requirement to be a formal language. It would be odd to come up with a definition of language that excludes regular languages, for example. TBF you did say "programming language", not just "language". But once we move from the mathematical setting of formal languages into the informal engineering setting of programming languages, I don't see why a formal concept such as Turing completeness should be the deciding criterion for what constitutes a programming language. I think a more reasonable criterion is that a programming language needs to have at least 1) a syntax; 2) a semantics or an implementation that could, with enough effort, be given a semantics; and 3) whose primary use is giving instructions to some computational machine (Turing or otherwise). According to this criterion, SQL is certainly a language. If you think about it for a moment, HTML and CSS are perfectly reasonable languages as well. Their semantics, however hairy, would be given for instance terms of manipulating objects in R^2.
- Bartweiss 10y ago
  This seems like a great place to observe that Magic The Gathering is Turing-complete. If your requirements suggest that MTG is a programming language, but HTML isn't, they're probably bad requirements. The syntax/semantics/instructions option seems like a way better basis. And honestly, most of us can get by with a Potter Stewart style standard of "know it when I see it".
mirages 10y ago
HTML + CSS seems to be Turing complete : http://lemire.me/blog/2011/03/08/breaking-news-htmlcss-is-turing-complete/ http://lemire.me/blog/2011/03/08/breaking-news-htmlcss-is-tu... As does SQL : http://stackoverflow.com/questions/900055/is-sql-or-even-tsql-turing-complete http://stackoverflow.com/questions/900055/is-sql-or-even-tsq...

contingencies 10y ago

You forgot something for the mobile strategy, something for web stats, something for monitoring, something for source control, something for issue management, something which shall remain nameless for team communication that breaks store and forward and interrupts you constantly, something for 'social', etc. Oh wait, and your infrastructure automation solution. And your third party DDoS protection/web cache integration... and all of this is TRULY NORMAL. We are underpaid.

douche 10y ago
You forgot containers, and a platform for orchestrating(?) or swarming or cat-herding or whatever it is one does with a gaggle of microservices.
vram22 10y ago
You forgot integrating all of that, keeping it integrated (aka working) as versions of pieces change, and debugging it all.

Bartweiss 10y ago

"A framework to make Foo bearable" seems like a huge portion of the issue here. We have a bunch of tools so hideously unfriendly to everyday development that we have to pile framework on framework in an attempt to actually get something built in a timely manner. And the result, of course, is an unmaintainable stack of dependencies and inefficiencies. Any time anything changes, anywhere, the whole thing falls apart again. Security folks talk about "threat surface" - I wonder if it would help to have an idea of "development surface" to signify the risks of bloat and dependency chaining?

jackhack 10y ago

Good post which jogged a memory for me, HN discussed this very thing 7.5 years ago: five languages in 7 lines of code -- how now to do web development : https://news.ycombinator.com/item?id=492321 https://news.ycombinator.com/item?id=492321

tantalor 10y ago
That doc is broken.

sheriffderek 10y ago

I would exclude the 3rd framework. You do not need or want to use a CSS framework if you actually understand and have experience writing CSS.

sheriffderek 10y ago
Whenever I hear this argument, I think of those guys out there on the freeway laying asphalt in the middle of the night. Or those people who are dead - inside the dam's cement. They probably wish they didn't have to use tools or try new techniques or combine skills and continue to learn new ways of building complex structures. They probably wish things didn't go wrong. They probably wish there was a task manager that just put all the dirt into the wheelbarrow and rolled it where it needed to go. As we move to a computer-based way of building things, it seems that we have already become spoiled and self-deserving. It seems like most 'developers' took a "rails for zombies" tutorial and are angry that things aren't as easy as that. That's why front-end developers get paid 4 times a much as most people / to make crappy software for other developers to track their time or catalog their toys or rants with their friends about how much they hate programming. I think everyone who doesn't like writing code, should get a job on a contractor's team for a summer - if they'll have you. Then while you are thinking about how much that job sucks, dream up a new box-model CSS type thing and be the hero.

clifanatic 10y ago

... and usually ... Five or six competing frameworks that do the same thing in different, incompatible ways, because either the guy who understood EXT-JS left the company or one group like jQuery better than DOJO and they both went off to do their own things only to be brought back together later.

cosinetau 10y ago

I remember being warned about engineers that get used to using frameworks too often. Their ability to work outside of it eventually suffers. We might need less abstraction, and let the engineers work that out.

tracker1 10y ago
LOL, all of the frameworks mentioned, even express are pretty light abstractions... that said, I feel angular, as an example goes TOO far.. way too far. These days, I hesitate to even use lodash, let alone jquery or larger bits. Though I'll still bring in moment if I have to deal with a lot of date/time logic and formatting (hate the size of it though).
joesmo 10y ago
Yeah, I'm all up for writing everything in machine language using punch cards. Anything else is clearly too much abstraction and obviously a sign of bad engineers.
- dllthomas 10y ago
  Cards? No, you need to feel the bits, inputting them with manual switches.

tracker1 10y ago

OR... * JavaScript (client and server) * Redux (state management) * React (UI Control framework) * MaterialUI Controls (toolkit, one of many) * JS Friendly DB With a database that has a native adapter such as RethinkDB (or Mongo if you really want it), it's really transparent.

BinaryIdiot 10y ago

> If anything, this understates the problem. A modal web application today takes an absolute minimum of five programming languages If you're going to call HTML a programming language than when you talk about server-side work you must include XML as a programming language (I see markup far different, more simplistic than a programming language). CSS is simply properties applied to the same markup but I digress; I could see the argument argued either way. Regardless, you can minimize what you're saying down to just HTML, CSS and a server-side language. You can make good applications without a single line of JavaScript and depending on your purpose you may not need persistent storage in the backend. In fact you can write an entire web application with just HTML, CSS and JS if you want and have no backend (beyond a CDN unless you want to be super pedantic and call that a "backend" but I think that would exceptionally overstate what it does). > And then come the (leaky) abstractions on top of them: God, you don't need any of these. JS isn't that bad anymore. It's actually kinda nice in some ways. Same with CSS it's rather easy and there are far lighter projects than bootstrap if you want to do minimal stuff, quickly (but there isn't any reason you can't look at tutorials if you're new and get a CSS layout working pretty quickly sans framework). For server side this depends on your language. Node has a great built in http capability that many seem to ignore (it's quite easy to write your own web server using it; in fact it doesn't take much more code than plugging into express or hapi). Alternatively other languages have even better, built-in ways of handling server-side logic. > ...and often... Ugh, SQL is so easy I don't understand why people even bother with these. Every single time I've been involved in a team that used these abstractions it worked great initially and then steered us off a cliff in the end. Just don't. RDMS is easy.

meredydd 10y ago
> If you're going to call HTML a programming language [...] CSS is simply properties [...] Whatever they are, they're complicated. They've each got syntax, enormous sets of tags/keywords to learn, and quirks coming out of their ears. There are even people down-thread pointing out that HTML+CSS is Turing complete. > God, you don't need any of these [abstractions] With respect, almost everyone else in this thread seems to disagree with you. I'd challenge you to find a major public-facing web app written with - let's be charitable - fewer than two of the frameworks on that list. I do tend to agree with you on the merits of SQL, though. We built a very simple database for Anvil, that doesn't do anything except store and retrieve tuples of data, and for anything more complicated, we say "great, SQL is over there" :-P

ohgh1ieD 10y ago

What you basically do, is hiding and abstracting facts. That comes at a cost, namely when someone has a special requirement, then that person has to dig very deep into your framework. It's almost the same like Java GWT or Vaddin. If you stick to the recommended way, everything is just fine, but don't ever try to solve some exceptional problem because then you are in a world of pain where it's just smarter to embrace JS and CSS. The problem is, abstracting things away doesn't make them disappear, because WEB DEVELOPMENT IS BROKEN BY DESIGN. I never used your app nor do I know how it behaves, this is just general speaking about the scenario when people try to 'abstract' things away, I hope you understand that I'm not speaking about your app but the idea of hiding things. The sames goes for all those frameworks who tried to hide HTTP ( I'm looking at you asp.net and some older Java frameworks ), this lead to a pile of shit, newer frameworks accept the fact that we use HTTP and we got less problems by doing that. Since you mentioned ORM's, it's called the Vietnam of computer science[0], everyone tries to hide SQL, if you are doing some basic CRUD applications everything is fine but if you need more sophisticated queries you are already fighting the ORM which is supposed to help you and not making you developer life miserable, we don't need another DSL for databases, SQL is already the best language to make queries. I guess, what I'm trying to point out here is that I use those simple tools because I know my way around, I know how to debug it which wouldn't be possible with some abstraction. [0] https://blog.codinghorror.com/object-relational-mapping-is-the-vietnam-of-computer-science/ https://blog.codinghorror.com/object-relational-mapping-is-t...

meredydd 10y ago
I assume you're talking about https://anvil.works https://anvil.works here. That tension ("hiding facts") is there in every abstraction, but there are some luxuries to the way we do it. By putting a whole, consistent layer over the top of the web platform (in our case, Python and a traditional UI toolkit with a GUI designer), rather than patching little holes in usability here and there, we can prevent you from stubbing your toe on (eg) Javascript-isms every five minutes. The tradeoff is that if you want to use an obscure feature of the underlying platform (and boy does the web have those), you need to explicitly abandon our abstraction. There's always an escape hatch for this - you can drop down and write HTML/JS/CSS if you need to. (And something similar on the server side too.) All abstractions leak. Anvil leaks deliberately and rarely, whereas abstractions built in the classic HTML/JS/CSS world leak constantly and unpredictably. We think that's worth the trade-off.

tedmiston 10y ago

+ A framework to make the web app framework more suitable for API development (eg Django Rest Framework)

LBarret 10y ago

this is a bit disingenuous. the back-end technologies are quite stable and based on not-perfect-but-reasonable semantics. Django/SQLALchemy don't change that much. Front-end on the other end is a mess. JS/HTML/CSS as tools are clearly unfit for the current needs.

scriptkiddy 10y ago
I think backend frameworks do change. I think the difference lies in the velocity of change. Front-end frameworks tend to move laterally; e.g. implementing a new design pattern or changing the workflow with an existing API. Back-End frameworks tend to move vertically; e.g. adding new features or abstractions and developing generic bootstrapping procedures. I'm glad you brought up Django here. I work with Django as my primary back-end. I think it does a great job abstracting the stuff you don't normally need to worry about while persisting the ability to modify it if need be. It seems like every update to Django is designed to make the developer's life easier. It doesn't require complicated build tools. It has a built in dev server. It includes a fantastic and secure ORM. It has it's own easy to use templating language. You can build an entire web application with Django and no 3rd-party packages if you wanted to. Contrast that with something like Node/Express/whatever and you can see the two different camps of developers a bit more clearly. Sure, maybe my Python runtime is slightly slower than a Node runtime. Maybe the lack of async request handling(not really a problem with channels or celery) means I can't handle as many concurrent requests. Here's the thing. Hardware is cheaper than developer time. If I have an overloaded server, I can just spin up another with the push of a button and pay 10 bucks to run it for a whole month. 10 bucks is like 20 minutes of developer pay. That's not to knock on Node, it has it's use cases, but the ecosystem it exists in is one of infinite dependencies and breaking changes. In conclusion, I think back-end frameworks do change. I believe that changes to back-end frameworks have a different velocity to those on the front-end. I also believe that the changes made are a direct result of a framework's ecosystem. I hope that made sense.
- 3ch1dna 10y ago
  The problem is that I think a lot of back-end frameworks change (and/or are created in the first place) as just a means to pad the developer(s) that coined it. All the new implementations of JS that are increasingly more backend just seem like a lazy way of not having to learn a "real" OOP language and just pressing boundaries. Which is great in some respects, but I feel like we could be making better headway as a collective resource by working on improving what's already there (without breaking it in the process) instead of making new things so the new kids to the game don't have to try so hard. HTML is akin to translating. I know devs who have done front end for 20 years who can't begin to wrap their heads around scripting because it's not just wrapping text in brackets to translate to a screen, but they can pull of tricks in CSS like a shark breathes water. Yes, CSS is a mess and I think a lot of that was trial and error and needs to be standardized, but it's an example still of working to make something that is already there do its job better rather than making something new and shiny to replace it so you can add another language to your portfolio.

YeGoblynQueenne 10y ago

>> A modal web application today takes an absolute minimum of five programming languages and three frameworks: I haven't done it myself, but you could try to replace most of your stack from the database up, with a single language: http://www.swi-prolog.org/FAQ/PrologLAMP.txt http://www.swi-prolog.org/FAQ/PrologLAMP.txt You'll still need the three stooges but at least you'll have a single language behind them.