Hacker News Reader

Comment by plainOldText | Hacker News Reader

Oh boy, yet another JavaScript framework. Colored me unimpressed; angular, backbone, ember, angular 2.0, react, etc. I feel like they're just reinventing the same wheel with a different spin. I wish people would actually spend their time creating a really revolutionary "framework" instead, better yet a programming environment, which would redefine how we write web programs.

I'm envisioning a way to create software, where while having a conversation with another person, we could collaboratively draw some shapes on the screen, connect them, then my program comes to life, evolves, scales up, scales down, etc.

I believe programming should not be an endeavor accessible only to those adept at manipulating text files. Telling computers what to do should be for everyone.

View on HN

It's frustrating that this is the top comment on the thread, because it could have been written without reading anything about this Javascript framework.

Ironically, it's exactly on stories like these --- new Javascript frameworks, CSS templates, and the like --- where in-depth HN comments are most useful. I clicked the story, read it for 2 minutes, thought "you know, the top comment on the HN thread for this is probably going to tell me all I need to know about this framework", and instead found your comment.

Oh boy, another complaint about having a diversity of tools available.

You're not really contributing much here, and it's a frustrating attitude to see. We're still in the relatively early days of building the kind of apps that these frameworks are targeted at; the idea that any time spent on incremental improvement or experimentation is a waste, and instead we should; 'redefine how we write web programs' is just nonsense. It's extremely rare that things evolve in that fashion.

Yes, programming probably should be accessible to everyone. That's a gigantic, fuzzy challenge that's totally orthogonal to spending time developing tools that are useful in the immediate present.

And it's not like it's never been tried before. What about Hypercard, or more recently Scratch? Or Swift's playgrounds? All of these are looking at ways to make development more visual and accessible.

Your time would be much better spent contributing to those efforts than rubbishing the attempts of other people to deal with other problems.

Completely agree with your first paragraph, but not the second.

There have been plenty of GUI programming tools, but most of them are pretty crap (the ones I have tried). MS Access had an OK query builder, but at the end of the day it didn't gain you anything over SQL. Java beans were touted as t a hot topic back when I was at university, but nothing ever came of them.

Syntax is rarely the difficult part in programming (except with CSS maybe). The way I see it, plugging parts as you describe together relies on a number of assumptions being made for you. The easier it is to plug things together, the less flexible each unit becomes. The difficult bit is choosing what assumptions are appropriate.

> I'm envisioning a way to create software, where while having a conversation with another person, we could collaboratively draw some shapes on the screen, connect them, then my program comes to life, evolves, scales up, scales down, etc. I believe programming should not be an endeavor accessible only to those adept at manipulating text files.

There are many solutions (e.g. Simulink, GUI builders, the "connected nodes" approach of Blender) for that, but they only tackle specific areas. I don't see that changing, either. And they usually don't address anything except very small programs (say < 5000 lines of code), while the exact purpose of these JavaScript frameworks is to deal with the larger ones.

I find it very strange that programmers seem to think their trade has artificial entry barriers. For some reason, mathematicians are not concerned with that. It's already fairly easy to get started with programming. Languages have come a long way, there are good IDEs and you can get started using just freely available software.

Speaking of mathematicians, they've also come up with an explanation how to model those graph based, "data flow" languages like Simulink or Blender's connected nodes abstractly. They are all examples of diagrams in some (traced, symmetric) monoidal/cartesian category. What is missing is a programming system that isn't tackling a specific area based on that model, that is it supports polymorphism. Haskell's arrows come close, it is relatively easy to model cartesian closed categories in it. But something better, with graphical visualization and maybe direct manipulation would certainly desirable.

React is pretty revolutionary. It turns rendering code into a simple pure function, which is a necessary step for where you want to end up.

Rendering code is easy to express as pure functions...that is mostly how OpenGL and DirectX work, after all. React doesn't help very much with the state of your application (nor is it meant to). That being said, being able to treat the DOM as something to be rendered efficiently in immediate mode is quite useful.

OpenGL is a big ol' box of state in almost everything it does. I'm not sure how you get pure functions out of that.

Immediate shader mode is fairly stateless, pixel and vertex shaders are as functional as one can get. Let's not talk about the fixed function APIs that no one uses anymore.

I'm not sure what you mean by "immediate shader mode". Even direct state access mode is tweaking knobs in a state machine that can have very strange side effects if you don't re-set the state every time (and that's antithetical to pure functional programming). When not using DSA--I mean, just grep for "bind" in any OpenGL codebase...

The hardware has state that is exposed more or less directly, but texture management is all just plumbing and easily wrapped. Most of my experience is with directX though, which seems to have a much cleaner API.

Anyways, immediate mode UIs abound for game stacks given the ease at which they can be mapped to the GPU directly.

DirectX still uses stuff like ID3D11DeviceContext::PSSetShaderResources to set application-global state that's required to do anything. It is fundamentally stateful and non-pure. I'm not sure why you're trying to argue this point.

Benchmarks for React tell a different story. It's like two orders of magnitude slower than multiple alternatives. If you are performance critical, React is not possible to use in production, and likely will never be considering Facebook's development practices.

I've deployed two applications to production that use React and in neither has React created a performance bottleneck. Both of them are heavily used in mobile, too. And they work wonderfully.

Benchmarks don't mean much when you're shipping real software to production.

You're reading too much into benchmarks without understanding what the alternatives are.

Sure there are faster ways of rendering a template; just use format strings! Wow — super fast!

It's a nonsensical way of reasoning about frameworks.

I couldn't really understand what FOAM does in under 2 minutes, so it doesn't meet the bar for me.

You should try React with JSX though. It's a tool like jQuery, but much more sane and structured, and as opposed to frameworks, it becomes more likable the more you use it.

Don't see how that's a bad thing, nobody forces you to use it, and odds are some nice ideas will get validated here and more popular frameworks will adopt them. Think how React influenced the changes in rendering models of Ember, Angular, etc.

Always baffles me how HN crowd can at the same time revere Lean/Agile mindset, and at the same time despise the same principles applied to the tools ecosystem. To me it's obvious that to make progress of any kind multiple attempts are needed. Naturally only few of all those experiments will survive, the thing is nobody knows which ones.

I am glad there are others who are looking into this same approach to build software. We are currently building just this. http://www.dhi.io

We want building web ui's to be as simple as having a conversation with another developer about the requirement.

"I'm envisioning a way to create software, where while having a conversation with another person, we could collaboratively draw some shapes on the screen, connect them, then my program comes to life, evolves, scales up, scales down, etc."

This already exists, its called UML, and UML code generation tools. Wait, Have I just fed the troll?

To add to that, it's not really even that impressive - no ES6, lots of technologies that are not in the current "hype" and so on.

That said - having frameworks emerge from the community rather than dictated is a good thing, it helps create a healthy ecosystem. Whenever a new "fad" takes over we actually _do_ learn something.

Interesting sentiment, but the problem is that way is awfully abstract. Until computers can write code optimized for both the intent and use case, this remains a far out of reach dream.

It could happen, but I suppose it would need very different architecture compared to CPU.

I've been thinking about this as well. A visual and intuitive way of building software would make software and code as disposable as paper.

Do you want to help build a system that is universally distributed and allows creation by everybody? I want to build something that will allow every person to create software on their touch screens without having to fiddle with complex interfaces or text-based commands. Do you want to make this vision a reality?

Email me sethjgore@gmail.com.

A Mozilla effort: https://webmaker.org/

I can understand your frustrations, it does seem huge amounts of the work in a web application are really about configuration rather than code. Often there are no algorithms, just lists of database tables and fields, forms, validation rules, routes, links, templates etc.

It seems we aren't very good at catering for people who aren't like ourselves.

Have you tried Scratch (https://scratch.mit.edu/)? It sounds similar to what you're describing. If you have any ideas on a better way to do this, maybe you should build it - there's a lot of interest in "accessible programming".

React is not a framework though.

It's the smell of progress.

Reply on news.ycombinator.com