371–380 of 688 posts
Earlier quoted context omitted.
That was the promise of Java - write once run anywhere. JavaScript managed to achieve it instead.
You mean the browser achieved it instead of the JVM. It could have been something other than JavaScript as the scripting language. What mattered was the platform everyone ended up using.
My theory is that everything is a mess, once you get close enough to notice. Every profession that appears as if its practitioners know what they're doing really is a shocking hodge-podge of temporary solutions, strung together by proverbial duct tape. From doctors to flight engineers to anything else that you thought was running like a smooth machine. Programming is no different.
Earlier quoted context omitted.
Joel Spolsky (FogBugz, Stack Overflow, Trello) wrote this article half a generation ago. It's about not giving in to the temptation to start from scratch when your software is ugly. http://www.joelonsoftware.com/articles/fog0000000069.html
Ironically Firefox was produced as a result of the code created from the Netscape rewrite he criticised.
Earlier quoted context omitted.
NeWS was a lovely thing (and the HyperNeWS environment that was built on it is still one of all time favourite frameworks) but I'm not sure it was directly comparable with HTML+JS+AJAX - it was more like an attempt to do a better X11. Specifically I don't remember (even, ironically given its name, in HyperNews) there being much support for working with documents or hyperlinks. Mind you - it did do the client side scr…
They are all variants on the cross-platform thin-client theme. The HTML+JS+AJAX conglomeration has certainly more in common with NeWS than it does with the web I remember in 1994, which was a solution to the problem of sharing and cross referencing scientific papers and similar documents.
1. And it certainly was fun - HyperNeWS was brilliant (e.g. I remember drawing a "broken window" of multiple unconnected parts, pasting it as the shape of a terminal window and everything continued to work - this was '91 or '92).
Also I vaguely remember logging into another users environment and manually tweaking the transformation matrix for the terminal window they were using to rotate it very slightly as they were working...
Also seen/worked on projects that are a mess and devs there built hacks upon hacks to keep everything up.
I also felt like I am stupid (besides studying software engineering and working in the web business for 15 years) or I miss something. But then I also had the privilege to work with very skilled people and get a different perspective.
Here comes my argument:
I argue that most projects that went to be a mess have been set up by people that had to work with incomplete information or insufficient time to conquer the stated problem. So I project the question "is-technology-the-problem?" to "is-the-team-the-problem?".
In my experience much bad influence - that create messy projects - comes from the lack or the way of communication between technical designers (who say whats possible), developers (who say how its possible) and other stakeholders (who normally "just want something"). I think of a situation here, where I had to work with a sales guy who proudly sold "rapid development" and "agile iterations" without understanding the technical or management perspective of true rapid development.
When it comes to making design decisions (which WILL influence the "messiness") the web is full of different approaches, technologies and so called "best practices". If you're a designer of a "will-become-big"-project it is difficult to make those decisions based on this variety of solutions (which as the OP stated almost everytime suck after some months). The fact that every framework presents itself as the best and most versatile does not help at all.
My best practice to go out and talk to people about my problem and not ask the internet. Its others people experience you only can access in a discussion, because normally you don't and cannot know what information you lack and therefore ask superficial questions on the web and thus get superficial solutions and have to conquer previously unexpected problems in long-term.
Another argument I want to make:
If you were a carpenter and would have to build the interior of an opera you would not go to the web, google for a month and then think you have exhausted all available resources and now you are ready to build that opera interior. The ubiquity of "quick solutions" make developers believe there are no long-term-effects of such decisions and thus most such small decisions never get discussed. If you have worked in teams in other branches (building digital arts, building a house boat, stuff like that, where you MUST have a team) you get the point of what I am saying. Its only computer science where people stop talking because they think everything is clear to everybody.
About your question about orientation:
I suggest getting aware of the high level concepts of full stack web development and truly understand the concerns every layer tries to attack. Web-Development - like every other software engineering discipline - is all about Devide&Conquer. N-Tier development (one approach to D&C) is nothing new, but the semantics of web development are new. A good designer has to speak those new semantics fluently. It also helps getting a good feeling about what actually is a "best practice" and what is just sold as such. There simply is no universality to web programming as there is none to other software engineering disciplines.
I gained a lot of confidence in knowing about the classification of problems and how you would generally combine them instead of building a big hashmap of problem -> web-tech-framework (This also reminded me of some complexity courses I took in my studies). Giving clear semantics to different parts of your application and discussing those layers using natural language also reduces your teams vulnerability to total chaos and prepares for unexpected changes of requirements.
Further I learned from experience that its often the time-constraint that promotes messy code that never gets cleaned up because the project somewhat dies a slow death, which in my eyes is just a reminder that web-tech is something new to the society as a whole.
Finally:
Thus I developed the following perspective: I see myself as a moderator of language and problem-awareness. I often argue in front of customers that if you describe the project as a map of the problem domain there are A LOT of blank areas and its our teams effort that will unveil/debunk/uncover those blank areas. I also point out that there are a lot of semi-blank-areas on our project map. I for example know how agile development looks like that does NOT generate a hack-upon-hack architecture but the others don't. On the other hand I have no knowledge whatsoever about interiors of operas (to reuse the example from above). Its that explicit merge of information that prevents a projects structure going astray.
Yes. I feel like we're in the dark ages right now. JavaScript - Dynamically typed, does not scale what so ever. Code written in it becomes 'read only' very quickly. Impossible to refactor. CSS - Also becomes impossible to manage. Who knows if the class you wrote is or isn't being used in HTML or JavaScript somewhere. Same problem, read-only, it only gets bigger and more unmanageable. HTML - At the heart of it, the fo…
If the world had settle in Word format, instead of javascript we will be using VBA, and everything else will look exactly the same.
I think what we really need is a web app environment, with programming as the first though
Earlier quoted context omitted.
What's sad is the zillions of hours wasted by engineers on an inherently flawed stack. What's sad is how ridiculously complicated it is to create and manage relatively simple UIs. What's sad is an entire generations of programmers growing up and thinking this is normal. Programming is supposed to be about creating platforms for each other so we can continue solving higher (and higher) level problems. This web crap ha…
Complicated to create UIs? Win32 was complicated. MFC was complicated. GTK is hard HTML and CSS aren't as complex as those. Not even close
The initial learning curve was higher, but once you had that knowledge it remained correct and relevant for years- sometimes decades.
And your application UX was faster and smoother. The minor lag between user interaction and UI action that we take as a given today in all but the most basic applications simply didn't exist if you wrote your UI to conform with the platform guidelines.
Even poor performing complex UIs typically did better than today's well written complex UIs - on hardware quite a bit less capable.
We've accepted he current hodgepodge because of portability, but if you've ever worked with the base platforms for any length of time , the difference is painfully clear.
This doesn't touch on how you could expect a consistent ui experience across all applications on an entire platform. It's hard to get that across even two web sites.
We are currently well into a full generation of developers and consumers who are unaware of what's being lost, because most of their interactions are with browser base applications and mobile phones. Waiting a few dozen to a few hundred extra ms for ui to respond is considered normal, if it's noticed at all.
Yes. I feel like we're in the dark ages right now. JavaScript - Dynamically typed, does not scale what so ever. Code written in it becomes 'read only' very quickly. Impossible to refactor. CSS - Also becomes impossible to manage. Who knows if the class you wrote is or isn't being used in HTML or JavaScript somewhere. Same problem, read-only, it only gets bigger and more unmanageable. HTML - At the heart of it, the fo…
React is, in my opinion, a big step forward in reclaiming the front end as a mature UI environment. I have also found that CSS becomes a lot more tolerable with CSS Modules, in combination with React, which allows you to write CSS that targets one component and only that component. By eschewing cascading, you can finally write modular, reusable CSS that avoids side effects and still allows fine-tuning (overriding) by…
Earlier quoted context omitted.
I was building GUIs in pure Win32, with my own C++ wrapper classes for Win32 and later with OWL and MFC. I'd say building Win32 GUIs in C++ was easier than current Web stack. Same with Java AWT and Swing libraries. Objective C / Cocoa is more complex - never really managed to learn it beyond basic stuff, maybe with Swift it's easier. Elm is close to those desktop GUI frameworks, but functional instead of OO. But Tcl/…
But none of your examples are as cross system portable and "native/normal feel" as writing an app that only works in chrome/chromium. For the decades leading up to this stage cross system GUIs with a few simple library dependencies have been an unachieved "easy" task. Web remains as frustrating as ever because now we need it to work on all non portable browsers even on platforms that supports better ones. Then we wan…