151–160 of 191 posts
Oh good, another abstraction around html and css. Please murder me and this project.
Agreed. Universities need to start offering history courses on software development explaining why certain approaches were left behind. HN is full of "new stuff" that is just old stuff that we moved on from.
It should also look like natural speech.
Earlier quoted context omitted.
Agreed. Universities need to start offering history courses on software development explaining why certain approaches were left behind. HN is full of "new stuff" that is just old stuff that we moved on from.
Hey guys... let's make a programming language... for non-programmers! Pretty wacky, eh? It should also look like natural speech.
Great technology. But it reminds me a little bit to perl cgi in the 90's. print h1('hello world'); I mean, this is great for people fast learning, but will never work against "fronted" people in the average (non top) company. I wish I'm wrong.
What problem is ojjs solving and what are the trade-offs? For me personally, the design principle of "separation of concerns" has always worked well, especially in a team environment. Having a pure designer (on photoshop or illustrator), then an html/css expert for coding pages and finally a programmer for adding dynamic content works out as a nice pipeline for web development. With ojjs, the programmer and html/css…
Why does everything have to necessarily solve something? Just experimenting around it's pretty valid IMO.
That being said, this library does try to solve a problem, it's not useless. In my opinion, it's just not the right tool.. yet.
What problem is ojjs solving and what are the trade-offs? For me personally, the design principle of "separation of concerns" has always worked well, especially in a team environment. Having a pure designer (on photoshop or illustrator), then an html/css expert for coding pages and finally a programmer for adding dynamic content works out as a nice pipeline for web development. With ojjs, the programmer and html/css…
I think the only benefit that comes with this library is job security lol
The big issue I have with this approach is that you'll eventually need to do one of the following: hire a designer that can javascript (rare); hire a javascripter that can design (rare); sit and tediously convert your designer's static html and css line-by-line into javascript templates. It's not impossible to be an expert graphic designer and web developer, but they are both extremely deep disciplines and people wit…
This post is getting a lot of flack from people who haven't given it more than a glance. -------Benefits 1. SEO is not a problem. Since OJ can be compiled on the server-side, it's comparable to EjS, JADE or other templating languages, which means SEO is not a problem. 2. Current code-size can be ignored in the long run. This code doesn't have to be sent to the client (since it can run on the server), could possibly b…
Earlier quoted context omitted.
I am sorry, you make a good point, but it's for "better way of doing things". Such comment is so far deep into the common sense territory that there is hardly any reason to mention it explicitly. This discussion is happening with exactly that in mind. Other folks here have mention the separation of concerns. Is there something that you can say related to that? Loved your summary of benefits and trade-offs, but can yo…
Separation of concerns is increased with OJ: Your app doesn't just have one huge CSS file, but each view has it's own css, and it's own html(template) & js. This will significantly reduce complexity in larger apps.
What we are seeing here is an attempt to solve the same problem, but by doing all the work by using JavaScript. Cool. But not impressed.