Hacker News new | comments | ask | show | jobs | submit login

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 - where everything is in Python, and the GUI is drag'n'drop.




"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?


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.


> Node allows you to run isomorphic JavaScript that runs on both your server side and client side

But then you're writing JavaScript on the server side, and I think I'd rather shove live weasels down my trousers than write one line more of JavaScript than I absolutely must.


JavaScript is a fantastic language. I don't get this animosity towards it. A decade ago it was made fun of by people who "use real programming languages" but JavaScript has grown up. It's actually very good and very fast. ES6 brought improvements but honestly ES5 is still a great language.


JavaScript is not a fantastic language. It does a lot of things that make no sense. It converts between types in nonsensical ways. Eg in Ruby, you can't accidentally do `5 + "hi"` and get "5hi". If you really want to treat the number as a string, you can do `5.to_s + "hi"` and it works, but you don't do such crap accidentally.

In JavaScript, `4 / "cake"` returns `NaN`, which is sensible, but if I wanted to check whether I just accidentally did a bad division, `(4 / "cake") === NaN` will lie to me.

There are LOTS of quirks like this. JS is like a floor with boards missing all over the place. Yes, if you've walked on it every day for years, you've already stepped in every hole and know where they are. But that doesn't make it a good floor.

A good language is consistent. JS is not.

The fact that it now has fast implementations has nothing to do with it. This car goes 300mph, but don't use the left turn signal on Tuesdays because that sucker will blow you up.


> It does a lot of things that make no sense. It converts between types in nonsensical ways. Eg in Ruby, you can't accidentally do `5 + "hi"` and get "5hi". If you really want to treat the number as a string, you can do `5.to_s + "hi"` and it works, but you don't do such crap accidentally.

Uh, so two things here. First, even though it's a dynamic language you should know what your code is doing. Your code should never be be "accidentally" doing this. That would be very poor design outside of an accidental bug.

Second, some other dynamic languages do this or other weird type coercion (I mean type coercion exists for a reason; sounds like you're against it in general which is separate from JavaScript). PHP simply extracts numbers from strings and uses them in this case. Many languages use + as a concatenation operator JavaScript just doesn't have a good way to override it so it could work properly in all cases.

> In JavaScript, `4 / "cake"` returns `NaN`, which is sensible, but if I wanted to check whether I just accidentally did a bad division, `(4 / "cake") === NaN` will lie to me.

It's not lying to you; you're using a feature of the language wrong. That's like calling the wrong validation function and getting upset because it's not working like you wanted it to (because there is a validation function for NaN). At the same time a good design won't run into this issue anyway. Now I'll admit NaN is a bit of an oddball so yes it's not the most intuitive but at the same time don't say the language is lying to you.

> There are LOTS of quirks like this. JS is like a floor with boards missing all over the place. Yes, if you've walked on it every day for years, you've already stepped in every hole and know where they are. But that doesn't make it a good floor.

> A good language is consistent. JS is not.

Not really. This is the common statement repeated by those who don't use JavaScript and consider it an awful language. If you're following best practices I'd love to know where all these language quirks or inconsistencies are because I'm for sure not running into them.


NaN is not equal to NaN by the IEEE 754 standard. JavaScript, and many other modern languages, implement floating point numbers by this standard. E.g. in C#:

> 0.0/0.0 == Double.NaN

false


Totally agree. The lack of understanding of JavaScript's paradigm from some people make them blind about the language power, it has the enough amount of every needed paradigm there, including OOP, functional and evented. I see in the comments here people complaining about things like dynamic `this` when they just don't understand it's one of the biggest powers of JS.


JS is not object oriented. A prototype is not the same thing as an object. There are no classes in JS.


What you mean to say: JavaScript is not class-oriented.

Sure, there are features that JavaScript lacks compared to other object-oriented languages, but saying that it's not object-oriented is like saying that it's statically typed. It's just wrong, the language is full of objects.


Ok, tell me where on "object-oriented programming" is the word "class". Objects are not necessarily related to classes. And yes, a prorotype is a object that you can extend from, as well as from any other object, like prototype-based OOP works.


JavaScript sucked indeed. ES6 though, has brought many improvements, and the language now is quite decent. With the advent of async/await in ES7 (which is available now if you transpile with Babel), the callback hell is completely gone, and the language is actually beautiful, powerful, and concise.


I think we are exaggerating here. Javascript was terrible but with es6 it's just getting better, I know various languages and only Javascript manages to make me scream with its quirks, the others at most I feel disappointed. So "good" is an exaggeration, reasonable seems fine, but currently is either an OOP language where 'this' changes every time, or a functional language without native support for immutability, curried functions by default and a whole bunch of utilities that you expect from a language claiming to be functional. If it's a language with both mixed, must be compared to ruby which has consistent oop and functional programming with support for laziness and a super powerful ability to create dsl.

And in Javascript, it's still a nightmare importing a file. You either have a or you are on nodejs.


Damn, I see so much frustration from you for not being able to understand JavaScript here... once you understand it's a different language instead of trying to write your favorite language with JavaScript syntax it'll get better, buddy, relax :)


You could of course write something that compiles to JavaScript. There's a ton of options, some are even pretty nice (I like ClojureScript; want to try out Elm).


Elm is client side only.


Elm can be installed run from the command line.


Do you mean there's a way to run non-html-anchored Elm? Links would be wonderful!


Then use PureScript.


This is where Typescript comes in. It's beautiful.


> You can pick a nice ORM (like sequelize)

I'm gonna stop you right there. Node is a helpful tool and I enjoy using it, but Sequelize was nothing but pure pain when I used it. You're much better off running raw SQL, or using a query builder like KnexJS.

I would never use Sequelize for more than a 1-table read or update.


honestly, in JS/Node, I find it easiest to use a SQL adapter that can handle template strings as parameterized queries...

    const results = await sql.query`
      SELECT ...
      WHERE foo = ${bar}
    `;

    if (!results && results.length) return;
    await myQueue.add(results);
Which works unbelievably well... There's not nearly as much need for boilerplate/translation layers in what is already a dynamic environment. I wrote a wrapper for ms-sql when migrating data, it took 2-3 days to get it done, but writing queries as above was so easy to work with it was incredibly nice. I'd rather work with a db that has a friendlier API to work with or abstract around... but writing a little template driven sql is often better than layers of boilerplate like an ORM.. and I still don't really get mongoose.


Maybe I'm missing something, but that looks like SQL Injection ready to happen.


sql.query is a function that will receive two arrays, one is the strings part, the other is the injected values... the template processor takes those arrays and turns it into a parameterized query to the database.


Very cool! In that example though... where's the array? And don't backticks do string interpolation?


Backticks by themselves will do string interpolation. But backticks with a function name in front will do something a bit different. In this case 'sql.query' is a function and the JS will pass it an array which represents the contents of the backtick string. There the function can do what it likes and return a result. 'sql.query' builds a proper (and safe!) SQL query and executes it.

The backtick feature in ES2015 is really cool and allows for some great DSL type features.


This feature is apparently called "tagged template strings"; more on MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...


Neat! Thanks for the awesome explanation!


That looks fantastic, I'll take that any day over an ORM in JS.


Here's the one I wrote for mssql[1], though it should really be updated, and probably use tedious directly, instead of mssql.

[1] https://www.npmjs.com/package/mssql-ng


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.)


And how many frameworks can you count in a win forms or wpf application?

If we're going to count frameworks, there'd be no end it. As I once said, programming is abstraction upon abstraction.

Like an onion, a Russia doll or better still, inception.

Frameworks abound everywhere, at every layer. You just need to adjust your scope as you see fit, to find them.


Honestly from the programmer's perspective, it's really just one framework: .NET. I know that .NET abstracts away other frameworks such as the Win32 API, but generally you don't need to know any Win32 API etc. to make a Winforms / WPF / etc. application. With modern "web application" style development, it seems these days you need to know multiple frameworks by default, for better or for worse.

More to the point, .NET was designed from the get go as an enterprise programming language. The web was not designed from the beginning to be a universal application platform, it was designed to display formatted hyperlinked text. Much of the hack-y feel of today's web development -- as well as other aspects such as the rather poor security -- springs from this. If the web were designed from the get-go to be a universal sandboxed application platform, I feel that many things (ranging from the scripting language choice to the DOM model) would have looked a lot different today. Standard, non interactive HTML + CSS (what the web was designed for) certainly doesn't feel too hacky after all.


I'm not sure what sre you talking about, if you program with c# and wpf, you need to know xaml and their weird syntax, you need to know prism which is a framework to properly organize your UI, you need to know a server language like asp. Net if you want to deal with backend code.

Prefer winform? That's much like react without using jsx, and if yoy want fancy graphics is much more complicated than html. Now sure you can stick to system style, but you can also buy css themes, use bootstrap, material ui frameworks to have your already prepared ui in html too.

Same issues with qt libraries... The thing is simple: inevitably you need more layer of complexity if you need to be able to maintain the code while being open to changes.

For simple apps, sure winform is faster, for complex apps, no way, it's the same.

And you can't really say that.net is a single framework when it includes so much stuff that is bigger than react, node, webpack, css and html put together


I would have to disagree on the last sentence -- there is nothing in any definition of a software framework I know about that suggests that a software framework cannot encompass more than one function. .NET indeed does have a much larger solution stack then most web frameworks, for better or worse (there are advantages and disadvantages to this approach). But that does not disqualify it from being a framework in my opinion.

Web programming is more fragmented in nature, for better or worse. I think that was more my point with the first paragraph (and also a response that most .NET programmers don't need to care too much about any backbone frameworks .NET was built on). .NET provides you with a full front-to-back ecosystem. With web applications, you usually chose, at minimum, some form of Javascript framework, some back end framework, and some form of style framework. (Full stack frameworks for some reason have not taken off in the web ecosystem.) Even that description simplifies some of the fragmentation, due to the bewildering amount of choice. If you want to implement a Flux pattern in React for instance, there are over a dozen versions out there to chose from.

I don't think this necessarily says anything about app complexity or speed of development at all, agreed. Complex apps are going to be the same. I do think that the current fragmented, churn-y nature of the Javascript ecosystem can be a barrier to entry for simple apps at the moment; for that reason, I'll welcome the day when the Javascript ecosystem reaches peak "Javascript fatigue", becomes a bit more stabilized.


True it's a single framework, my point was only the size... I mean, the amount of knowledge you need is probably the same you need to work with web stack.

Also, if you need a backend even if it's written in same language, is still a different thing, much like node and web javascript. Choosing a different backend languages usually is made because of the advantages it brings (Rails for prototyping, Erlang or Elixir for stability, Java for performance and so on)


You are confusing .Net, C# and WP* frameworks. .Net is closer to the JVM, C# is the language and WP* are libraries that interact with w32 apis


Not trying to be pedantic, just posting to set the record straight:

- WPF, WinForms, ASP.NET, ADO.NET etc. etc. are all officially part of the .NET Framework.

- WPF doesn't do much (or any) direct interaction with Win32. It uses Direct#D for rendering.

- The CLR is the .NET equivalent of the JVM.

It's useful to look at the .NET Framework the same way as the standard library that ships with the JVM. They're both large standard libraries that include GUI Library (AWT, Swing, JavaFX, Winforms, WPF), database access (JDBC, ADO.NET).

In both cases, the extensive standard library can easily be used by multiple languages (i.e. VB, C#, F# in .NET, Java, Scala, Clojure and many others on the JVM).


As rpeden pointed out, it's you that are confusing the things. CLR is what JVM is for C#, while all the stuff I mentioned are inside the .net framework


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.


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.


But all of these things you're bitching about combined are far smaller than even ASP.Net without including anything client-side.


Node is a runtime, not a framework/language, and if you use a JS friendly DB (there are many with transparent APIs available (rethinkdb, mongo, etc) then it's all just JS.


"thats it"

250mb worth of dependecies later...


I would argue that React is different enough so as to almost be called its own language. After all, it does use "JSX", whatever the hell that means ;-)


> ... to abstract away SQL

SQL already is an abstraction, why would I want to abstract it away? Why not abstract JS away instead?


Well, everything is an abstraction, down to zeroes and ones.


Oh, it goes so much further down than that.


It's all just fluctuating fields in the vacuum?


Turtles all the way down.


Until you're working on a project where the turtles eat the errors...

Funny story, that's how I've been describing the issue with how errors have been handled on the project I'm working on, where there are SO many areas where errors are just ignored... so they don't propagate up the chain/stack... doubly annoying in a node environment where it's all supposed to be error first (as in the first thing you think about and check for).


I was describing the problem as "turtles all the way down, except the turtles are eating all the errors, and the rabbits can't find them"


> Why not abstract JS away instead?

Lots of projects are already doing this: Elm, ClojureScript, PureScript, etc.


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.


You forgot containers, and a platform for orchestrating(?) or swarming or cat-herding or whatever it is one does with a gaggle of microservices.


You forgot integrating all of that, keeping it integrated (aka working) as versions of pieces change, and debugging it all.


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-t...


I assume you're talking about 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.


... 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.


>> 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

You'll still need the three stooges but at least you'll have a single language behind them.


> 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.


> 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


> 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.

Just like with C++ you don't have to use all of those fancy features. You can use CSS as simply properties on many web applications. They can be as complex or as simple as need be.

> 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 actually work on one during my day job that is used by millions of people :). Though in fairness we're transitioning to a single framework rather than the hand rolled one.

Frameworks have their use cases. Native also has its. For whatever reason people today are taught they have to use at least one otherwise they're throwing their time away or they can't interoperate with others which are both not true.

I'm beginning to think I need to work on a web series around creating web applications without frameworks.

> 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

This seems to be the exact type of scenario I've seen played out countless times in my career but the easy start of ORMs sucks people in every time (though I honestly think starting without an ORM is also super simple but I think many of them abstract away schemas which, if you just want to jump into something, can seemingly get in the way.


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


That doc is broken.


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.


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.


Cards? No, you need to feel the bits, inputting them with manual switches.


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).


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.


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.


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.


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


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.


You can literally use Javascript for all of this.


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.


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.


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.


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.


That leads to the MEAN stack (Mongo, Express, Angular, Node) and I am not so sure whether that's where the rosy future is.


it's not, because Mongo has huge issues [0] and angular is generally a giant mess and a pain in the ass [1]

[0] http://blog.runnable.com/post/149000201856/think-before-you-...

[1] if you haven't used angular, ask someone who has


I work on a large (500000+ lines) of Angular daily. Maybe this represents some sort of Stockholm syndrome, but it's really not that bad?


Similar situation here, but it depends on your level of experience as well. Can you structure an AngularJS app so that it's (relatively) sane? Absolutely. It's also very easy to make a mess of things so that it's hard to reason about control flow; frameworks that are doing a better job of embracing unidirectional dataflow definitely help with this, but I don't blame Angular as it predates the wide adoption of that as a practice.

It's also more difficult to follow practices like quickly rendering above the fold content; when you use the normal practice of writing re-usable directives, you end up needing to wait until at least Angular and any dependencies are loaded prior to being able to render any content at all. Server side rendering of initial content helps to alleviate that quite a bit since even though the content may not be interactive until your app bootstraps, the perceived load time is much better as the user has something to look at.


Oh totally agree. There are some really nasty bugs we've had to deal with because of the lack of strictly controlled data flow. Still not all that bad.


Over half a million lines of Angular? May I ask what the application is and how that's broken down language-wise?


Angular front-end, C# "middleware" to Java services layer. I was actually guessing when I tossed off 500k. I went and looked and it's actually closer to 250. Still pretty big though.


Have you ever worked with a JS framework that wasn't angular? Ember, React, Vue, etc?


I've used react personally and like it rather well. I think it's much better than Angular, but I still don't think that Angular represents the 9th circle of hell, as seems to be implied above.


I think most libraries should be compared based on their worst-case implementations. As in, the "worst" react code is still much better than the "worst" angular code.


I've used Angular a good bit, seems fine to me. Last place I worked probably had around 20-30k lines of Angular code. It wasn't perfect, but it was way better organized and easier to understand than a much smaller project (~1k lines) done with JQuery and handmade paging system.


I have yet to work on any ng (1 or 2) project that I'd take over a well-structured React + Redux project.


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.


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...


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.


Yeh I initially hated that commonjs was not used for es2015 imports. Slowed down application startup and lack of node.js compatibility.

But after reading the justification it will be better in the long run.

We just need some way to lazy load modules.


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.


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.


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.


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


> 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.


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".



This is a language lawyer nit-pick comment that doesn't add anything to the discussion.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: